Loading CHANGES +5 −0 Original line number Diff line number Diff line Loading @@ -4,6 +4,11 @@ Changes between 0.9.8p and 0.9.8q [xx XXX xxxx] *) Disable code workaround for ancient and obsolete Netscape browsers and servers: an attacker can use it in a ciphersuite downgrade attack. Thanks to Martin Rex for discovering this bug. CVE-2010-4180 [Steve Henson] *) Fixed J-PAKE implementation error, originally discovered by Sebastien Martini, further info and confirmation from Stefan Arentz and Feng Hao. Note that this fix is a security fix. CVE-2010-4252 Loading NEWS +1 −0 Original line number Diff line number Diff line Loading @@ -7,6 +7,7 @@ Major changes between OpenSSL 0.9.8p and OpenSSL 0.9.8q: o Fix for security issue CVE-2010-4180 o Fix for CVE-2010-4252 Major changes between OpenSSL 0.9.8o and OpenSSL 0.9.8p: Loading doc/ssl/SSL_CTX_set_options.pod +1 −12 Original line number Diff line number Diff line Loading @@ -78,18 +78,7 @@ this breaks this server so 16 bytes is the way to go. =item SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG ssl3.netscape.com:443, first a connection is established with RC4-MD5. If it is then resumed, we end up using DES-CBC3-SHA. It should be RC4-MD5 according to 7.6.1.3, 'cipher_suite'. Netscape-Enterprise/2.01 (https://merchant.netscape.com) has this bug. It only really shows up when connecting via SSLv2/v3 then reconnecting via SSLv3. The cipher list changes.... NEW INFORMATION. Try connecting with a cipher list of just DES-CBC-SHA:RC4-MD5. For some weird reason, each new connection uses RC4-MD5, but a re-connect tries to use DES-CBC-SHA. So netscape, when doing a re-connect, always takes the first cipher in the cipher list. As of OpenSSL 0.9.8q and 1.0.0c, this option has no effect. =item SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG Loading ssl/s3_clnt.c +3 −0 Original line number Diff line number Diff line Loading @@ -814,8 +814,11 @@ int ssl3_get_server_hello(SSL *s) s->session->cipher_id = s->session->cipher->id; if (s->hit && (s->session->cipher_id != c->id)) { /* Workaround is now obsolete */ #if 0 if (!(s->options & SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG)) #endif { al=SSL_AD_ILLEGAL_PARAMETER; SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,SSL_R_OLD_SESSION_CIPHER_NOT_RETURNED); Loading ssl/s3_srvr.c +5 −0 Original line number Diff line number Diff line Loading @@ -927,6 +927,10 @@ int ssl3_get_client_hello(SSL *s) break; } } /* Disabled because it can be used in a ciphersuite downgrade * attack: CVE-2010-4180. */ #if 0 if (j == 0 && (s->options & SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG) && (sk_SSL_CIPHER_num(ciphers) == 1)) { /* Special case as client bug workaround: the previously used cipher may Loading @@ -941,6 +945,7 @@ int ssl3_get_client_hello(SSL *s) j = 1; } } #endif if (j == 0) { /* we need to have the cipher in the cipher Loading Loading
CHANGES +5 −0 Original line number Diff line number Diff line Loading @@ -4,6 +4,11 @@ Changes between 0.9.8p and 0.9.8q [xx XXX xxxx] *) Disable code workaround for ancient and obsolete Netscape browsers and servers: an attacker can use it in a ciphersuite downgrade attack. Thanks to Martin Rex for discovering this bug. CVE-2010-4180 [Steve Henson] *) Fixed J-PAKE implementation error, originally discovered by Sebastien Martini, further info and confirmation from Stefan Arentz and Feng Hao. Note that this fix is a security fix. CVE-2010-4252 Loading
NEWS +1 −0 Original line number Diff line number Diff line Loading @@ -7,6 +7,7 @@ Major changes between OpenSSL 0.9.8p and OpenSSL 0.9.8q: o Fix for security issue CVE-2010-4180 o Fix for CVE-2010-4252 Major changes between OpenSSL 0.9.8o and OpenSSL 0.9.8p: Loading
doc/ssl/SSL_CTX_set_options.pod +1 −12 Original line number Diff line number Diff line Loading @@ -78,18 +78,7 @@ this breaks this server so 16 bytes is the way to go. =item SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG ssl3.netscape.com:443, first a connection is established with RC4-MD5. If it is then resumed, we end up using DES-CBC3-SHA. It should be RC4-MD5 according to 7.6.1.3, 'cipher_suite'. Netscape-Enterprise/2.01 (https://merchant.netscape.com) has this bug. It only really shows up when connecting via SSLv2/v3 then reconnecting via SSLv3. The cipher list changes.... NEW INFORMATION. Try connecting with a cipher list of just DES-CBC-SHA:RC4-MD5. For some weird reason, each new connection uses RC4-MD5, but a re-connect tries to use DES-CBC-SHA. So netscape, when doing a re-connect, always takes the first cipher in the cipher list. As of OpenSSL 0.9.8q and 1.0.0c, this option has no effect. =item SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG Loading
ssl/s3_clnt.c +3 −0 Original line number Diff line number Diff line Loading @@ -814,8 +814,11 @@ int ssl3_get_server_hello(SSL *s) s->session->cipher_id = s->session->cipher->id; if (s->hit && (s->session->cipher_id != c->id)) { /* Workaround is now obsolete */ #if 0 if (!(s->options & SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG)) #endif { al=SSL_AD_ILLEGAL_PARAMETER; SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,SSL_R_OLD_SESSION_CIPHER_NOT_RETURNED); Loading
ssl/s3_srvr.c +5 −0 Original line number Diff line number Diff line Loading @@ -927,6 +927,10 @@ int ssl3_get_client_hello(SSL *s) break; } } /* Disabled because it can be used in a ciphersuite downgrade * attack: CVE-2010-4180. */ #if 0 if (j == 0 && (s->options & SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG) && (sk_SSL_CIPHER_num(ciphers) == 1)) { /* Special case as client bug workaround: the previously used cipher may Loading @@ -941,6 +945,7 @@ int ssl3_get_client_hello(SSL *s) j = 1; } } #endif if (j == 0) { /* we need to have the cipher in the cipher Loading