{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"", "gen_ut":1756843900, "reponame":"openssl", "desc":"OpenSSL", "owner": { "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"https://warmcat.com/repo/openssl", "f":3, "items": [ {"schema":"libjg2-1", "cid":"f24d2ed94c1cd03735317c4255f13bb8", "oid":{ "oid": "879bde123b18afdcb2aecf67f5c807c016bbcf73", "alias": []},"blobname": "bugs/SSLv3", "blob": "So far...\n\nssl3.netscape.com:443 does not support client side dynamic\nsession-renegotiation.\n\nssl3.netscape.com:444 (asks for client cert) sends out all the CA RDN\nin an invalid format (the outer sequence is removed).\n\nNetscape-Commerce/1.12, when talking SSLv2, accepts a 32 byte\nchallenge but then appears to only use 16 bytes when generating the\nencryption keys. Using 16 bytes is ok but it should be ok to use 32.\nAccording to the SSLv3 spec, one should use 32 bytes for the challenge\nwhen opperating in SSLv2/v3 compatablity mode, but as mentioned above,\nthis breaks this server so 16 bytes is the way to go.\n\nwww.microsoft.com - when talking SSLv2, if session-id reuse is\nperformed, the session-id passed back in the server-finished message\nis different from the one decided upon.\n\nssl3.netscape.com:443, first a connection is established with RC4-MD5.\nIf it is then resumed, we end up using DES-CBC3-SHA. It should be\nRC4-MD5 according to 7.6.1.3, 'cipher_suite'.\nNetscape-Enterprise/2.01 (https://merchant.netscape.com) has this bug.\nIt only really shows up when connecting via SSLv2/v3 then reconnecting\nvia SSLv3. The cipher list changes....\nNEW INFORMATION. Try connecting with a cipher list of just\nDES-CBC-SHA:RC4-MD5. For some weird reason, each new connection uses\nRC4-MD5, but a re-connect tries to use DES-CBC-SHA. So netscape, when\ndoing a re-connect, always takes the first cipher in the cipher list.\n\nIf we accept a netscape connection, demand a client cert, have a\nnon-self-signed CA which does not have it's CA in netscape, and the\nbrowser has a cert, it will crash/hang. Works for 3.x and 4.xbeta\n\nNetscape browsers do not really notice the server sending a\nclose notify message. I was sending one, and then some invalid data.\nnetscape complained of an invalid mac. (a fork()ed child doing a\nSSL_shutdown() and still sharing the socket with its parent).\n\nNetscape, when using export ciphers, will accept a 1024 bit temporary\nRSA key. It is supposed to only accept 512.\n\nIf Netscape connects to a server which requests a client certificate\nit will frequently hang after the user has selected one and never\ncomplete the connection. Hitting \u0022Stop\u0022 and reload fixes this and\nall subsequent connections work fine. This appears to be because \nNetscape wont read any new records in when it is awaiting a server\ndone message at this point. The fix is to send the certificate request\nand server done messages in one record.\n","s":{"c":1756843900,"u": 377}} ],"g": 2732,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 1, "si": 0, "db":0, "di":0, "sat":0, "lfc": "0000"}