13 ms·

Next Chrome Update Will Block SHA-1 Certificates

199 points by Mojah 12y ago

omeid2 12y ago
Training users to ignore SSL warnings. sigh
- quonn 12y 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.
  - omeid2 12y 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.
  - josteink 12y 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?
    - helyka 12y ago
      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.
      - grhino 12y ago
        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.
      - jamies888888 12y ago
        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/
      - marcosdumay 12y ago
        If you are in Firefox, you can also click the padlock icon, and click on the more information button.
    - smackfu 12y ago
      Yeah, *.ycombinator.com is using a 5-year certificate which was issued in 2014.
  - geofft 12y ago
    Yes, that's correct. Due to a subtle bug (https://crbug.com/472978 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 12y 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.
k33l0r 12y 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-41-but-chrome-42/ https://www.entrust.com/sha-1-deprecation-update-not-chrome-...
- acveilleux 12y 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...
  - pilif 12y 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.
    - eatler 12y ago
      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.
  - Someone1234 12y 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 12y 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-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually...
0x0 12y 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?
- cotillion 12y ago
  StartSSL have sha2 intermediates nowdays. https://www.startssl.com/certs/class1/sha2/pem/ https://www.startssl.com/certs/class1/sha2/pem/
  - 0x0 12y ago
    I guess using these will still require a re-issue of existing leaf certificates, so the signature matches the sha2 intermediate?
    - acveilleux 12y ago
      You guess correctly.
      - 0x0 12y ago
        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...
    - cotillion 12y ago
      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.
    - dtech 12y ago
      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/ 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.
higherpurpose 12y 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_se.html 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 12y 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.
- smackfu 12y ago
  Especially considering the official announcement blog post still says Chrome 41. http://googleonlinesecurity.blogspot.be/2014/09/gradually-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...
- jfoster 12y 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.
  - vtlynch 12y 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 https://twitter.com/vtlynch/status/574301319428702208
    - smackfu 12y ago
      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.
skrowl 12y ago
That's actually pretty hilarious considering that ajax.googleapis.com (one of google's public CDNs) still uses SHA-1 certs.
- rgbrenner 12y 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-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...
- BCM43 12y 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.
  - rgbrenner 12y 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.
    - skrowl 12y ago
      The post title should be updated with this information.
- deleted 12y ago
  [deleted]
- cbhl 12y ago
  Google is pretty big. It's hard to get everyone to move in the same direction. ;)
tomjen3 12y ago
I wonder how many site owners just disable https now.
- jfoster 12y 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.
  - josteink 12y 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.
    - jasonmp85 12y ago
      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.
  - Someone1234 12y 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 12y ago
driverdan 12y 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.
- smackfu 12y ago
  Actually the Canary I just downloaded is 44. Version 44.0.2358.0 canary (64-bit)
jonathanoliver 12y 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:// https:// portion of the URL is green.
- rgbrenner 12y 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-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...
- pwnna 12y ago
  Root certificates are not affected.
gbl08ma 12y 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?
- rgbrenner 12y 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-as-non-secure https://www.chromium.org/Home/chromium-security/marking-http...
- MichaelGG 12y 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.)
  - marcosdumay 12y ago
    Just when was the last time you typed the "https://" 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.
smackfu 12y ago
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.
- blinkingled 12y 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.
  - smackfu 12y ago
    Yeah, I find it odd that they used that white page security indicator instead of the yellow yield warning sign.
    - blinkingled 12y ago
      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.
- pilif 12y 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.
  - 12y ago
verytrivial 12y 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.
- vtlynch 12y ago
  Use SSLLabs.com for diagnostics.
  - verytrivial 12y 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 12y 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-if-my-ssl-certificate-is-sha1-or-sha2-on-the-commandline http://stackoverflow.com/questions/26473076/how-do-i-check-i...
- giovannibajo1 12y ago
  Or use: https://shaaaaaaaaaaaaa.com https://shaaaaaaaaaaaaa.com
scottlinux 12y ago
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/comments/7 https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1423031/c...
FiloSottile 12y 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-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually... [2]: https://twitter.com/sleevi_/status/585429689646260224 https://twitter.com/sleevi_/status/585429689646260224 [3]: https://docs.google.com/presentation/d/1uv_dNkPVlDFG1kaImq7dW-6PasJQU1Yzpj5IKG_2coA/present?slide=id.i62 https://docs.google.com/presentation/d/1uv_dNkPVlDFG1kaImq7d... [4]: https://twitter.com/sleevi_/status/585429901848608769 https://twitter.com/sleevi_/status/585429901848608769
- brians 12y 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 12y 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 12y ago
  That seems to be common at least with the GlobalSign-backed CAs that I've seen. Not sure about others.
hkdobrev 12y ago
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
sandstrom 12y 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 12y 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 12y 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/ 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 12y 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-roadmap-for-chrome-development http://superuser.com/questions/885625/is-there-a-high-level-...

199 points by Mojah 12y ago

omeid2 12y ago

Training users to ignore SSL warnings. sigh

quonn 12y 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.
- omeid2 12y 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.
- josteink 12y 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?
  - helyka 12y ago
    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.
    - grhino 12y ago
      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.
    - jamies888888 12y ago
      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/
    - marcosdumay 12y ago
      If you are in Firefox, you can also click the padlock icon, and click on the more information button.
  - smackfu 12y ago
    Yeah, *.ycombinator.com is using a 5-year certificate which was issued in 2014.
- geofft 12y ago
  Yes, that's correct. Due to a subtle bug (https://crbug.com/472978 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 12y 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.

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

acveilleux 12y 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...
- pilif 12y 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.
  - eatler 12y ago
    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.
- Someone1234 12y 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 12y 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-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually...

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

cotillion 12y ago
StartSSL have sha2 intermediates nowdays. https://www.startssl.com/certs/class1/sha2/pem/ https://www.startssl.com/certs/class1/sha2/pem/
- 0x0 12y ago
  I guess using these will still require a re-issue of existing leaf certificates, so the signature matches the sha2 intermediate?
  - acveilleux 12y ago
    You guess correctly.
    - 0x0 12y ago
      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...
  - cotillion 12y ago
    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.
  - dtech 12y ago
    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/ 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.

higherpurpose 12y 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_se.html 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 12y 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.

smackfu 12y ago
Especially considering the official announcement blog post still says Chrome 41. http://googleonlinesecurity.blogspot.be/2014/09/gradually-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...
jfoster 12y 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.
- vtlynch 12y 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 https://twitter.com/vtlynch/status/574301319428702208
  - smackfu 12y ago
    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.

skrowl 12y ago

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

rgbrenner 12y 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-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...
BCM43 12y 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.
- rgbrenner 12y 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.
  - skrowl 12y ago
    The post title should be updated with this information.
deleted 12y ago
[deleted]
cbhl 12y ago
Google is pretty big. It's hard to get everyone to move in the same direction. ;)

tomjen3 12y ago

I wonder how many site owners just disable https now.

jfoster 12y 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.
- josteink 12y 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.
  - jasonmp85 12y ago
    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.
- Someone1234 12y 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 12y ago

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

smackfu 12y ago
Actually the Canary I just downloaded is 44. Version 44.0.2358.0 canary (64-bit)

jonathanoliver 12y 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:// https:// portion of the URL is green.

rgbrenner 12y 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-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.be/2014/09/gradually-su...
pwnna 12y ago
Root certificates are not affected.

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

rgbrenner 12y 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-as-non-secure https://www.chromium.org/Home/chromium-security/marking-http...
MichaelGG 12y 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.)
- marcosdumay 12y ago
  Just when was the last time you typed the "https://" 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.

smackfu 12y ago

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.

blinkingled 12y 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.
- smackfu 12y ago
  Yeah, I find it odd that they used that white page security indicator instead of the yellow yield warning sign.
  - blinkingled 12y ago
    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.
pilif 12y 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.
- 12y ago

verytrivial 12y 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.

vtlynch 12y ago
Use SSLLabs.com for diagnostics.
- verytrivial 12y 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 12y 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-if-my-ssl-certificate-is-sha1-or-sha2-on-the-commandline http://stackoverflow.com/questions/26473076/how-do-i-check-i...

giovannibajo1 12y ago
Or use: https://shaaaaaaaaaaaaa.com https://shaaaaaaaaaaaaa.com

scottlinux 12y ago

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/comments/7 https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1423031/c...

FiloSottile 12y 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-sunsetting-sha-1.html http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually... [2]: https://twitter.com/sleevi_/status/585429689646260224 https://twitter.com/sleevi_/status/585429689646260224 [3]: https://docs.google.com/presentation/d/1uv_dNkPVlDFG1kaImq7dW-6PasJQU1Yzpj5IKG_2coA/present?slide=id.i62 https://docs.google.com/presentation/d/1uv_dNkPVlDFG1kaImq7d... [4]: https://twitter.com/sleevi_/status/585429901848608769 https://twitter.com/sleevi_/status/585429901848608769

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

hkdobrev 12y ago

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

sandstrom 12y 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 12y 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 12y 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/ 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 12y 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-roadmap-for-chrome-development http://superuser.com/questions/885625/is-there-a-high-level-...