Hacker News Reader

Comment by StressedDev | Hacker News Reader

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.

View on HN

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)

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/

Reply on news.ycombinator.com