4 ms·

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

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.

corbezzoli 3y ago
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.
- hsbauauvhabzb 3y ago
  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/ https://letsencrypt.org/docs/allow-port-80/
hsbauauvhabzb 3y ago
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.
- iforgotpassword 3y ago
  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.
tsimionescu 3y ago
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.

corbezzoli 3y ago

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.

hsbauauvhabzb 3y ago
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/ https://letsencrypt.org/docs/allow-port-80/

hsbauauvhabzb 3y ago

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.

iforgotpassword 3y ago
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.

tsimionescu 3y ago

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.