When I use the sha tool against google.com, it shows them using SHA-1.
Why Google is Hurrying the Web to Kill SHA-1
71–80 of 136 posts
Re: Why Google is Hurrying the Web to Kill SHA-1
#72Earlier 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.
Re: Why Google is Hurrying the Web to Kill SHA-1
#73Two 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…
To out-pedant you: even assuming that the differential collision attacks we know about are incorrect [1], we absolutely know how to break SHA-1 given enough compute, that is, roughly the same resources needed to break RSA-1024. The answer is generic collision finding with parallel rho [2]. [1] https://marc-stevens.nl/research/papers/EC13-S.pdf [2] http://people.scs.carleton.ca/~paulv/papers/JoC97.pdf
Re: Why Google is Hurrying the Web to Kill SHA-1
#74Would be interesting to know how this affects Git version control, which has SHA-1 at its core.
Google's decisions with respect to certificates don't really affect git much. But, if you're curious about how git handles pulling from repositories containing malicious hash collisions, Linus has talked about that in the past: > If it has the same SHA1, it means that when we receive the object from the other end, we will not overwrite the object we already have. > So what happens is that if we ever see a collision,…
Re: Why Google is Hurrying the Web to Kill SHA-1
#75Re: Why Google is Hurrying the Web to Kill SHA-1
#76So where is the fully automated solution for rotating certificates? I've been looking for a CA who will provide an API to send the cert request, an easy way to prove the domain ownership which doesn't involve SMTP, and the signed cert handed straight back from the API, but haven't found it. So far the most I've been able to streamline my certificate requests is to automate generating the CSR, skip setting the MX reco…
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 deployment. Also feel free to email me (address is in my profile).
Sadly, we're still SHA-1 only, because that's all that our certificate authority (RapidSSL) supports at the moment. On the other hand, once we make renewals dead simple, you can just buy 1 year certs and it won't be a big deal upgrading to SHA-2 in a year's time. (After all, even Google is still using SHA-1, but they can easily switch thanks to their 3 month certs and well-oiled cert deployment machinery.)
Re: Why Google is Hurrying the Web to Kill SHA-1
#77I know crypto is not to be taken lightly, and I'm glad people would rather be safe than sorry, and I'll avoid SHA-1 in my own personal security use (`sha256sum` is sha-2 right?). I'm just curious.
Re: Why Google is Hurrying the Web to Kill SHA-1
#78@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.
Re: Why Google is Hurrying the Web to Kill SHA-1
#79Understanding 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…
No collisions published to the public doesn't mean no collisions have been found.
As the article says; “we should assume that the worst vulnerabilities go undisclosed.”