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 arehttps://ssl3.netscape.com https://sectest.microsoft.com https://sectest.microsoft.com:444 (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 tohttps://ssl3.netscape.com (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 firstname.lastname@example.org. 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
Netscape SSLv3 CA RDN encoding bug
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 tohttps://www.amazon.com (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 usesSSL_OP_MICROSOFT_SESS_ID_BUG to work around this bug.
Netscape SSLv3 changing reused cipher bug
If SSLeay is compiled withREUSE_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.http://www.microsoft.com 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.