Google.com is still SHA-1 but they green-light their domains | Hacker News Reader

Google.com is still SHA-1 but they green-light their domains

tls.so

35 pointspmccarren12 comments

The certificate is expiring in less than three months. Chrome has always been clear that they don't care about SHA-1 certs that are expiring within 2015. They just want to make sure that when you renew those certs, you renew as SHA-256.

http://googleonlinesecurity.blogspot.com/2014/09/gradually-s...

"Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as 'secure, but with minor errors' [i.e., the lock-with-yellow-triangle you also get for mixed content].

"Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as 'affirmatively insecure'. Subresources from such domain will be treated as 'active mixed content'."

This just hit me. I was doing some work on my side-business site and noticed a big red error for the SSL cert. Luckily the process to reissue a new cert was pretty straight forward and I gotten taken care of the same day.

My SSL provider (namecheap) did send me one email at some point, but I'm sure I glossed over it because I didn't realize this change was coming.

Their certs expire before the deadline (only valid for 3 months) so they show up as green.

They seem to get new certs every three months.

How useful is it to get new certs that often? I always had the impression that certs live only a certain time so that revocation lists can be pruned and don't grow unbounded over time, or is there anything else to it?

If you think a cryptosystem is weak, so that it will take years to break a key (instead of millenia), then reducing key expiration times to months seems like a good way to buy some time.

And it incentivizes moving to a system that's not so weak.

That's certainly part of it, but at some point there's a qualitative shift: if you make certificate lifetimes short enough, you don't need to bother with revocation lists at all. Since CRLs are unwieldy no matter how you do them, standard practice for revocation is OCSP, preferably through OCSP stapling, where you carry a signed response from the CA (valid for about a day) saying that your certificate hasn't been revoked. Effectively this is just a more complicated way of getting a new certificate about every day.

The other part is that, if something about a cert turns out to have been a bad idea, it's much better to only have to wait a few days or even months than to wait a few years. "Something" could be the algorithm (precisely why Chrome is yelling at SHA-1 certs that will still be valid in 2017, even though there's no attack as of right today). It could also be certification practices: if the community decides that, say, certificates without the `subjectAltName` extension need to be deprecated because the CN field is underspecified, nobody's going to want to do revocations for that. So you are stuck waiting until all current certs expire and get renewed to follow current best practices.

Another benefit: If you have that infrastructure in place then you don't run into problems where everyone forgot that the certificate was expiring. That error has hit so many sites/services... even huge ones with multi-million-dollar budgets and hundreds of people working on it.

Which means that less than 3 months ago, they got a cert which was SHA-1. Why would they do that?

I noticed that they use a 3 tier system. But even SHA-1 encryption, I wanted to talk about how it compares to the use of RC4 on AES. I am still learning about the effectual uses of encryption but it would seem to me that being able to use modulo as you swap indeces throughout the hash would enable more coerce authentication if not for the sole reason that it would be difficult to find out the derivative of both of the numbers that gave modulo. VS AES whose algorithm uses a reverse mapping of the hash in order to equate the distance from left to right between the indeces.It is said that RC$ is less secure as a method because of it is more prone to WEP attacks due to its inability to factorialize an instance of teh hash suring the scheduling phase, while it only allows for a 64 bit size whereas AES is more sutiable for 256 bit. It's adavtnage lies in large network systems but would be suitable for API distributions. In effect its PRG would be effective in taking a modulo variable being parsed as K[] progresses through the list in a function that combines it along wth the inverse natural e in to create an limit as protection from FMS attacks even at a byte level. Thanks for letting me comment and learn.

Beyond the expiry fact, I think google does pinning for their certs. If you pin your certs you don't really care a lot whether the ca is compromised, and here it's just the ca that's got sha1 signing, not the actual cert which is sha2.

No, the *.google.com cert has SHA-1. It's just that it expires before 2016, as they get issued for 3 months.

You're right. I must have imagined the SHA-256 part.

Reply on news.ycombinator.com