SSL implementation bugs

During my development of SSLeay, I have had the opportunity to detect many different bugs in other vendor's SSL implementations. Some of these may now be out dated, and some could be sightly wrong, so take everything with a grain of salt. I have also included a few extra bugs that are not strictly SSL problems but if you implement SSL, you will hit them.

The primary test machines available are (asks for a client certificate)

SSLv2 session id reuse cert type bug

From the SSLv2 specification, section 2.6 Server Only Protocol Messages

If the SESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE, CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields will be zero.

If one connects to (19-Jun-97), and reuses a session id, the CERTIFICATE-TYPE is returned as 1 in the reused session. Most SSLv2 clients tolerate this departure from the standard. SSLeay enables tolerance of this via the SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG option.

Fixed in NT 4.0 SP3, not fixed yet in W95 IE 3.0x

SSLv2 protocol packet order

This behaviour was originally reported by SSLref clients wait to receive a server-verify before they send a client-finished. Besides this not being evident from the examples in section 2.2.1 of the SSLv2 specifications, it makes more sense to always send all packets you can before reading any returned data. SSLeay was waiting in the server to receive a client-finish before sending the server-verify. This has been changed so that SSLeay sends a server-verify before trying to read the client-finished. This was a sort of bug in SSLeay but it is something to be aware of when implementing SSLv2.

SSLv3 Dynamic session renegotiation (19-Jun-97) does not support client dynamic session renegotiation. If you attempt to do this, a handshake failure alert will be returned. Perhaps this should just be silently ignored instead. Microsoft handles this correctly.

Netscape SSLv3 CA RDN encoding bug (19-Jun-97) does not encode CA distinguished names correctly when prompting for a client certificate to be provided. The outer sequence on each DN is missing. SSL_OP_NETSCAPE_CA_DN_BUG is used by SSLeay to parse this alternative encoding system. I believe this erroneous encoding system is only present on this test server. Microsoft servers send the correct encoding.

Netscape SSLv2 challenge length bug

Netscape-Commerce/1.12, when talking SSLv2, accepts a 32 byte challenge but then appears to only use 16 bytes when generating the encryption keys. Using 16 bytes is ok but it should be ok to use 32. According to the SSLv3 spec, one should use 32 bytes for the challenge when operating in SSLv2/v3 compatibility mode, but as mentioned above, this breaks this server so 16 bytes is the way to go. This error is serious since it means that all SSLv2/v3 client applications need to use 16 byte challenge keys, not 32 as the SSLv3 spec suggests. Connect to (19-Jun-97) for an example of a server that displays this property. SSLeay uses SSL_OP_NETSCAPE_CHALLENGE_BUG to work around this bug.

Microsoft SSLv2 session id reuse bug

This bug appears to be fixed. When talking SSLv2, if session-id reuse is performed, the session-id passed back in the server-finished message is different from the client originally passed in. There may be old version of MS servers that still contain this bug in their SSLv2 implementation. SSLeay uses SSL_OP_MICROSOFT_SESS_ID_BUG to work around this bug.

Netscape SSLv3 changing reused cipher bug (19-Jun-97). If a SSLv3 connection is initially established, the first available cipher is used. If a session is resumed, a different cipher may be chosen if it appears in the passed cipher list before the sessions current cipher. Normally this bug will only be noticed if you cipher list management code is doing screwy things. Netscape-Enterprise/2.01 ( has this bug. It is best observed by doing a SSLv23 connection, then using a different cipher order when reconnecting using an old session-id. This feature can be used to change ciphers on the server. It does not speak highly of how session-ids are managed in a multi-threaded environment in that particular SSL implementation. SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG will let SSLeay change SSL_SESSION->cipher if the server dictates that this should be done.

If SSLeay is compiled with REUSE_CIPHER_BUG defined, SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, when set, will cause the server side of SSLeay's SSL to attempt to drop down to either a NULL encryption cipher or an export cipher. Netscape clients do not always update the key when the reused session is weaker than the initial connection.

Navigator certificate management problems

(Some of the following information could be wrong since I have not re-tested things since I scribbled down my rough notes).

While this is not strictly the SSL protocol, it does cause problems when testing client certificates against Netscape navigator 3.x (and perhaps 4.x). Have a SSLv2 or SSLv3 server accept a Navigator connection, demand a client cert, have a non-self-sighed CA loaded which does not have it's CA in Netscape, and if the browser has a client certificate, it will crash/hang. Works for 3.x and 4.xbeta. This particularly strange combination of events can cause a lot of wasted time. The solution is to get the self signed CA cert into Navigator.

Netscape SSLv3 ignoring close notify alerts

Netscape browsers do not really notice the server sending a close notify message. I was sending one, and then some invalid data. Netscape complained of an invalid mac, not data being sent on a shutdown SSLv3 connection. I only noticed this problem because a program I was debugging was fork()ing and after the parent had sent the close notify the child was sending more data. My code was wrong in that the parent should not have been sending the close notify but still, it appears that this part of the SSLv3 specification has not been strictly implemented by Navigator.

Netscape SSLv3 export ciphers public keys not restricted

Netscape, when using export ciphers, will accept a 1024 bit temporary RSA key. It is supposed to only accept 512. While this is not strictly a bug, it is interesting.

Microsoft SSLv2 rollback attacks on SSLv3 clients

The SSLv3 specifications require that a modified PKCS#1 padding be used in the RSA encryption operation to facilitate detection of rollback attacks against SSLv3 capable browsers when using the compatibility mode. Microsoft clients do not check for the modified PKCS#1 packets, so are vulnerable to this type of attack.

MICROSOFT SSLv2 PKCS#1 padding error

MSIE 3.02, when doing SSLv2 (SSLv3 is turned off), all ways uses the SSLv2/v3 special PKS1 padding of 8 bytes of value 3. In it should not do so if it is talking only SSLv2 (SSLv2 hello message with a version of number of 2).

Microsoft large SSLv3 packets

Microsoft IE sends SSLv3 packets greater than 18k+5 bytes. This is expressly prohibited by the SSLv3 spec. will sent a page of this size (assuming you have a required cookie so you are not re-directed). Navigator rejects the large packets. If an SSLeay application enables SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER all subsequent SSL connections will be able to read these large packets.


I'm sure I've left some out. Please feel free to provide me with more bugs/problems. If people have specific application versions that are affected by these bugs, or what software releases fix them, please let me know.


eric (