mirror of
https://github.com/wolfSSL/wolfssl.git
synced 2026-08-25 23:33:25 +02:00
Tobias Frauenschläger
e2cce035eb
SSL_clear recycles a WOLFSSL object for a new connection, which is the usual pattern in connection pooling servers, and wolfSSL_shutdown calls it on success as well. It reset the option and state fields but left every piece of key material from the previous connection in place. The teardown path in SSL_ResourceFree is careful here and force zeroes the keys struct and the TLS 1.3 traffic secrets, so a reused object ended up holding material that a freed one would not. The keys struct keeps the write keys, MAC secrets and IVs, clientSecret and serverSecret keep the TLS 1.3 traffic secrets, the DTLS 1.3 epoch table keeps traffic keys, IVs and sequence number keys for every epoch, and the handshake arrays keep the master secret, the pre master secret, the PSK key and the TLS 1.3 key schedule secret. The tls-unique fields keep the Finished values of the connection that just ended, so the next caller could bind to the wrong session. The buffers are sized for the largest supported algorithm, so a later handshake that negotiates something smaller only overwrites a prefix and the tail survives. Force zero all of it. A freshly created object has these zeroed already, with two exceptions that are put back after the wipe: the multicast peer identifier sentinel, and the unprotected DTLS 1.3 epoch 0 together with the epoch pointers aimed at it, which only InitSSL sets up and without which the next handshake has no valid epoch. Wipe the handshake arrays in place rather than releasing them. They have to stay allocated because wolfSSL_set_secret, the exporter and the accessors that run after a connection all read from them on an object that is being recycled rather than freed, and because the key agreement routines take preMasterSz as the size of the buffer they may write, so that is restored to what a freshly allocated Arrays carries. An application that asked to keep the arrays still gets back everything the API can hand it, so the master secret and the exporter secret only go when it did not ask, while the pre master secret, the PSK key and the key schedule secret always do because nothing reads those back. wolfSSL_set_secret and wolfSSL_make_eap_keys both reached into the arrays without checking that they are there, which the ordinary handshake teardown can already leave them not to be, so both now report a bad argument instead. Add a regression test that runs a handshake, clears the object with the arrays kept, and requires the write keys, both traffic secrets and the pre master secret to be gone while the master secret, the exporter secret and the client random survive. It then takes that request back, clears again, and requires the master and exporter secrets to be gone with the arrays themselves still present. Fixes F-7258.
Before creating any new configure files (.conf) read the CONF_FILES_README.md