After 28 years, SSLv2 is still not gone from the internet | Hacker News Reader

After 28 years, SSLv2 is still not gone from the internet

isc.sans.edu

129 points1970-01-0135 comments

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.

See: https://drownattack.com/

Thank you for sharing your insight. Your post is one of those things that makes HN great. Outstanding!

> The reason we disabled SSLv2 at scale is not that it is in itself insecure, or that it is old or anything.

It is just insecure and even the DROWN link states that:

> SSLv2 has been known to be insecure for 20 years

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*):

https://github.com/boppreh/hello_tls

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.

Cool project ! I'll try to use it and give you a feedback. Thanks for sharing.

This is the key point;

"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.

So the number is like 250ish sites. Are these real sites or honeypots/test boxes of some kind?

I'm seeing 200,000-ish sites on the left y-axis?

> 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.

[0] https://www.ssllabs.com/ssl-pulse/

I'm not surprised at all, there is an astounding amount of lefacy stuff around, such as this issue from 2021: https://github.com/golang/go/issues/46899

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?

None. But it makes a good headline: “COBOL STILL IN USE AFTER 60 YEARS!”

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.

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)

2) This one yes.

1) half-wrong, complete crypto stripping downgrade attacks are possible if HSTS and HSTS preloading is not implemented.

Iirc it was possible to perform downgrade attacks upto sslv3, but again the client must accept these algorithms - modern browsers reject them.

Disabling port 80 has no value[1], unless clients who do not respect hsts are of concern (I think curl does not).

[1] https://letsencrypt.org/docs/allow-port-80/

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.

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.

A server supporting SSLv2 allows using the DROWN attack to decrypt TLS connections on same server:

https://www.cs.umd.edu/class/spring2021/cmsc614/papers/drown...

I want my next username to be 1969-12-31:19:00.

Is there any chance you were in a StarCraft 1 earthbound clan for a week about 22 years ago?

No, I never got into Starcraft. I don’t remember when I made up this AIM name, but it was sometime in the early 00s.

I recently started to use Caddy v2, which doesn't even support SSL at all, and TLS versions older than 1.2.

This is a great idea :)

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.

It's also possible that it's related to your blackberry not having the most up-to-date root certificates.

Man is it ever a pain to access old iDracs / BMCs with a modern browser :(

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.

See comment from https://news.ycombinator.com/item?id=38047633

In theory, yes. In practice it's almost certainly already mitigated in client side.

HN insists on breaking the correct hyperlink.

https://isc.sans.edu/diary/After+28+years+SSLv2+is+still+not...

It's because the page says

  <link rel="canonical" href="https://isc.sans.edu/diary/0" />

which is presumably incorrect. I've fixed the link above manually now.

Reply on news.ycombinator.com