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.