On a recent pentest one of the findings that came up (actually it seems like this finding is on every pentest) is the web server allowing SSLv2.
In the course of doing the report I of course wanted to point to a good reason why this was the case. It was actually difficult to find a CVE/CVSS/etc to say why its bad, in fact I never did. Kind of the same with allowing VRFY on your SMTP server. We all know its bad, but where is the proof.
Nevertheless, here are some links that were useful in understanding the problem.
http://www.foundstone.com/us/resources/whitepapers/wp_ssldigger.pdf
http://www.gnu.org/software/gnutls/manual/html_node/On-SSL-2-and-older-protocols.html
http://osvdb.org/show/osvdb/56387
http://www.schneier.com/paper-ssl.pdf
http://en.wikipedia.org/wiki/Secure_Sockets_Layer#Security
http://clearskies.net/blog/2009/03/01/insecure-ssl-and-how-pci-nearly-gets-it-right/
OSVDB updated their entry for SSLv2
http://osvdb.org/56387
Also a couple of tools to do some checking for you:
Foundstone's SSLDigger
http://www.foundstone.com/us/resources/proddesc/ssldigger.htm
nmap will do this for you with -A with port 443 open or with the sslv2 script
http://nmap.org/nsedoc/scripts/sslv2.html
ssl-cipher-check.pl from http://www.unspecific.com/ssl/
Example output from the tool site:
Usage:
$ perl ./ssl-cipher-check.pl : SSL Cipher Check: 1.2 : written by Lee 'MadHat' Heath (at) Unspecific.com Usage: ./ssl-cipher-check.pl [ -dvwas ][ ] default port is 443 -d Add debug info (show it all, lots of stuff) -v Verbose. Show more info about what is found -w Show only weak ciphers enabled. -a Show all ciphers, enabled or not -s Show only the STRONG ciphers enabled.
Default Output:
$ perl ./ssl-cipher-check.pl mail.yahoo.com Testing mail.yahoo.com:443 SSLv3:RC4-MD5 - ENABLED - STRONG 128 bits SSLv3:DES-CBC3-SHA - ENABLED - STRONG 168 bits SSLv3:RC4-SHA - ENABLED - STRONG 128 bits ** SSLv3:DES-CBC-SHA - ENABLED - WEAK 56 bits ** ** SSLv3:EXP-RC4-MD5 - ENABLED - WEAK 40 bits ** ** SSLv3:EXP-DES-CBC-SHA - ENABLED - WEAK 40 bits ** ** SSLv3:EXP-RC2-CBC-MD5 - ENABLED - WEAK 40 bits ** SSLv3:AES128-SHA - ENABLED - STRONG 128 bits SSLv3:AES256-SHA - ENABLED - STRONG 256 bits TLSv1:RC4-MD5 - ENABLED - STRONG 128 bits TLSv1:DES-CBC3-SHA - ENABLED - STRONG 168 bits TLSv1:RC4-SHA - ENABLED - STRONG 128 bits ** TLSv1:DES-CBC-SHA - ENABLED - WEAK 56 bits ** ** TLSv1:EXP-RC4-MD5 - ENABLED - WEAK 40 bits ** ** TLSv1:EXP-DES-CBC-SHA - ENABLED - WEAK 40 bits ** ** TLSv1:EXP-RC2-CBC-MD5 - ENABLED - WEAK 40 bits ** TLSv1:AES128-SHA - ENABLED - STRONG 128 bits TLSv1:AES256-SHA - ENABLED - STRONG 256 bits ** SSLv2:RC4-MD5 - ENABLED - WEAK 128 bits ** ** SSLv2:RC2-CBC-MD5 - ENABLED - WEAK 128 bits ** ** SSLv2:DES-CBC-MD5 - ENABLED - WEAK 56 bits ** ** SSLv2:EXP-RC4-MD5 - ENABLED - WEAK 40 bits ** ** SSLv2:EXP-RC2-CBC-MD5 - ENABLED - WEAK 40 bits ** ** SSLv2:DES-CBC3-MD5 - ENABLED - WEAK 168 bits ** *WARNING* 14 WEAK Ciphers Enabled. Total Ciphers Enabled: 24
Links that go with the above tools
ssl-cipher-check author's talk slides
http://dc214.org/.go/presentations#mar2009
Disabling SSLv2 on a variety of services:
http://blog.zenone.org/2009/03/pci-compliance-disable-sslv2-and-weak.html
http://adamyoung.net/Disable-SSLv2-System-Wide
Comments
SSLv2 Weak...why?
Well, where the whole SSLv2 Enabled deal is really driving from in the last couple of years is the Visa Payment Card Industry (PCI) Data Security Standards that say it's weak, and all subscribing merchants _must_ have it removed. That was enough to get it put in as a Nessus sig (in such wording), and since most of the PCI ASV (aka "scan shops") use Nessus as the basis for their "automated scanning" technology (e.g., Qualys, AmberonTrustWave, etc.), you wound up with this inexplicable vuln showing up everywhere.
SSLv2 is bad for various reasons. As for the "default" server-side security protocol, SSL is a top down negotiator (like baud rates on modems). They try for TLS/SSLvMax and go down. However, the client is fully able to stipulate what security protocol to connect with (unless the server has disabled it, or in some cases--where the server can be configured to not follow client directed handshaking). That's how tools such as the above work, otherwise how would they ever find out what ciphers/security protos the server had?
To the last comment, the far worse issue is allowing NULL or Anonymous CipherSuites to be used on servers. Try communicating with a SSL enabled web server using a NULL-NULL-NULL CipherSuite.
If you want to remove all doubts, suggest to your clients that they enable FIPS-140 ONLY CipherSuites on the servers :>. It doesn't work in most cases (such as financial institutions, etc) because they usually have some corner case requiring RC2-MD5 or something silly like that, but hey, you don't know until you cause a disruption of service!
-asynk
SSLv2 is weak, allowing for MITM
I didn't read all the links you left above but the simple answer is that SSLv2 allows for an easy man-in-the-middle, such as when doing ARP spoofing with Ettercap. I also see SSLv2 enabled on all but the most security conscious servers.
Not Really a Big Deal Anymore...
SSLv2 takes two to tango: server and client. Go to whatever site you'd consider trustworthy on reporting browser statistics. Out of those reported, see how many not only have SSLv2 enabled, but use it as the initial handshake. IE 6 uses SSLv3 out of the box; FF has been doing that since at least 1.5. So, you're talking about a population of maybe 5% that use an antiquated browser. IMO, Considering all of the vulnerabilities out there, I would believe the threats that these people have to face go above and beyond someone downgrading their crypto strength and exposing a previously-encrypted session.
Good collection nonetheless.
@cykyc
Another Great SSL Cipher Check Tool
http://www.woany.co.uk/sslciphercheck/
Both Madhat's and the tool above check ADH and NULL ciphers.
It is important to know that some tools just don't check all the ciphers...