4 ms·

Everyone is vulnerable: https://www.google.com https://www.google.com, https://www.facebook.com https://www.facebook.com, https://www.svyft.com https://www.svyf

by kajarya 12y ago

Everyone is vulnerable: https://www.google.com https://www.google.com, https://www.facebook.com https://www.facebook.com, https://www.svyft.com https://www.svyft.com as per the link provided in the article (https://shaaaaaaaaaaaaa.com https://shaaaaaaaaaaaaa.com)

tptacek 12y ago
Vulnerable to what? Perhaps better to say, "everyone would be vulnerable".
- deleted 12y ago
  [deleted]
  - tptacek 12y ago
    Someone on HN knows this subject much better than I do, but as I understand it, there's no attack in the literature that takes a good certificate request and $2MM as an input and spits out a validating certificate as an output. This is different than the situation with MD5, where the components needed for a successful attack were known to the literature, and the real work was (a) scaling the attack so that it could perform within the time windows needed to forge a TLS certificate and (b) putting all the pieces together. (But see upthread with 'pbsd, who is one of those people on HN who knows the subject much better than me).
- xkiwi 12y ago
  Https is to prevent wiretapping and man-in-the-middle attacks. The problem now is even you established HTTPS connection, the weak SHA-1 encryption will not protect you.
  - tptacek 12y ago
    The SHA1 vulnerability being contemplated here affects only the establishment of an HTTPS connection; the attack scenario involves obtaining a forged certificate.
    - rictic 12y ago
      That's an especially pedantic correction, as it does not impact the meaning of the statement. s/the weak SHA-1 encryption/the weakened SHA-1 hash used to verify the certificate that's used to authenticate the encrypted connection/
      - tptacek 12y ago
        It is, you're right. It's a hobbyhorse of mine, though, because SHA1 (and MD5) appear in TLS ciphersuites as MAC components, and those uses are not known to be vulnerable at all.
mathias 12y ago
Luckily shaaaaaaaaaaaaa.com itself is fine: https://shaaaaaaaaaaaaa.com/check/shaaaaaaaaaaaaa.com https://shaaaaaaaaaaaaa.com/check/shaaaaaaaaaaaaa.com
thefreeman 12y ago
From the OP: If you poke around Google's SSL configuration, you'll see that (!) they use certificates signed with SHA-1. But each certificate expires in 3 months, a short-lived window that reduces the chances that a certificate could be forged, while they migrate to SHA-2 in 2015.
- personZ 12y ago
  If going SHA-2 only requires a request flag, why so long for a transition? Is there some downside (e.g. old clients that don't support it) that holds Google off?
  - agwa 12y ago
    First, it requires more than just a request flag, since that flag only affects the signature algorithm in your certificate signing request. Your certificate authority has to actually support signing certificates with SHA-2, and also needs a chain that uses SHA-2 signatures. There are some certificate authorities that are lagging behind here, such as RapidSSL. Second, there are old clients out there that still don't support SHA-2. Namely, pre-SP3 Windows XP and pre-2.3 Android. Edit: originally this comment said that only IE on pre-SP3 Windows XP was affected; apparently Chrome on pre-SP3 is as well, presumably because it uses some system libraries.
  - cbhl 12y ago
    Windows XP SP 2 (SP 3 is fine) and early Android, I believe, are the clients that don't support certs later than SHA-1.
    - Someone1234 12y ago
      There are also other (mostly unsupported) mobile devices which don't. Like old ebook readers which have browsers for some reason.
    - drdaeman 12y ago
      Just curious — does X.509 support multiple signatures, so both SHA-1 and SHA-2-based sigs could be included, one for legacy user-agents and one for modern ones?
the_watcher 12y ago
My company website is one of the only ones I tested that actually passed. At first I thought there was simply a shocking lack of adoption, but based on this thread, seems like there is some level of "wow, this is nowhere near as common as it should be," and some level of the tool being somewhat overly strict on what passes. Either way, Google has made it pretty clear that they want at least SHA-2 certificates, which, so long as they call it out in address bars, warning interstitials, and make noise about SERP impact, means that this is the way things are going.
Perseids 12y ago
You have it kind of backwards. Not these sites or their certificates are vulnerable, but the certificate signing process itself is. And by extension all browsers that accept SHA1 certificates anywhere are. To clarify, what the attack does is generate two certificates that have the same SHA1 hash, one of them legitimate and one of them illegitimate. In the worst case scenario the illegitimate one is an itself an intermediate CA, which means the illegitimate one can MITM any connection. You send the legitimate one to the CA to get it signed. When you get it back you swap the legitimate certificate with the illegitimate one - which is possible as both have the same hash - and voila, you have broken TLS world wide. Having a certificate with SHA2 will not save you. A client under attack will not even see it. The only thing that helps is stop accepting SHA1 certificates (and especially SHA1 intermediate CAs) globally. All this stuff about accepting short lived certificates is only a publicity stunt by Google to raise awareness about the issue (an attacker can forge a certificate with any expiry time she wishes).

by kajarya 12y ago

tptacek 12y ago

Vulnerable to what? Perhaps better to say, "everyone would be vulnerable".

deleted 12y ago
[deleted]
- tptacek 12y ago
  Someone on HN knows this subject much better than I do, but as I understand it, there's no attack in the literature that takes a good certificate request and $2MM as an input and spits out a validating certificate as an output. This is different than the situation with MD5, where the components needed for a successful attack were known to the literature, and the real work was (a) scaling the attack so that it could perform within the time windows needed to forge a TLS certificate and (b) putting all the pieces together. (But see upthread with 'pbsd, who is one of those people on HN who knows the subject much better than me).
xkiwi 12y ago
Https is to prevent wiretapping and man-in-the-middle attacks. The problem now is even you established HTTPS connection, the weak SHA-1 encryption will not protect you.
- tptacek 12y ago
  The SHA1 vulnerability being contemplated here affects only the establishment of an HTTPS connection; the attack scenario involves obtaining a forged certificate.
  - rictic 12y ago
    That's an especially pedantic correction, as it does not impact the meaning of the statement. s/the weak SHA-1 encryption/the weakened SHA-1 hash used to verify the certificate that's used to authenticate the encrypted connection/
    - tptacek 12y ago
      It is, you're right. It's a hobbyhorse of mine, though, because SHA1 (and MD5) appear in TLS ciphersuites as MAC components, and those uses are not known to be vulnerable at all.

mathias 12y ago

Luckily shaaaaaaaaaaaaa.com itself is fine: https://shaaaaaaaaaaaaa.com/check/shaaaaaaaaaaaaa.com https://shaaaaaaaaaaaaa.com/check/shaaaaaaaaaaaaa.com

thefreeman 12y ago

From the OP: If you poke around Google's SSL configuration, you'll see that (!) they use certificates signed with SHA-1. But each certificate expires in 3 months, a short-lived window that reduces the chances that a certificate could be forged, while they migrate to SHA-2 in 2015.

personZ 12y ago
If going SHA-2 only requires a request flag, why so long for a transition? Is there some downside (e.g. old clients that don't support it) that holds Google off?
- agwa 12y ago
  First, it requires more than just a request flag, since that flag only affects the signature algorithm in your certificate signing request. Your certificate authority has to actually support signing certificates with SHA-2, and also needs a chain that uses SHA-2 signatures. There are some certificate authorities that are lagging behind here, such as RapidSSL. Second, there are old clients out there that still don't support SHA-2. Namely, pre-SP3 Windows XP and pre-2.3 Android. Edit: originally this comment said that only IE on pre-SP3 Windows XP was affected; apparently Chrome on pre-SP3 is as well, presumably because it uses some system libraries.
- cbhl 12y ago
  Windows XP SP 2 (SP 3 is fine) and early Android, I believe, are the clients that don't support certs later than SHA-1.
  - Someone1234 12y ago
    There are also other (mostly unsupported) mobile devices which don't. Like old ebook readers which have browsers for some reason.
  - drdaeman 12y ago
    Just curious — does X.509 support multiple signatures, so both SHA-1 and SHA-2-based sigs could be included, one for legacy user-agents and one for modern ones?

the_watcher 12y ago

My company website is one of the only ones I tested that actually passed. At first I thought there was simply a shocking lack of adoption, but based on this thread, seems like there is some level of "wow, this is nowhere near as common as it should be," and some level of the tool being somewhat overly strict on what passes. Either way, Google has made it pretty clear that they want at least SHA-2 certificates, which, so long as they call it out in address bars, warning interstitials, and make noise about SERP impact, means that this is the way things are going.

Perseids 12y ago

You have it kind of backwards. Not these sites or their certificates are vulnerable, but the certificate signing process itself is. And by extension all browsers that accept SHA1 certificates anywhere are. To clarify, what the attack does is generate two certificates that have the same SHA1 hash, one of them legitimate and one of them illegitimate. In the worst case scenario the illegitimate one is an itself an intermediate CA, which means the illegitimate one can MITM any connection. You send the legitimate one to the CA to get it signed. When you get it back you swap the legitimate certificate with the illegitimate one - which is possible as both have the same hash - and voila, you have broken TLS world wide. Having a certificate with SHA2 will not save you. A client under attack will not even see it. The only thing that helps is stop accepting SHA1 certificates (and especially SHA1 intermediate CAs) globally. All this stuff about accepting short lived certificates is only a publicity stunt by Google to raise awareness about the issue (an attacker can forge a certificate with any expiry time she wishes).