once the ChangeCipherSpec message is received. Previously, the server would
set the flag once at SSL3_ST_SR_CERT_VRFY and again at SSL3_ST_SR_FINISHED.
This would allow a second CCS to arrive and would corrupt the server state.
(Because the first CCS would latch the correct keys and subsequent CCS
messages would have to be encrypted, a MitM attacker cannot exploit this,
though.)
Thanks to Joeri de Ruiter for reporting this issue.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit e94a6c0ede623960728415b68650a595e48f5a43)
Conflicts:
CHANGES
ssl/s3_srvr.c
Use same logic when determining when to expect a client
certificate for both TLS and DTLS.
PR#3452
(cherry picked from commit c8d710dc5f83d69d802f941a4cc5895eb5fe3d65)
PR: 2808
With DTLS/SCTP the SCTP extension SCTP-AUTH is used to protect DATA and
FORWARD-TSN chunks. The key for this extension is derived from the
master secret and changed with the next ChangeCipherSpec, whenever a new
key has been negotiated. The following Finished then already uses the
new key. Unfortunately, the ChangeCipherSpec and Finished are part of
the same flight as the ClientKeyExchange, which is necessary for the
computation of the new secret. Hence, these messages are sent
immediately following each other, leaving the server very little time to
compute the new secret and pass it to SCTP before the finished arrives.
So the Finished is likely to be discarded by SCTP and a retransmission
becomes necessary. To prevent this issue, the Finished of the client is
still sent with the old key.
(cherry picked from commit 9fb523adce6fd6015b68da2ca8e4ac4900ac2be2)
(cherry picked from commit b9ef52b07897f249a9fa44943dba33fba8fb2721)
This fix ensures that
* A HelloRequest is retransmitted if not responded by a ClientHello
* The HelloRequest "consumes" the sequence number 0. The subsequent
ServerHello uses the sequence number 1.
* The client also expects the sequence number of the ServerHello to
be 1 if a HelloRequest was received earlier.
This patch fixes the RFC violation.
(cherry picked from commit b62f4daac00303280361924b9cc19b3e27528b15)
Submitted by: steve@openssl.org
More robust fix and workaround for PR#1949. Don't try to work out if there
is any write pending data as this can be unreliable: always flush.
Submitted by: steve@openssl.org
Fix DTLS connection so new_session is reset if we read second client hello:
new_session is used to detect renegotiation.
This change resolves a number of problems and obviates multiple kludges.
A new feature is that you can now say "AES256" or "AES128" (not just
"AES", which enables both).
In some cases the ciphersuite list generated from a given string is
affected by this change. I hope this is just in those cases where the
previous behaviour did not make sense.
