Hacker News Reader

Comment by kajarya | Hacker News Reader

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

View on HN

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

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.

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?

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.

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.

There are also other (mostly unsupported) mobile devices which don't. Like old ebook readers which have browsers for some reason.

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?

It has to be so frustrating to Google that the people responsible for Android make it so hard for users to upgrade to versions that support SHA-2.

It's not Google's fault the telecoms cripple every phone they sell.

Well, Google knew it would happen, and allowed them to do it.

Lots of old clients still out there, including people who don't have the option to upgrade.

A couple of years ago we tried upgrading our certificate to SHA-2, and rolled it back within an hour, because it broke the site for several of our customers.

It might work now; IE6 users have (finally!) dropped to about 0, but we certainly have tons of IE7 users, and I'll have to look up versions of Windows they're using before we try it again.

We work with hospitals whose IT departments who need to control changes to their computing environments extremely carefully, and upgrades are unfortunately quite expensive and difficult for these kinds of environments.

Fortunately, hopefully most enterprises moved to SP3 years ago. MS officially dropped XP SP2 support in mid 2010, and while MS does do Custom Support for older service packs, of course I hope no one is relying on it now. I think Custom Support for WinXP SP3 is IE8 only after the first year BTW.

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.

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

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

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.

The SHA1 vulnerability being contemplated here affects only the establishment of an HTTPS connection; the attack scenario involves obtaining a forged certificate.

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/

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.

Reply on news.ycombinator.com