Hacker News Reader

Comment by eastdakota | Hacker News Reader

While I'm a huge fan of what you're doing in terms of crypto at Google, it's hard for me to see this decision as anything other than reckless. I think we'll be able to show a number of empirical examples of how, over the coming months, it will make the web a less secure place as sites that we're just now starting to convince to adopt crypto will stop.

I do at least hope that you will make efforts to alert more of the general public of what's coming and how they can prepare ahead of time. While at CloudFlare we follow the crypto lists closely and know there have been discussions for some time, dropping this news quietly for general public consumption on the Google blog on a Friday afternoon was... an odd choice.

And, for the record, for the last two years we've made it one-click simple for any of the millions of sites on CloudFlare to alert their users to move off out-of-date browsers:

https://www.cloudflare.com/apps/abetterbrowser

View on HN

Unfortunately we don't have the technical ability, nor do people have the mental capacity, to cope with multiple URL schemes for different "levels" of security. SHA-1 limits the security for everyone and all uses. And if sites are worried about compat, Google will be doing this transition along with everyone else. That's a good tailwind to ride.

If Microsoft's 2016/2017 deadline is reckless, what SHA-1 deprecation date would be right by your measure? Some have suggested ~2020 (5 years issuance from 2015). Would you really be happy depending on SHA-1 in 2020?

(Edit: on re-read, the 2020 suggestion sounds like a strawman - but that's actually what we were on the road towards and we may not have even managed that.)

You say that Google will be doing this transition along with everyone else, but you won't be feeling the same pain. Google's current cert expires November 24th, 2014, so when you extend it then it will be for 1 year and your new cert will expire before January 1st, 2016 which is pretty convenient for you because that cert (even if it is SHA-1) will still show up as a green bar through Chrome 41 so it will have no impact for you. I also second eastdakota's response that this was pretty crappy to drop as a Friday afternoon announcement.

(Google's certificates only last three months and that's not because of this announcement.)

The transition that I'm talking about is the transition to SHA-256 overall. If you're in a position where your CA sold you a certificate that they shouldn't have then I feel sorry, but if you're blaming us for that then I think you're pointing in the wrong direction.

I would guess that most buyers of certs are not technically sophisticated enough to know that they should have been looking for a cert with a specific encryption algo, especially if they bought a very long-lived cert x years ago. That said, I'm guessing that most reasonable cert providers will allow reissues.

What would be the technical challenges facing offering free wildcard certs? Is it just engineering time, or is there something more fundamental? That seems like it would do much more for web security than pushing for higher minimum encryption standards on certs would...

Google, CloudFlare and a handful of the technically sophisticated organizations have the ability to return different certificates depending on the connecting browser. Your argument would be far more persuasive if Google were really biting the bullet and dropping support for SHA1 even when an old browser connects. I assume that's not what you're doing, but please correct me if I'm wrong.

If you are returning two different certificates for two different situations at Google.com, the least you could do is dedicate some of your vast engineering resources to making the plugins to support such a setup production ready. If Google uses it's technical sophistication to avoid the pain while the rest of the web burns then that's, at best, hypocritical.

I'll make you this deal: if you do it for Apache, we'll do it for NGINX. That's the right thing to do. As would be making SSL certs free, but that's a conversation for another day.

Actually, Apache already supports deployments with more than one certificate for the same host: http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertifi...

Is it possible to specify both a RSA-SHA1 cert and a RSA-SHA256 cert that way, or would it have to be RSA-SHA1 and ECDH-SHA256?

Apache/OpenSSL would have to assume that pre-TLSv1.2 clients support only SHA1 because there's no signature_algorithms extension, but for TLSv1.2 clients can Apache/OpenSSL choose between a RSA-SHA1 cert and a RSA-SHA256 cert?

The reason I ask is because ECDH certs seem to be even harder to come by than RSA-SHA256 certs right now.

I haven't tried, but I think at the moment Apache supports only multiple certificates with different private key algorithms. Anything else would have to be implemented in custom code. IIRC, OpenSSL 1.0.2 (not yet released) has better support for multiple certificate chains on the same server.

> Your argument would be far more persuasive if Google were really biting the bullet and dropping support for SHA1 even when an old browser connects.

That's certainly the plan. What did I say that suggests otherwise?

Will www.google.com continue to be available over HTTP? If so, the old browsers will still be able to use Google search by simply avoiding HTTPS. That would lessen the impact on Google, in contrast to sites that follow best practice and unconditionally redirect HTTP to HTTPS.

Reply on news.ycombinator.com