Hacker News Reader

Comment by hsbauauvhabzb | Hacker News Reader

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?

View on HN

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

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.

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

Reply on news.ycombinator.com