Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Google is Hurrying the Web to Kill SHA-1

konklone.com

Post reply on HN
Print view View original

91–100 of 136 posts

Re: Why Google is Hurrying the Web to Kill SHA-1

#91

Post by Perseids »

konklone wrote: post #46
tptacek wrote: post #32

Earlier quoted context omitted.

Another way to think about SHA2 and SHA3 is that it's entirely possible that SHA3 could fall before SHA2 does. They are unrelated algorithms. I'm also not comparing attacks on SHA1 to brute force (which is also not how MD5 fell). It would be helpful, when people posit attacks on SHA1, if they'd cite the literature they're referring to.

> Another way to think about SHA2 and SHA3 is that it's entirely possible that SHA3 could fall before SHA2 does. They are unrelated algorithms. Very good point, though I would expect SHA2 to see far more research on weakening it. It's been around a lot longer, and its wider deployment makes it a much higher value target. (Is SHA-3 supported anywhere right now?)

You can easily make the converse point and claim that SHA2 has a higher probability to resist future cryptanalysis than SHA3, given that SHA2 has already had a lot more research than SHA3, but is still not broken. "Old" is a feature in this sense. The only issue I know about with SHA2 is its length extension property. And that is by design.

Re: Why Google is Hurrying the Web to Kill SHA-1

#92

Post by konklone »

vtlynch wrote: post #78

This article is amazing! I work in the SSL industry and this is a huge help in summarizing exactly whats going on. @konklone, have you followed the CAB Forum's mailing on this topic? Its the most I've seen them argue in well over a year.

I have, it's one of the links in there. I truly loved reading that discussion.

Re: Why Google is Hurrying the Web to Kill SHA-1

#93

Post by Perseids »

michaelbuckbee wrote: post #41

A while back I launched a SSL scanner [1] and got tons of feedback from people at Facebook, Google, Microsoft. The most divisive item was how to represent SHA1 deprecation. The OPs article doesn't really touch on it, but the reason that Google and everyone else haven't moved on is that there still exist a sizeable number of clients that can only accept SHA1 (and will error on anything else). I actually suspect that l…

> I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support.

How would you do that? When the TLS connection is established you know nothing about the client except its IP address. All of the interesting information about the browser is transported via the HTTP stream which is tunneled inside the TLS connection.

HSTS is simple by comparison, as it's only an HTTP header.

Re: Why Google is Hurrying the Web to Kill SHA-1

#94

Post by sk5t »

Perseids wrote: post #93
michaelbuckbee wrote: post #41

A while back I launched a SSL scanner [1] and got tons of feedback from people at Facebook, Google, Microsoft. The most divisive item was how to represent SHA1 deprecation. The OPs article doesn't really touch on it, but the reason that Google and everyone else haven't moved on is that there still exist a sizeable number of clients that can only accept SHA1 (and will error on anything else). I actually suspect that l…

> I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support. How would you do that? When the TLS connection is established you know nothing about the client except its IP address. All of the interesting information about the browser is transported via the HTTP stream which is tunneled inside the TLS con…

Not true; consider SNI as an example of the server choosing a certificate as part of the handshake, without a cleartext exchange of the hostname.

http://en.wikipedia.org/wiki/Server_Name_Indication

Re: Why Google is Hurrying the Web to Kill SHA-1

#95

Post by agwa »

zaroth wrote: post #90
agwa wrote: post #76

Earlier quoted context omitted.

I'm working on this problem: https://sslmate.com/ Right now it's just a command line client, but a public API is in the works. And this week we'll be announcing a solution to the cert rotation problem (basically, you'll be able to drive your renewals from cron - it's going to be really cool). You might want to follow @sslmate on Twitter - this is just the beginning of some very exciting stuff for automating SSL cert…

Very interesting, thanks! I unpacked the .deb, the nodejs source is pretty easy to follow, so I'd say you pretty much already have the public API done. ;-) The /link API is interesting, versus generating a token on your site through the UI. You might want to consider allowing an explicit $$ limit on /buy, since you store the api-key in the clear (albeit in a config file set to 0600). It looks like you still rely on b…

Thanks for checking it out! Yeah, it's really just a matter of documenting the API ;-)

Unfortunately it does rely on being able to receive an email, as this is a requirement of virtually all certificate authorities, though the email address in the whois record is also an option (at least for TLDs which list the email in whois). I have some ideas to make this easier for users who don't otherwise receive mail at their domains, such as by letting them point their MX record at sslmate.

A configurable $ limit on /buy is a very good idea; also I should make it possible for users to use sslmate without permanently storing their API credentials on the filesystem.

Re: Why Google is Hurrying the Web to Kill SHA-1

#96

Post by Perseids »

kajarya wrote: post #5

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 )

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

Re: Why Google is Hurrying the Web to Kill SHA-1

#97

Post by mike_hearn »

mlissner wrote: post #68
mike_hearn wrote: post #50

Earlier quoted context omitted.

They are businesses. Their customers are mostly businesses. SHA1 is, for most businesses that only want a padlock to reassure their customers, just peachy. A CA that hassles their customers and says "you need to do complicated extra work" is put at a disadvantage to other CA's that have a "customer is always right" kind of attitude. Combined with tools that default to SHA1, and customers that may depressingly actuall…

What's weird though is that they have a consortium. They could have all agreed simultaneously to stop issuing SHA1 certs years ago and at no market loss. But they didn't.

No. They've been quite clear about this. CA's are still selling SHA1 certs because customers are asking for them. They're asking for them because they're compatible with more apps/devices and - until now - browsers treated them the same. So why sacrifice compatibility for no improvement.

The Chrome team are right to push this along, but I do have some sympathy for the CA's here too. I read the whole discussion and it's pretty clear that there was some epic miscommunication going on here. Notably Google thinks that removing the padlock icon is not "deprecation" according to the timetable Microsoft established, but all the people buying certs disagree; that's why they're doing it.

Re: Why Google is Hurrying the Web to Kill SHA-1

#98

Post by Perseids »

Cyranix wrote: post #75

Just to be clear, since I often end up confused on this point — is the use of SHA-1 with HMAC, outside of the context of SSL, still acceptable?

The use of SHA1 with HMAC, inside as well as outside of the context of SSL is still acceptable, yes. Even against a nation state attacker. The reason attacks on HMAC(k,m)~=SHA1(k||SHA1(k||m)) are much more difficult than general collision attacks is that as an attacker you do not know the internal state of the hash function when you are trying to create a collision with m, as the secret key is input in the hash function first.

The attack vector for TLS certificates is the (asymmetric) signature which signs a plain SHA1 hash message. I'm still disappointed that after all the experiences they have had with MD5 they haven't yet started to randomize the hash in the signature (sign SHA1(random||message) instead of SHA1(message) ) which would boost the signature security to that of HMAC.

Re: Why Google is Hurrying the Web to Kill SHA-1

#99

Post by cgjaro »

tptacek wrote: post #2

Two nits, both pedantic: An attack on SHA1 that makes certificate forgery viable within the next few years doesn't seem very likely, although over the long term it might be. The attack on SHA1 isn't like the attacks on RSA-1024; my sense is that the literature already knows how to break RSA-1024 given enough compute, but does not know how to do that with SHA1. Further, factoring RSA-1024 provides an attacker with a t…

I don't know if "10 years" falls in your definition of "next few years".

For a viable rogue CA attack, you need a chosen-prefix attack. Current best research (https://marc-stevens.nl/research/papers/EC13-S.pdf) shows it should take 2^77.1 SHA-1 compression calls to do a chosen-prefix attack. Say this is improved to 2^65 within the next 10 years. Right now a good GPU (AMD R9 290) can do 3 billion SHA-1 compression calls per second. Say Moore's Law continues for the next 10 years and that 10 years from now a GPU can do 20 billion SHA-1 per second. So 10 year from now, 100 high-end GPUs should be able to produce a rogue CA with colliding SHA-1 signature in 7 month of compute time.

Change one little assumption and assume the best attack ends up being 2^60 instead of 2^65. In this case, a viable attack could certainly be carried out in the next 3-4 years.

You can't cross your fingers and hopes such an attack will not be discovered. The time to abandon SHA-1 is now.

Re: Why Google is Hurrying the Web to Kill SHA-1

#100

Post by PeterisP »

orblivion wrote: post #77

Understanding that this is a naive outsider perspective, I find it strange that it's any sort of emergency when a single collision has yet to be produced. And then, does the latest hash collision attack allow you to make a collision with a _specific_ target or just make a collision in general? Finally, even if you hit the target with some junk that happens to hash to the same thing, is it going to be in correct file…

The point is that currently producing a single collision may cost a couple million dollars of brute force for now. So we should expect it to be used (there are attacks where that much money is invested, either a very valuable target or very many low-value targets), but we should expect to see one only after a highly targeted attack is detected and analyized - in the case of Flame, those steps took a few years.

Some government agency MITM'ing major social sites or email providers would be rather possible at that cost.

Post reply on HN