Next Chrome Update Will Block SHA-1 Certificates(ma.ttias.be)
ma.ttias.be
Next Chrome Update Will Block SHA-1 Certificates
https://ma.ttias.be/chrome-version-42-starts-blocking-sha-1-ssl-certificates/
96 comments
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."
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.
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.
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)
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)
Background: CAs often provide cross certificates signed with SHA1 to older roots for browsers that don't have the newer roots installed.
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.
"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
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
What's also odd is that it says "obsolete security" in that section of the security pane, but it still has a green lock next to it, not the yellow warning. So the text says one thing and the iconography says another, which is very confusing.
Yes, I agree,Its not ideal. But I follow the industry very closely and I trust that Google's team is working on it and nearing some major improvements.
Especially considering the official announcement blog post still says Chrome 41.
http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...
http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...
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?
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?
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...
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...
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.
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.
Well one of the problems is that SSL does two things: Server Authentication and Encryption. Since there is nothing backing the identity of a self-signed certificate, it can easily masquerade as whatever it wants.
Yes, a CA-issued cert and a self-signed are equilvent when it comes to encryption. But with Server Authentication, its too easy for self-signed certificates to mislead people, and that is deserving of the red-X in my opinion.
You may be interested in the Opportunistic Encryption that Firefox has just enabled: http://bitsup.blogspot.it/2015/03/opportunistic-encryption-f...
It allows for SSL encryption with a self-signed, and ignores authentication. So not red-x, but no green padlock either.
EDIT: Opportunistic Encryption seems to have caused some problems: https://www.mozilla.org/en-US/security/advisories/mfsa2015-4...
Yes, a CA-issued cert and a self-signed are equilvent when it comes to encryption. But with Server Authentication, its too easy for self-signed certificates to mislead people, and that is deserving of the red-X in my opinion.
You may be interested in the Opportunistic Encryption that Firefox has just enabled: http://bitsup.blogspot.it/2015/03/opportunistic-encryption-f...
It allows for SSL encryption with a self-signed, and ignores authentication. So not red-x, but no green padlock either.
EDIT: Opportunistic Encryption seems to have caused some problems: https://www.mozilla.org/en-US/security/advisories/mfsa2015-4...
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 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 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. 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:// scheme, instead of the 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-...
For instance, let's say that I log into 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 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. 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:// scheme, instead of the 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-...
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.
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.
Well yes, but is it self-signed (or otherwise "invalid" cert) because the user was MITM or because that's what the server handed over? The former really does deserved a BIG RED SCARY ALERT, the later not so much. But distinguishing those two reliably is not feasible, so browsers fail-safe into assuming it's a potential MITM.
> Well yes, but is it self-signed (or otherwise "invalid" cert) because the user was MITM or because that's what the server handed over?
Is it HTTP because the user was MITM or because that's what the server handed over?
Again, why one rule for HTTP and another for self-signed. It is inconsistent. HTTPS sites being hacked and turned into HTTP is a real and common problem, yet where is HTTP's red bar of danger?
Is it HTTP because the user was MITM or because that's what the server handed over?
Again, why one rule for HTTP and another for self-signed. It is inconsistent. HTTPS sites being hacked and turned into HTTP is a real and common problem, yet where is HTTP's red bar of danger?
If you send an HTTPS request you can't get back HTTP. HTTP vs. HTTPS was chosen by the client. A MITM cannot downgrade HTTPS to HTTP.
And thus the difference in behaviors because of the difference in intent. If you initiate HTTPS you intend for it to be secure and failure to do that is a fail condition, big red warning, this request faild. If you initiate HTTP you did not intend for it to be secure.
Yes this is a problem of technicals vs. UX but it's not arbitrary or random.
And thus the difference in behaviors because of the difference in intent. If you initiate HTTPS you intend for it to be secure and failure to do that is a fail condition, big red warning, this request faild. If you initiate HTTP you did not intend for it to be secure.
Yes this is a problem of technicals vs. UX but it's not arbitrary or random.
Merely a wonder out loud. How does the average user respond to the site not loading?
Lets say for example I managed to break into a Facebook edge server and disable port 443 so users get a connection failed message. On average would they themselves switch to http (or just type facebook.com into the browser, which interprets as the HTTP version) and receive my spoofed login page?
Please disregard the fact it would be near impossible to get into Facebook's edge servers and that they'd probably hit a different one on the reload, etc, etc. Merely used Facebook as an example as it's hugely popular and arguably addictive site (users need their 'fix', damn the security!)
Lets say for example I managed to break into a Facebook edge server and disable port 443 so users get a connection failed message. On average would they themselves switch to http (or just type facebook.com into the browser, which interprets as the HTTP version) and receive my spoofed login page?
Please disregard the fact it would be near impossible to get into Facebook's edge servers and that they'd probably hit a different one on the reload, etc, etc. Merely used Facebook as an example as it's hugely popular and arguably addictive site (users need their 'fix', damn the security!)
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.)
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.
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.
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...
And there is a proposal to mark all http traffic as insecure also: https://www.chromium.org/Home/chromium-security/marking-http...
> 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.
This is true. I believe that Chrome is experimenting with marking http as insecure with yellow text.
Red text, with a lock with an X next to it - at least, that's what's checked in at the moment.
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-...
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...
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.
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.
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.
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...
See: http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually...
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.
PS - A lot of CA software makes doing offline CAs extremely hard. I'm talking about Microsoft's stuff in particular.
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?
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?
That's actually pretty hilarious considering that ajax.googleapis.com (one of google's public CDNs) still uses SHA-1 certs.
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...
http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...
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.
Google is pretty big. It's hard to get everyone to move in the same direction. ;)
[deleted]
Training users to ignore SSL warnings. sigh
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.
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.
> 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?
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?
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.
This is a quick check site I've used previously: https://shaaaaaaaaaaaaa.com/
However the proper test should be done using https://www.ssllabs.com/ssltest/
However the proper test should be done using https://www.ssllabs.com/ssltest/
If you view your website in chrome, you can click on the lock icon in the address bar. Go to the connection tab -> Click certificate information -> Details Tab.
You should see one of the entries should be signature algorithm. SHA-1 is a problem. SHA-224 or higher means the cert is on SHA-2 which is okay.
If you are in Firefox, you can also click the padlock icon, and click on the more information button.
Yeah, *.ycombinator.com is using a 5-year certificate which was issued in 2014.
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.
> 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.
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".
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.
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.
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.
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.
Right now in Chrome 41, the https:// portion of the URL is green.
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-su...
Root certificates are not affected.
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"
"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.
Use SSLLabs.com for diagnostics.
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.
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.
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.
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.
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.
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...
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...
I wonder how many site owners just disable https now.
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.
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.
> 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.
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.
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.
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).
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).
> 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.
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.
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.
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.
I don't mean they should present the message to all users. Currently, even if you go into the certificate details without being prompted, there is nothing there saying anything to the effect of "SHA-1 is insecure; if you are the webmaster, get this certificate issued with SHA-2"
[deleted]
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.
Edit: installing version 42 does show the red lock, so I guess it's a Canary issue.
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.
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.
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/
And the forums, the only place you would actually log in, don't even have a secure version: https://forums.xkcd.com/
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.
Yeah, I find it odd that they used that white page security indicator instead of the yellow yield warning sign.
It's an aggressive and controversial change - there isn't really much of a reason to reject SHA-1 certificates so early. May be that's why they want to be less alarming at least in the interim.
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-...
I asked this question on superuser but got no replies. http://superuser.com/questions/885625/is-there-a-high-level-...
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
Example with https://xkcd.com - http://i.imgur.com/lFlMgly.png
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?
StartSSL have sha2 intermediates nowdays.
https://www.startssl.com/certs/class1/sha2/pem/
I guess using these will still require a re-issue of existing leaf certificates, so the signature matches the sha2 intermediate?
I'm not 100% sure, but I don't think so. Simply re-signing the same intermediate certificate (by the CA) with a better hash should allow the new intermediate cert to be a drop-in replacement, as the private/public keys didn't actually change.
You can probably download their latest intermediate certificate or bundle (https://www.startssl.com/certs/) to resolve the error.
Notice how their current intermediate cert has a SHA256 hash, yet they don't offer an "old" intermediate cert which would supposedly be required for older certificates.
You can probably download their latest intermediate certificate or bundle (https://www.startssl.com/certs/) to resolve the error.
Notice how their current intermediate cert has a SHA256 hash, yet they don't offer an "old" intermediate cert which would supposedly be required for older certificates.
No, because their intermediate is the same public key, resigned with SHA2. So you just need to update it in your chain.
I belive the problem was the signature on the intermediate. The same intermediate has probably been signed again with sha2. Or maybe it was cross signed somehow...
I just replaced the intermediate cert and the warnings went away.
I just replaced the intermediate cert and the warnings went away.
You guess correctly.
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...
The expiration date of the intermediate doesn't matter.
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?
That seems to be common at least with the GlobalSign-backed CAs that I've seen. Not sure about others.
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