Last modified: 2012-02-20 19:54:33 UTC
+++ This bug was initially created as a clone of Bug #27909 +++ SSLv2 has some security problems, so current best practice is to not support it: http://tools.ietf.org/html/rfc6176 It might be desirable to disable the ciphers listed as weak on the SSL Labs page, unless there are concerns that would exclude users with very old clients.
In theory, we only need to "support" browser wise what we do on the software side, so >= IE6 atm, plus others which are about http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
http://stackoverflow.com/questions/881563/what-browsers-only-support-sslv2 "According to the book, Data Center Fundamentals, page 369, SSLv3 support was added in Netscape 2.x and Internet Explorer 3.x, and TLS was added in Netscape 4.x and Internet Explorer 4.x. So, SSLv3 support has been widely available since 1995–1996. My working assumption is that SSLv2-only browsers are not found outside a museum."
THINK this is a shell thing, but of course, there is a good chance I'm wrong.
Removing "shell" keyword for things that aren't directly doable by shell users etc
Adding ops keyword
Removing shell keyword if exists
We do get a CONNECTED when using SSL2, but the handshake fails, while it works with SSL3 and TLS1: openssl s_client -connect secure.wikimedia.org:443 -ssl2 CONNECTED(00000003) 5140:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428: openssl s_client -connect secure.wikimedia.org:443 -ssl3 ..SSL handshake has read 1509 bytes and written 319 bytes.. openssl s_client -connect secure.wikimedia.org:443 -tls1 ..SSL handshake has read 1656 bytes and written 293 bytes.. In Apache config SSL2 is disabled and insecure ciphers (!ADH) are disabled as well. # enable only secure ciphers: SSLCipherSuite HIGH:MEDIUM:!ADH # enable only secure protocols: SSLv3 and TLSv1, but not SSLv2 SSLProtocol all -SSLv2 What made you think we are still supporting SSL2? Because you do get a CONNECTED(00000003) first?
secure.wikimedia.org is now obsolete. We support SSL connection using the usual DNS entry such as https://en.wikipedia.org/ $ openssl s_client -connect en.wikipedia.org:443 -ssl2 CONNECTED(00000003) write:errno=54 $ Marking this bug as fixed.