
Next Chrome Update Will Block SHA-1 Certificates - Mojah
https://ma.ttias.be/chrome-version-42-starts-blocking-sha-1-ssl-certificates/
======
FiloSottile
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...](http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-
sunsetting-sha-1.html)

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

[3]:
[https://docs.google.com/presentation/d/1uv_dNkPVlDFG1kaImq7d...](https://docs.google.com/presentation/d/1uv_dNkPVlDFG1kaImq7dW-6PasJQU1Yzpj5IKG_2coA/present?slide=id.i62)

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

~~~
brians
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."

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

~~~
vtlynch
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](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](https://twitter.com/sleevi_/status/584010058897293313)

(Ryan Sleevi works on PKI for Chromium)

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

------
gbl08ma
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?

~~~
vtlynch
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...](https://www.chromium.org/Home/chromium-security/marking-http-as-non-
secure)

~~~
Someone1234
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.

~~~
geofft
Treating self-signed HTTPS as HTTP would be a behavior change with subtle
implications that are hard to get right.

For instance, let's say that I log into
[https://example.com](https://example.com) today, and it has a valid cert (but
no HSTS). It sets a cookie with the "HTTPOnly" and "Secure" flags, indicating
that it should only be sent over HTTPS, and not exposed to e.g. JS. I come
back tomorrow, and [https://example.com](https://example.com) is now sporting
a self-signed certificate.

There are now _three_ possibilities for what's going on here. One is that this
is an attack, so the browser should by default block the site. One is that the
site downgraded to a self-signed certificate because they want to be treated
as HTTP. One is that the site downgraded to a self-signed certificate because
of misconfiguration, but you know out-of-band that it should be treated as
HTTPS (the fingerprint matches what the support phone number tells you, or
you're on a secure network, or something).

Those last two situations are different. In the former, that cookie should no
longer get sent, just as it would not be sent to
[http://example.com](http://example.com). In the latter, it should be sent.

Right now, on the assumption that "intended to downgrade to HTTP with
opportunistic encryption" is rare, the browser will put up a scary alert to
make sure you're verifying the security of the connection out-of-band, and
then send the cookie if you click through the warning. You'd have to somehow
find a way for site owners to signal that they intend to do OE, and they _don
't_ want to be treated as HTTPS -- including not getting secure cookies, not
getting features like web crypto or service workers, etc.

Mozilla is working on exposing opportunistic encryption via the
[http://](http://) scheme, instead of the [https://](https://) one, which
sidesteps all of this: if you happen to connect on https, you'll still get a
cert warning. This approach is also consistent with OE being "equally as
secure" against a slightly nontrivial attacker.

[http://bitsup.blogspot.com/2015/03/opportunistic-
encryption-...](http://bitsup.blogspot.com/2015/03/opportunistic-encryption-
for-firefox.html)

~~~
marcosdumay
If it's using a self signed cert, it's as secure as HTTP, and should be
treated a such.

That means your cookie shouldn't be sent. (And, optimally, the address bar
becomes red.)

If you want to trust the self signed cert, you should be able to do so, and
the optimal place for that is at an scary-looking icon on the same place the
padlock would be.

Other features shouldn't depend only on the protocol used.

------
k33l0r
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-...](https://www.entrust.com/sha-1-deprecation-update-not-
chrome-41-but-chrome-42/)

~~~
acveilleux
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...

~~~
pilif
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.

~~~
eatler
Actually, the root certificate itself simply does not need to be checked at
all, as we need to trust it anyway. In the last verification step, we verify
that the last intermediate certificate in the chain has a valid signature from
the root CA certificate, by using the public (!) key of the root CA
certificate stored in the browser.

------
higherpurpose
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_...](https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html)

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?

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

~~~
BCM43
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.

~~~
rgbrenner
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.

~~~
skrowl
The post title should be updated with this information.

------
omeid2
Training users to ignore SSL warnings. _sigh_

~~~
quonn
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.

~~~
josteink
> 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?

~~~
helyka
That being said. How can I check our cert? The current cert predates my
employment with the county and this is something I have never had to deal
with.

~~~
jamies888888
This is a quick check site I've used previously:
[https://shaaaaaaaaaaaaa.com/](https://shaaaaaaaaaaaaa.com/)

However the proper test should be done using
[https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/)

------
plorg
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/](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.

------
jonathanoliver
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://](https://) portion of the URL is green.

~~~
rgbrenner
_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...](http://googleonlinesecurity.blogspot.be/2014/09/gradually-sunsetting-
sha-1.html)

------
IgorPartola
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...](http://stackoverflow.com/questions/26473076/how-do-i-check-if-my-
ssl-certificate-is-sha1-or-sha2-on-the-commandline)

~~~
giovannibajo1
Or use: [https://shaaaaaaaaaaaaa.com](https://shaaaaaaaaaaaaa.com)

------
verytrivial
"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.

~~~
vtlynch
Use SSLLabs.com for diagnostics.

~~~
verytrivial
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.

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

~~~
smackfu
Actually the Canary I just downloaded is 44.

Version 44.0.2358.0 canary (64-bit)

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

------
scottlinux
On Linux, there is a false positive that occurs
([http://code.google.com/p/chromium/issues/detail?id=437733](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](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...](https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1423031/comments/7)

------
tomjen3
I wonder how many site owners just disable https now.

~~~
jfoster
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.

~~~
josteink
> 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.

~~~
jasonmp85
And when Google starts penalizing their page in rankings because it's
plaintext only? The sysadmins will hear about that from their bosses when
visits drop.

------
smackfu
I'm very confused. I'm on Chrome 41, which shows the XKCD page
([https://xkcd.com/](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.

~~~
pilif
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.

~~~
smackfu
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/](https://forums.xkcd.com/)

------
larrybud
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-...](http://superuser.com/questions/885625/is-there-a-high-level-
roadmap-for-chrome-development)

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

Example with [https://xkcd.com](https://xkcd.com) \-
[http://i.imgur.com/lFlMgly.png](http://i.imgur.com/lFlMgly.png)

------
0x0
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?

~~~
cotillion
StartSSL have sha2 intermediates nowdays.
[https://www.startssl.com/certs/class1/sha2/pem/](https://www.startssl.com/certs/class1/sha2/pem/)

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

~~~
acveilleux
You guess correctly.

~~~
0x0
Actually it seemed work by just updating the intermediate chain cert. Still
need to try to re-issue leaf certs that are actually signed with sha1...

------
thwarted
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
That seems to be common at least with the GlobalSign-backed CAs that I've
seen. Not sure about others.

