Next Chrome Update Will Block SHA-1 Certificates

https://ma.ttias.be/chrome-version-42-starts-blocking-sha-1-ssl-certificates/

by Mojah • 11 years ago

199 94 11 years ago

ma.ttias.be

omeid22• 11 years ago

Training users to ignore SSL warnings. sigh

quonn• 11 years ago

I think Chrome only shows the red sign in the address bar, not the usual warning page.

This step was announced some time ago, and since certificates usually need to be replaced frequently, there should be very few problematic certificates, if the CAs did their job.

josteink2• 11 years ago

This step was announced some time ago, and since certificates usually need to be replaced frequently

Most people will buy certs valid for a few years, or around a couple of dozen Chrome-releases, and forget about them until they expire.

From my experience, among the things deployed in the world of IT, I would argue they are among the things replaced most infrequently.

So I'm curious... What makes you say certificates needs to be replaced frequently? What's the use-cases you are referring to?

geofft2• 11 years ago

Yes, that's correct. Due to a subtle bug (https://crbug.com/472978), my beta-channel Chromebook thinks my personal website has a SHA-1 intermediate, so I've seen this happen. There's no certificate warning / interstitial, just the red slash through the "https".

crucialfelix• 11 years ago

It looks pretty bad and alarming. I'm on canary, so I've seen the warning on my own site. With only a weeks warning I have to get this solved before normal customers start seeing it. A big nasty red strike through our reputation.

there should be very few problematic certificates, if the CAs did their job.

The cert was bought through Network Solutions in the past year. They are not exactly amateurs.

I've already had to spend 45 minutes researching and trying to solve this and I still have to waste more time resolving this.

omeid22• 11 years ago

It is still bad. Most users don't understand the difference. And the "in for a penny, in for a pound" mentality is more common than one would hope.

k33l0r• 11 years ago

Something not mentioned in the article: only SHA-1 certificates with expiry dates past the 1st of January 2017 will be marked as “affirmatively insecure.”

https://www.entrust.com/sha-1-deprecation-update-not-chrome-...

acveilleux2• 11 years ago

The problem is that this is the case for pretty much all CA and intermediate CA certs using SHA-1. 2020 and 2030 are popular expiry dates...

pilif2• 11 years ago

It's a problem for intermediates, yes.

You'd have to request a re-issue by an intermediate which itself is certified using something better than sha-1.

It's not, however a problem for the roots because those are checked by browser using the actual private key they know by virtue of the root actually be embedded in the browser/os itself instead of just checking the SHA-1 signature.

Someone12345• 11 years ago

Which is extremely bad practice in its own right. Unless you have an offline master (which you should, by the way) there's no justification for a 5+ year expiration. Keys need to be rotated.

PS - A lot of CA software makes doing offline CAs extremely hard. I'm talking about Microsoft's stuff in particular.

agwa• 11 years ago

Chrome only cares about the hash algorithm of the intermediate certificate(s) if the end-entity cert is expiring after 2016. So a SHA-1 certificate expiring in 2015 won't be marked insecure even if it's signed by a SHA-1 intermediate expiring in 2020.

See: http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually...

0x03• 11 years ago

I noticed being set up with a StartSSL intermediate cert that expires in 2017, which is signed with SHA1. I guess that's going to cause problems?

cotillion2• 11 years ago

StartSSL have sha2 intermediates nowdays. https://www.startssl.com/certs/class1/sha2/pem/

0x03• 11 years ago

I guess using these will still require a re-issue of existing leaf certificates, so the signature matches the sha2 intermediate?

Dylan16807• 11 years ago

The expiration date of the intermediate doesn't matter.

higherpurpose• 11 years ago

For a reminder why we need to move away from SHA1, here are some calculations on what computing power is needed for SHA1 collision attacks. Keep in mind the worst possible attack there is from a "crime syndicate". Now multiply that capability by say 100 to get what an intelligence agency could achieve.

https://www.schneier.com/blog/archives/2012/10/when_will_we_...

I think Google is sensible about wanting to kill SHA1 earlier than 2018 when a "crime syndicate can provoke a collision attack." Why should they wait until the last day even for that?

xorcist• 11 years ago

It seems this was supposed to go in Chrome 41, but was deferred to Chrome 42.

What is the official communications channel from Google on these matters? I can't find anything expect the blog post from September, and absolutely nothing on the supposed deferral. The deadline came and went and I was left crying wolf.

I need something to point to in order to get people to understand the severity of this, and Google is not making it easy.

jfoster3• 11 years ago

They also could do a better job of informing webmasters exactly what is wrong with their certificates. If you go to XKCD, for example, Chrome's handling of https is very scary-looking and it has a message about the site using "obsolete cryptography", but it doesn't call out SHA-1 as the culprit or point toward an article explaining what's wrong & how to fix it.

vtlynch6• 11 years ago

"Obsolete cryptography" does NOT refer to SHA-1. It refers to using old cipher suites which are not viewed as secure.

One of the security team engineers also acknowledged that this is an unclear warning and that they are working on it.

https://twitter.com/vtlynch/status/574301319428702208

smackfu7• 11 years ago

Especially considering the official announcement blog post still says Chrome 41.

http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...

vtlynch6• 11 years ago

I agree that the original article should be updated. The delay seems to be due to some "late-breaking chain building bugs": https://twitter.com/sleevi_/status/585429689646260224

This older Twitter thread kinda alludes to some problems with CAs being compliant in time: https://twitter.com/sleevi_/status/584010058897293313

(Ryan Sleevi works on PKI for Chromium)

yuhong2• 11 years ago

Background: CAs often provide cross certificates signed with SHA1 to older roots for browsers that don't have the newer roots installed.

skrowl2• 11 years ago

That's actually pretty hilarious considering that ajax.googleapis.com (one of google's public CDNs) still uses SHA-1 certs.

rgbrenner4• 11 years ago

It expires in June, which means it's not affected (must have an expiration after 1/1/2016 for a warning)

http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...

BCM43• 11 years ago

My understanding is that if the cert is valid for less that three months, it's still marked as OK for now. That cert is valid for 3/19/15-6/16/15.

rgbrenner4• 11 years ago

they're marked ok because they expire before 2016. If you had a 3 month cert issued in q4-2015 that expires in early 2016, it'll display a warning.

cbhl2• 11 years ago

Google is pretty big. It's hard to get everyone to move in the same direction. ;)

tomjen3• 11 years ago

I wonder how many site owners just disable https now.

jfoster3• 11 years ago

Good point. There is potential for this to do more harm than good. The handling of insecure sites is very plain and non-alarming. The handling of https sites using SHA-1 is red & scary-looking. If the Chrome warning were clearer on what is wrong and what should be done to remedy it, there would be less risk of that happening.

josteink2• 11 years ago

If the Chrome warning were clearer on what is wrong and what should be done to remedy it,

You mean if Chrome, like MSIE in the old days, had huge dialog windows with lots of text, which users learned to instinctively ignore and click away... This would somehow play out differently now than it did back then.

It wont.

I'm guessing lots of "lazy"/over-burdoned sysadmins will just disable HTTPS to make the Chrome-users shut up, and then he will forget about it, leaving the site HTTP-only.

Someone12345• 11 years ago

I actually agree. They should just yellow bar all the SHA-1 stuff. But will such a subtle approach force CAs to do the right thing? Unfortunately people have been bugging them for a long time, and it seems only a metaphorical gun to their heads has had any effect.

I agree that HTTP being white and "happy" and SHA-1 giving the "DANGER WILL ROBINSON" scare alert, is inconsistent/wrong. That's more a HTTP issue however rather than a SHA-1 one (i.e. HTTP needs to be marked insecure).

gsnedders• 11 years ago

Google have done a lot of studies to try and reduce the number of click-throughs of TLS warnings, especially when it comes down to the wording of the message.

Someone12345• 11 years ago

None, I'd expect.

This whole thing actually should never impact website admins. It is aimed to "encourage" CAs to do the right thing and stop publishing any NEW certificates with SHA-1. That's why they set the deadline for SHA-1 so far into the future, so that even if a certificate was created six months ago, it shouldn't have been impacted (when they first announced this).

So if you just leave any SHA-1 certificates in place, and then when they naturally expire you get the replacement from your CA, that replacement should be SHA-256. You may not even notice.

The only sites that MIGHT be impacted are sites who have CAs who are frankly asleep at the wheel. If your CA continued to issue 3 year certificates this year, you might be impacted, but I'd suggest you take that up with them and request they re-issue for free as SHA-256 (which they damn well better).

A lot of people think half the internet will break, I disagree. If you look at the actual requirements (expiration date + SHA-1), very few sites right now fall afoul of that.

toast02• 11 years ago

This whole thing actually should never impact website admins.

I had to do a lot of work for this, because I need to support clients that can't accept a SHA-2 cert, as well as Chrome which won't accept my SHA-1 cert because it expires in 2016. The SSL termination I use didn't know how to do that, so I had to write a patch. Thanks a lot Chrome.

driverdan• 11 years ago

The Chrome Canary build is at version 42, and has started blocking SSL certificates that still use the SHA-1 algorithm.

Actually Chrome Beta is on 42. Canary is on 43.

smackfu7• 11 years ago

Actually the Canary I just downloaded is 44.

Version 44.0.2358.0 canary (64-bit)

jonathanoliver• 11 years ago

I was looking at my certificate chain and I noticed that the root certificate uses SHA1. Any ideas if this will affect the root certificate? I'm using AddTrust External CA Root.

Right now in Chrome 41, the https:// portion of the URL is green.

rgbrenner4• 11 years ago

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...

pwnna• 11 years ago

Root certificates are not affected.

gbl08ma• 11 years ago

I have a free SHA-1 signed cert from StartSSL that only expires in June 2015. The rest of the chain is SHA-256 signed (at least this is what Chrome tells me). Will a cert in these conditions start showing a red lock with the next version of Chrome? If yes, is there a way I can reissue the StartSSL certificate with SHA-256 signing, without having to pay? A quick Google search tells me there isn't.

I'm anxiously waiting for Let's Encrypt to launch, as StartCom is kinda shady with the free cert thing (remember what happened with Heartbleed WRT revoking?). Until then, I begin to wonder if it wouldn't be best to (ugh) disable HTTPS for Chrome 42+ users, since most people will perceive a red lock thing on their status bar as "less secure" than the "silently gray" HTTP (even if technically, that's obviously not the case). If Google decides SHA-1 is so bad that it deserves being visibly marked as insecure, then why don't they also show a red cross on HTTP sites?

EDIT: oops, missed the "valid past 2015" part. My question is still valid, isn't insecure HTTP more deserving of a red cross than SHA-1 certs that expire in, say, 2016?

rgbrenner4• 11 years ago

certs that expire before jan 1 2016 are unaffected.

And there is a proposal to mark all http traffic as insecure also: https://www.chromium.org/Home/chromium-security/marking-http...

MichaelGG• 11 years ago

No, because HTTP doesn't imply security, whereas HTTPS does. If someone follows an HTTPS link, then that's an intention for security and should be respected. (Though it's not a bad idea to put some sort is warning indicator on HTTP, just to help reinforce things.)

marcosdumay3• 11 years ago

Just when was the last time you typed the "https://" at the address bar of your browser (accessing a site that isn't yours)?

People just don't think this way. Well informed people (a small minority) will check the padlock after the site loads. Most people will use an HTTP site thinking it's secure.

vtlynch6• 11 years ago

If they are going to show a green padlock, the connection needs to be reasonably secure, because the icon is supposed to indicate as such. With HTTP there are no icons being shown indicating you are secure, so there should be no expectation of security.

Chrome's security team is working on a proposal to show negative UI indicators to sites using HTTP:

https://www.chromium.org/Home/chromium-security/marking-http...

Someone12345• 11 years ago

That's always been a massive pet peeve of mine. HTTP gets a "free pass" (white/generic) but if you dare to self sign, BIG RED SCARY ALERT. Yet nobody thinks self-signed is less secure than HTTP, the worst you could claim is "equally as secure" (when the reality is it makes it subtly harder to eavesdrop, but provides no MITM protections at all).

They should just give HTTP and self-signed a red bar, and stop with the silly warning pages (unless the site previously had a CA signed certificate and HSTS). Just treat HTTPS self-signed the same as HTTP, that's all I ask.

rictic• 11 years ago

most people will perceive a red lock thing on their status bar as "less secure" than the "silently gray" HTTP (even if technically, that's obviously not the case)

This is true. I believe that Chrome is experimenting with marking http as insecure with yellow text.

qrmn• 11 years ago

Red text, with a lock with an X next to it - at least, that's what's checked in at the moment.

smackfu7• 11 years ago

I'm very confused. I'm on Chrome 41, which shows the XKCD page (https://xkcd.com/) with no lock and the blurb about outdated security settings. I installed Chrome Canary, which is on version 44, and I was expecting the red X. But instead I'm getting a green lock and no warning message. What's up with that? Is this code not deployed to Canary yet?

Edit: installing version 42 does show the red lock, so I guess it's a Canary issue.

blinkingled2• 11 years ago

Even on Chrome 41 (64b, Win) if you click on the white security indicator it shows a yellow warning triangle and warns you about it using "outdated security settings" which may prevent future versions of chrome from safely accessing it.

smackfu7• 11 years ago

Yeah, I find it odd that they used that white page security indicator instead of the yellow yield warning sign.

pilif2• 11 years ago

TBH, xkcd is using pretty outdated crypto all over the place, not just the sha-1 issue (though that's there too).

xkcd.com still supports SSL3 which can't really be trusted any more and it either supports really bad 56 bit single DES or RC4, neither of which are adequate any more.

Ok. it's a web comic, so SSL isn't of that much importance, but I would certainly prefer chrome to warn me when visiting a site using these settings, so I can make a decision whether to type in any credentials or not.

smackfu7• 11 years ago

It should also be mentioned that they certainly aren't actively pushing people to the secure site. You would only get it if you manually typed it in, or are using HTTPS Everywhere.

And the forums, the only place you would actually log in, don't even have a secure version: https://forums.xkcd.com/

verytrivial2• 11 years ago

"If you haven't already, check your certificates." -- I'd love too, but I use Chrome for Android so I only get a Magic 8-ball level of detail.

vtlynch6• 11 years ago

Use SSLLabs.com for diagnostics.

verytrivial2• 11 years ago

Yes, but that gives details about the certificate used between SSLLabs.com and the target server, not me and the target server. There is absolutely no requirement these two certs are the same. That's sort of the point of having a local check.

IgorPartola• 11 years ago

To quickly check multiple sites:

    openssl s_client -connect <host>:<port> < /dev/null 2>/dev/null | openssl x509 -text -in /dev/stdin | grep "Signature Algorithm"

From http://stackoverflow.com/questions/26473076/how-do-i-check-i...

giovannibajo12• 11 years ago

Or use: https://shaaaaaaaaaaaaa.com

scottlinux• 11 years ago

On Linux, there is a false positive that occurs (http://code.google.com/p/chromium/issues/detail?id=437733).

Debian has a fix in experimental. However the bug is seeing no action. Please Debian push this update out:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774195

Ubuntu fixed this in Feb 2015:

https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1423031/c...

FiloSottile• 11 years ago

Author of the embedded tweet here. I'd like to clarify, since my tweet was vaguely imprecise and this post sadly got it wrong.

The official timeline is on Google Online Security blog [1]. BUT you have to replace "41" with "42" [2].

SO, what changes? From version 42, the current "beta", which according to schedule [3] should become "stable" in a week on the 14th:

- certs that expire in 2016 will be yellow

- certs that expire after 2016 (like xkcd's) will be red

Nothing else will change after 42, and Firefox will follow next year [4]. Certs expiring in 2015 are fine.

Also note that this only affects the lock icon and "https" color, there will be no warning screen AND no connection will be blocked.

EDIT: thanks to the author for amending.

[1] http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually...

[2] https://twitter.com/sleevi_/status/585429689646260224

[3] https://docs.google.com/presentation/d/1uv_dNkPVlDFG1kaImq7d...

[4] https://twitter.com/sleevi_/status/585429901848608769

brians• 11 years ago

Thanks for the reminder that this is coming. I think that sites whose sub-resources come under certs under long-lived SHA-1 intermediates may have problems—they'll be treated as "active mixed content."

thwarted• 11 years ago

ma.ttias.be has a certificate issued by a CA with a Common Name of "AlphaSSL CA - SHA256 - G2". Is this going to be common, putting crypto settings in the CN and creating new sub-CAs when crypto settings change?

inigoesdr• 11 years ago

That seems to be common at least with the GlobalSign-backed CAs that I've seen. Not sure about others.

hkdobrev• 11 years ago

Chrome version 43 (dev channel atm) will actually show https in red and with a strikethrough.

Example with https://xkcd.com - http://i.imgur.com/lFlMgly.png

sandstrom• 11 years ago

Does anyone know how non-primary domains are handled? I.e. JS/fonts/etc from outside the primary domain (analytics services and the like).

There is a 'mixed content' warning when these aren't SSL, but I haven't read anything about a similar warning if they are on SHA1.

fyarebox• 11 years ago

Firefox currently* shows a red warning in the console, but still loads normally. I can't press F12 on any half-popular site, including most of Google, without seeing that wall of red.

I assume something similar will happen from Chrome. Hopefully they'll add an option to suppress or aggregate the messages.

* I'm using the developer edition, which is on Aurora. I don't think this is dev. edition specific, but I've never checked.

plorg• 11 years ago

I noticed this a couple of weeks ago when visiting my (local) bank's website (I'm in Chrome beta, v42 at that point) - the landing page had a red slash through the https. The e-banking site is operated by a third party on a different domain, with certificates which Chrome accepts.

I checked the site through https://www.ssllabs.com/, and was confused when it gave the site an A rating. Eventually I googled the text from the certificate info panel, and that search led me to the blog where Google outlined their deprecation plan.

I contacted the bank and their web host had it updated later that day.

I do wish that Google would give a clearer message to the user when displaying the red slash. It was far from clear to me what the problem was, even after I clicked to check out the purported certificate error.

larrybud• 11 years ago

Slightly off topic, but why is there no high level roadmap for changes like this? It would be nice to see a gantt type chart showing releases and major changes like this that would affect user experience.

I asked this question on superuser but got no replies. http://superuser.com/questions/885625/is-there-a-high-level-...

Next Chrome Update Will Block SHA-1 Certificates

Related Stories