Ok, this post lacks an important bit of information, and gets something wrong: The reason we disabled SSLv2 at scale is not that it is in itself insecure, or that it is old or anything.
The reason we disabled SSLv2 is the DROWN attack. It is a cross-protocol attack (or let's say cross-protocol-version attack) and the important fact to understand here is: The mere fact that you have SSLv2 enabled puts you at risk. It allows an attacker to essentially use your private key.
So, yes, SSLv2 on its own absolutely is a risk if your server supports it. It is completely independent of whether your browser supports it.
In trying to catch this type of problem on my turf, I built my own scanner after getting frustrated with the current options (*cough* testssl.sh and its 24kloc of bash *cough*):
The cool thing is that you only need Client/Server Hello, which happens before any encryption. So the tool can be fast even though it's written in pure dependency-less Python (pyOpenSSL being optional if you want certificate info). I'm frequently adding new features, so suggestions and bug reports are appreciated.
"Nevertheless, the fact that a certain web server supports this anachronistic protocol provides an interesting indicator that other vulnerabilities and security issues may (and most likely will) be present on the same system."
SSLv2 is, in itself, harmless since no random user using their browser will ever use it.
However the fact it is still switched on implies that the site contains some very old code in the stack. Their server/ OpenSSL, or whatever is old- which likely means the whole stack is old. Since the server likely also supports SSLv3, a well crafted attack could steal the private key.
Of course a site that is this old is also likely to have more-or-less zero (human) traffic, and protects likely zero actual information. So while an easy target, probably not a rich one.
Doing a deeper analysis of these sites would be interesting.
Equally a similar scan for SSLv3 would be good as a comparison statistic. (I expect the number is pretty similar.)
> SSLv2 is, in itself, harmless since no random user using their browser will ever use it.
Erh... No.
That was actually the main result of the DROWN paper and eventually the reason why everyone was disabling backwards compatibility with SSLv2:
https://drownattack.com/
The mere fact that you are supporting SSLv2 means that an attacker can abuse this to do key operations with your private key.
> This data seems to be supported by the latest statistics from Qualys SSL Labs, which show that the service has only detected SSLv2 being supported on 0.2% of all servers it scanned in the course of April 2023.
248 out of ~150k websites[0], not 248 out of all websites.
Iirc browsers now warn if tls 1.1 or lower - this warning is a similar page to when there is an invalid cert, but you cannot click through - you need to explicitly disable a config flag to ignore.
So what’s the real world impact of a server running sslv2?
Web browsers are not the only thing which use TLS/SSL. In general, allowing the use of insecure protocols will eventually bite you. Here is why:
1) It makes it easier for attackers to mount attacks. It gives them another tool they can use to attack your service. My guess is supporting SSLv2 makes it easier to mount downgrade attacks against a server (i.e. an attack where you can trick the client and the server to use SSLv2 instead of a secure protocol).
2) You should not run unnecessary code on your services. It gives attackers a chance to hack your service because the unnecessary code can be exploited.
The biggest problem is that SSLv2 can be attacked to obtain enough information about the private key to decrypt TLSv1.2 in realistic amounts of time. So even if the client only uses secure protocols, the fact that the server supports SSLv2 means that the client's traffic is at risk.
1) Are there any public case studies of sslv2 or similar being used against the general public? Downgrade attacks won’t work if the server supports sslv2 as the connecting host will still demand tls 1.2.
2) Is there any public case studies of remotely exploitable code via sslv2? granted poodle etc are still a thing, but they are cryptgraphic attacks which rely on the client accepting ssl in the first place.
imo more importantly, if they are running SSLv2 they almost certainly have really bad vulnerabilities somewhere as they’re clearly running legacy systems evidenced by sslv2, but I am not aware of any directly exploitable servers due specifically to sslv2 being enabled.
This kind of alarmism creates security fatigue, wasting time and resources rather than focusing on actual security issues.
DROWN has been mentioned several times here and was up and down the news when it was disclosed. It allows you to steal the private key from the server, after which you can mitm any version of the protocol.
1) Pardon me if I’m wrong, but downgrade attacks will be possible for as long as HTTP-non-S is allowed. Browsers could support SSLv2 as long as they treat it as an insecure origin. (This assumes HSTS isn’t used, which definitely isn’t on SSLv2 hosts)
Caddy is a wonderful web server. I use it since the early v1 days and it simply rocks. The configuration is simple once you get past some eureka! moments.
Community support is so-so (I hope to be very wrong but there is more elitism today than before) but Matt Holt (mholt, the author of Caddy) is simply wonderful. He is forgiving to beginners and overall a really, really nic egut.
Thanks Matt for your work - we bump into each other from time to time on the forum or discussions. THNAKS for Caddy.
Wow. Back in 2014 I was fighting with product development to default to TLS and make SSL optional. That was almost a decade ago and SSL is still around?
When did HN dropped the SSLv2 support? I have a guess that this has happened this autumn because my Blackberry stopped being allowed to visit HN (as well as Google, Wikipedia and most of internets) while being allowed to visit few set of websites, for example Less Wrong.
I can bet Please install JAVA and Flash plugin to continue... ):
Oh lord. Even Supermicro BMCs from 2020 still have Java applet support. On the plus side, it only does TLS v1.2 and serves certificates properly. Let's ignore that it's also very, very slow.
Edit: APC NMC2/3 don't allow of loading of conventional PEM PKCS#8 certificates. They require proprietary variations of "PKCS#12" certs and have no readily-available tool to change them. Also, APC's new owner has switched to a business model where they charge for firmware updates and refuse to patch devices without $$$$.
I'm not saying I've done it recently, but I have configured services to use legacy TLS protocols in purpose. It's better than fallback to plain text in case of mail services and FTP for example.
If I understood it correctly, it can actually be worse than fallback to plain text, because if a malicious actor can stability a connection using legacy SSLv2, then this connection can be used to decrypt the session for users running the latest TLS version.
While plain text connections would affected only users using the plain text connection.
The reason we disabled SSLv2 is the DROWN attack. It is a cross-protocol attack (or let's say cross-protocol-version attack) and the important fact to understand here is: The mere fact that you have SSLv2 enabled puts you at risk. It allows an attacker to essentially use your private key.
So, yes, SSLv2 on its own absolutely is a risk if your server supports it. It is completely independent of whether your browser supports it.
See: https://drownattack.com/