Last modified: 2012-02-20 19:54:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T31014, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29014 - Disable SSLv2 on secure.wikimedia.org
Disable SSLv2 on secure.wikimedia.org
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
SSL related (Other open bugs)
unspecified
All All
: High enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
https://www.ssllabs.com/ssldb/analyze...
: ops
Depends on:
Blocks: ssl
  Show dependency treegraph
 
Reported: 2011-05-16 16:12 UTC by Matt McCutchen
Modified: 2012-02-20 19:54 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Matt McCutchen 2011-05-16 16:12:06 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.
Comment 1 Sam Reed (reedy) 2011-05-16 16:14:20 UTC
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
Comment 2 Derk-Jan Hartman 2011-05-17 19:27:56 UTC
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."
Comment 3 Mark A. Hershberger 2011-05-19 16:36:29 UTC
THINK this is a shell thing, but of course, there is a good chance I'm wrong.
Comment 4 Sam Reed (reedy) 2011-07-06 20:10:25 UTC
Removing "shell" keyword for things that aren't directly doable by shell users etc
Comment 5 Sam Reed (reedy) 2011-07-06 20:31:27 UTC
Adding ops keyword
Comment 6 Sam Reed (reedy) 2011-07-06 20:31:59 UTC
Removing shell keyword if exists
Comment 7 Daniel Zahn 2012-02-07 09:24:23 UTC
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?
Comment 8 Antoine "hashar" Musso (WMF) 2012-02-20 19:54:33 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links