diff options
author | Emilia Kasper <emilia@openssl.org> | 2014-11-19 17:01:36 +0100 |
---|---|---|
committer | Emilia Kasper <emilia@openssl.org> | 2014-11-20 15:17:36 +0100 |
commit | e5f261df7369a8d1734045ed59e12b42142a9147 (patch) | |
tree | 7a149a3254d47240c1de4424e913f7ad4dd10fca /CHANGES | |
parent | 9baee0216fe3bf572435a867963bdeea8ad95b59 (diff) |
Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset
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)
Diffstat (limited to 'CHANGES')
-rw-r--r-- | CHANGES | 10 |
1 files changed, 10 insertions, 0 deletions
@@ -43,6 +43,11 @@ (CVE-2014-3566) [Adam Langley, Bodo Moeller] + *) Tighten handling of the ChangeCipherSpec (CCS) message: reject + early CCS messages during renegotiation. (Note that because + renegotiation is encrypted, this early CCS was not exploitable.) + [Emilia Käsper] + *) Tighten client-side session ticket handling during renegotiation: ensure that the client only accepts a session ticket if the server sends the extension anew in the ServerHello. Previously, a TLS client would @@ -376,6 +381,11 @@ Changes between 1.0.1j and 1.0.1k [xx XXX xxxx] + *) Tighten handling of the ChangeCipherSpec (CCS) message: reject + early CCS messages during renegotiation. (Note that because + renegotiation is encrypted, this early CCS was not exploitable.) + [Emilia Käsper] + *) Tighten client-side session ticket handling during renegotiation: ensure that the client only accepts a session ticket if the server sends the extension anew in the ServerHello. Previously, a TLS client would |