1*ebfedea0SLionel SambucSo far... 2*ebfedea0SLionel Sambuc 3*ebfedea0SLionel Sambucssl3.netscape.com:443 does not support client side dynamic 4*ebfedea0SLionel Sambucsession-renegotiation. 5*ebfedea0SLionel Sambuc 6*ebfedea0SLionel Sambucssl3.netscape.com:444 (asks for client cert) sends out all the CA RDN 7*ebfedea0SLionel Sambucin an invalid format (the outer sequence is removed). 8*ebfedea0SLionel Sambuc 9*ebfedea0SLionel SambucNetscape-Commerce/1.12, when talking SSLv2, accepts a 32 byte 10*ebfedea0SLionel Sambucchallenge but then appears to only use 16 bytes when generating the 11*ebfedea0SLionel Sambucencryption keys. Using 16 bytes is ok but it should be ok to use 32. 12*ebfedea0SLionel SambucAccording to the SSLv3 spec, one should use 32 bytes for the challenge 13*ebfedea0SLionel Sambucwhen opperating in SSLv2/v3 compatablity mode, but as mentioned above, 14*ebfedea0SLionel Sambucthis breaks this server so 16 bytes is the way to go. 15*ebfedea0SLionel Sambuc 16*ebfedea0SLionel Sambucwww.microsoft.com - when talking SSLv2, if session-id reuse is 17*ebfedea0SLionel Sambucperformed, the session-id passed back in the server-finished message 18*ebfedea0SLionel Sambucis different from the one decided upon. 19*ebfedea0SLionel Sambuc 20*ebfedea0SLionel Sambucssl3.netscape.com:443, first a connection is established with RC4-MD5. 21*ebfedea0SLionel SambucIf it is then resumed, we end up using DES-CBC3-SHA. It should be 22*ebfedea0SLionel SambucRC4-MD5 according to 7.6.1.3, 'cipher_suite'. 23*ebfedea0SLionel SambucNetscape-Enterprise/2.01 (https://merchant.netscape.com) has this bug. 24*ebfedea0SLionel SambucIt only really shows up when connecting via SSLv2/v3 then reconnecting 25*ebfedea0SLionel Sambucvia SSLv3. The cipher list changes.... 26*ebfedea0SLionel SambucNEW INFORMATION. Try connecting with a cipher list of just 27*ebfedea0SLionel SambucDES-CBC-SHA:RC4-MD5. For some weird reason, each new connection uses 28*ebfedea0SLionel SambucRC4-MD5, but a re-connect tries to use DES-CBC-SHA. So netscape, when 29*ebfedea0SLionel Sambucdoing a re-connect, always takes the first cipher in the cipher list. 30*ebfedea0SLionel Sambuc 31*ebfedea0SLionel SambucIf we accept a netscape connection, demand a client cert, have a 32*ebfedea0SLionel Sambucnon-self-signed CA which does not have it's CA in netscape, and the 33*ebfedea0SLionel Sambucbrowser has a cert, it will crash/hang. Works for 3.x and 4.xbeta 34*ebfedea0SLionel Sambuc 35*ebfedea0SLionel SambucNetscape browsers do not really notice the server sending a 36*ebfedea0SLionel Sambucclose notify message. I was sending one, and then some invalid data. 37*ebfedea0SLionel Sambucnetscape complained of an invalid mac. (a fork()ed child doing a 38*ebfedea0SLionel SambucSSL_shutdown() and still sharing the socket with its parent). 39*ebfedea0SLionel Sambuc 40*ebfedea0SLionel SambucNetscape, when using export ciphers, will accept a 1024 bit temporary 41*ebfedea0SLionel SambucRSA key. It is supposed to only accept 512. 42*ebfedea0SLionel Sambuc 43*ebfedea0SLionel SambucIf Netscape connects to a server which requests a client certificate 44*ebfedea0SLionel Sambucit will frequently hang after the user has selected one and never 45*ebfedea0SLionel Sambuccomplete the connection. Hitting "Stop" and reload fixes this and 46*ebfedea0SLionel Sambucall subsequent connections work fine. This appears to be because 47*ebfedea0SLionel SambucNetscape wont read any new records in when it is awaiting a server 48*ebfedea0SLionel Sambucdone message at this point. The fix is to send the certificate request 49*ebfedea0SLionel Sambucand server done messages in one record. 50