If one connects to https://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.

https://ssl3.netscape.com (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.

https://ssl3.netscape.com:444 (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-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 https://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.

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.

https://ssl3.netscape.com (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 (https://merchant.netscape.com) 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.

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.