Slashdot Mirror

← Back to Stories (view on slashdot.org)

Why Google Is Pushing For a Web Free of SHA-1

Posted by Soulskill on from the collision-course dept.

An anonymous reader writes: Google recently announced Chrome will be gradually phasing out support for certificates using SHA-1 encryption. They said, "We need to ensure that by the time an attack against SHA-1 is demonstrated publicly, the web has already moved away from it." Developer Eric Mill has written up a post explaining why SHA-1 is dangerously weak, and why moving browsers away from acceptance of SHA-1 is a lengthy, but important process. Both Microsoft and Mozilla have deprecation plans in place, but Google's taking the additional step of showing the user that it's not secure. "This is a gutsy move by Google, and represents substantial risk. One major reason why it's been so hard for browsers to move away from signature algorithms is that when browsers tell a user an important site is broken, the user believes the browser is broken and switches browsers. Google seems to be betting that Chrome is trusted enough for its security and liked enough by its users that they can withstand the first mover disadvantage. Opera has also backed Google's plan. The Safari team is watching developments and hasn't announced anything."

108 comments

  1. SHA-1 by turkeydance · · Score: 5, Funny

    has hit the fan

    1. Re:SHA-1 by Anonymous Coward · · Score: 0

      Bookmarked for 20 years from now when they deprecate SHA-7. :-)

  2. Deprecation shouldn't start at the browser by Anonymous Coward · · Score: 4, Insightful

    It should start at the certificate authorities. They should've been planning for sha-1 to be unsupported by x date, and not issuing certificates valid past that date.

    1. Re:Deprecation shouldn't start at the browser by WaffleMonster · · Score: 3, Informative

      It should start at the certificate authorities. They should've been planning for sha-1 to be unsupported by x date, and not issuing certificates valid past that date.

      Certificate authorities roots also use SHA1 and typically carry validity periods of decades.

    2. Re:Deprecation shouldn't start at the browser by Anonymous Coward · · Score: 1

      Root cert sigs are meaningless, they're self-signatures. They could be zeroed out and most trustdbs probably wouldn't care.

    3. Re:Deprecation shouldn't start at the browser by WaffleMonster · · Score: 1

      Root cert sigs are meaningless, they're self-signatures. They could be zeroed out and most trustdbs probably wouldn't care.

      Yes this is true but it doesn't matter.

      Cross signing / alternate certification paths can lead to one mans root becoming another's intermediary.

      Intermediaries have the same problem with 10+ year validity periods.

    4. Re:Deprecation shouldn't start at the browser by nleven · · Score: 4, Insightful

      My understanding is CAs have limited interest in this matter. The product they are selling to website owners is really that green lock in the address bar. As long as that green lock icon is there, SHA1 or SHA256 won't make any difference. In this sense, deprecation should actually start at the browser.

    5. Re:Deprecation shouldn't start at the browser by Nick_Lowe712 · · Score: 4, Informative

      This clearly does not work though... Quoting Google's Adam Langley: "Unfortunately, many CAs decided to ignore it, presumably on the assumption that Microsoft would be forced to back down. We've done this dance with MD5 and 1024-bit certificates and we know how it goes. Here's a quick list of CAs that issued more than 2000 certificates extending into 2017 with SHA-1: GlobalSign nv-sa: 75,312 GoDaddy: 41,606 GeoTrust: 40,429 Comodo: 37,789 Verisign: 34,927 Terena: 9,444 Thawte: 8,735 Internet2: 8,637 Network Solutions: 8,077 Entrust: 5,542 AlphaSSL: 3,458 We would all have liked CAs to have acted either when the Baseline was updated (2011) or when Microsoft laid down dates (Nov 2013) or when Chrome talked about doing this at the CA/B Forum meeting earlier this year. It is unfortunate that that 2016/2017 dates are being ignored. If you run a site and want to be insulated from this sort you might want to consider getting one year certificates. CAs like to sell multiple years of course but doing renewal once every three (or more) years means that you have a significant risk of loosing the institutional knowledge of how to do it. (E.g. the renewal remainder email goes to someone who left last year and you then have a panic when it expires). Additionally, very long lived certificates are not insulated from from these sorts of changes and you may need to replace them during their lifetime anyway." https://news.ycombinator.com/i...

    6. Re:Deprecation shouldn't start at the browser by sexconker · · Score: 2

      No, it should start, and stop, at the user's local cert store.
      I don't actually trust any of the root CAs, and would much rather the world ran on self-signed certs.
      I'd love to walk into my bank and say "Hey fuckers, I need to add your cert. He's my cert so you can do that same. I can clearly see that you are in fact, my bank, and you can see that I am, in fact, your customer, so let's share our certs so we can communicate over public lines securely.".
      But no, that requires effort. So fuck it, we'll use untrustworthy certificate authorities who can and do fuck shit up and leak shit all over hell, and who are at the behest of corrupt governments.

    7. Re:Deprecation shouldn't start at the browser by mcvos · · Score: 1

      My bank is not a place I can easily walk into. I'd need to figure out where their office is, make an appointment, travel there, etc. And they'd have to do that with every single customer.

      On the other hand, when I originally got my account there, I sent them a bunch of paperwork, and they sent me all sorts of sensitive stuff in return. Through snailmail. So I guess adding their cert (on a USB stick?) to that wouldn't compromise anything.

    8. Re:Deprecation shouldn't start at the browser by westyx · · Score: 1

      How do you deal with entities that aren't physically located where you live?

      There's no amazon place of business in australia, but I buy stuff from them all the time. I'm pretty sure that ebay australia doesn't have a local presence in my home city, and there's definitely no valve place of business here. How do I exchange certs physically with these entities without flying to sydney or to america?

    9. Re:Deprecation shouldn't start at the browser by Anonymous Coward · · Score: 0

      Honestly, everyone is far too tame. There should be a requirement for CAs to show good security practices, and every single one of these should be on the "one more misstep and we'll throw you out" and in addition "stop it right now or you can close your business" list.
      But nobody actually has the balls to do more than a bit of silent complaining, even when faced with hard evidence that more than 50% (probably more like 90%) of all CAs should never ever have made their way in a root certificate list.

    10. Re:Deprecation shouldn't start at the browser by Neil+Boekend · · Score: 1

      They do have a large interest in the matter. If SHA-1 is broken and they keep selling it they lower the belief in the system. Thus it would lower the monetary value of ALL certificates.

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
    11. Re:Deprecation shouldn't start at the browser by Inf0phreak · · Score: 2
      If you set it up such that mails from, say, VeriSign are sent directly to , then you're DOING IT WRONG and you deserve what you get if a mail accidentally gets dropped because Bob got fired last year.

      One obvious solution is to run your own mail server and create <certificates@example.com>, a forward to <bobfromaccounting@example.com> and finally a bit of logic such that a big scary warning is sent to the administrator account for the mail server if the forward should ever fail. Whatever you do, the account that the CA is sending mail to should NEVER have to change for any reason and it should always be assigned to some person in the company.

      --
      ________
      Entranced by anime since late summer 2001 and loving it ^_^
    12. Re:Deprecation shouldn't start at the browser by MikeBabcock · · Score: 2

      Print your cert with a QR code on a single sheet of correspondance. Its not hard, and it would be easy to disseminate.

      --
      - Michael T. Babcock (Yes, I blog)
    13. Re:Deprecation shouldn't start at the browser by Kjella · · Score: 1

      I'd love to walk into my bank

      Good for you. Mine is all e-bank and I tend to like it that way. Same with most the e-tailers I shop at, the intersection with physical retailers is slim. How do you visit Gmail or Facebook? Speaking of which, people often have a different third party between them and whoever they're communicating with. You could always pretend it's not signed you know, what would you do? Send an email, asking them if that's their real certificate? Try to verify it through your "web of trust", which includes a bunch of dimwits who'll make the CAs look good? No, I wouldn't trust them for real end-to-end encryption but it's mostly good enough.

      CAs takes the fradulent redirect threat down, but they could always just hack your computer and keylog everything, they could hack the bank, it could be an inside job, they could social engineer you into thinking this is a legitimate certificate update or they could social engineer the bank into thinking you've made a new certificate or whatever. It doesn't matter how many inches of steel the front door is if the rest is plywood and glass windows. Direct out of band secure exchange is of course technically the best, but also the most inconvenient. I guess you should also swap giant OTPs, wouldn't want to trust AES right?

      --
      Live today, because you never know what tomorrow brings
    14. Re:Deprecation shouldn't start at the browser by sexconker · · Score: 1

      How do you deal with entities that aren't physically located where you live?

      There's no amazon place of business in australia, but I buy stuff from them all the time. I'm pretty sure that ebay australia doesn't have a local presence in my home city, and there's definitely no valve place of business here. How do I exchange certs physically with these entities without flying to sydney or to america?

      Site posts thumbrint of cert on site.com/security .
      I can call the customer service phone number and ask a human to tell me the thumbprint so I can verify.
      A QR code can be posted on my monthly bill.
      I can ask someone else who I trust and who deals with that entity to tell me the thumbprint.
      Or I can take the risk and trust the cert.

      It's about giving the USER control over who they trust, making trust an explicit action with a default of NOT trusting shit, and getting rid of the possibility for CAs/governments to fuck with shit outside of breaking/sabotaging the crypto.

    15. Re:Deprecation shouldn't start at the browser by sexconker · · Score: 1

      Call your bank, talk to a person, compare the cert thumbprint with what the employee tells you.
      Or check against the one included on your monthly bill, possibly via a QR code.
      Or check against any other trustworthy source.

      You being lazy isn't an excuse, be it physically going somewhere or spending 5 minutes to look shit up.

    16. Re:Deprecation shouldn't start at the browser by Lisias · · Score: 1

      They do have a large interest in the matter. If SHA-1 is broken and they keep selling it they lower the belief in the system. Thus it would lower the monetary value of ALL certificates.

      How to lower the belief in something that no one's knows it there? :-)

      Common people don't know about cryptography and security. All that common people knows is about WHO tells that something is secure or not - if they trust the guy that says that something is secure, then they acts as it is secure.

      Google is betting that people thrust Chrome.

      --
      Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
    17. Re:Deprecation shouldn't start at the browser by jbo5112 · · Score: 1

      It didn't stop VeriSign from selling lower priced MD5 certificates when the algorithm had known vulnerabilities. They finally stopped when somebody publicly announced the ability to forge a verifiable certificate for any website in 1-2 days using a cluster of 200 PS3's.

    18. Re:Deprecation shouldn't start at the browser by david_thornley · · Score: 1

      That's actually up to the browser providers. Your browser (assuming you're using something halfway normal) has a list of certificates that are from certificate authorities, and a certificate authority is a company that has it's certificate listed in browsers as certificate authorities. It isn't (AFAIK) recognized by any government (although governments can have certificates in there).

      For certificates not in that list, there's ways to connect certificates to the authorities, directly or indirectly, so you know that there is a chain of trust from Joe's Bait Shop and Certificate Authority to the website of the Centrol Inteligence Agnency you're accepting. This is again built into browsers. (The chain normally involves the certificate you're looking at having a hash of itself signed by the certificate authority, so it's important to use a good hash algorithm. If I can create my own certificate that hashes to the same value as, say, Microsoft's, then I can just copy the signature into my certificate.)

      It looks like Google, in their capacity as the guys who do Chrome, is going to start rejecting SHA-1 based certificates as trusted.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  3. I don't care. by JustNiz · · Score: 3, Funny

    My website will be fine since it uses ROT-13.

    1. Re:I don't care. by Anonymous Coward · · Score: 0

      whoosh

    2. Re:I don't care. by zephvark · · Score: 3, Funny

      That's why I always use ROT-13 twice. It completely eliminates the risk of that form of decryption.

    3. Re:I don't care. by Anonymous Coward · · Score: 0

      Double whoosh.

    4. Re:I don't care. by binarylarry · · Score: 1

      HSOOHW

      --
      Mod me down, my New Earth Global Warmingist friends!
    5. Re:I don't care. by binarylarry · · Score: 1

      Yep, good old SHA-15

      Can't beat that.

      --
      Mod me down, my New Earth Global Warmingist friends!
    6. Re:I don't care. by Anonymous Coward · · Score: 0

      jubbfu

    7. Re:I don't care. by DaphneDiane · · Score: 1

      That's why I always use ROT-13 twice. It completely eliminates the risk of that form of decryption.

      Because I had to worry about clients using XP SP2, I'm stuck using ROT-1. But I found that if I use it 26 times, it gives just as good protection and also avoids the inverse directional issues ROT-1 has with some implementations.

    8. Re:I don't care. by amicusNYCL · · Score: 2

      Because I had to worry about clients using XP SP2, I'm stuck using ROT-1.

      You joke about that, but we just had to switch a major client's SSL certificate back to SHA-1 because their users in China couldn't use the new certificate since they were all on XP pre-SP3. We charged them something like a $500 stupidity tax for making us go through the process to install a less secure certificate.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    9. Re:I don't care. by DaphneDiane · · Score: 1

      Yeah it's a real issue. And in many environments even installing another browser isn't an option for various reasons. Going to be a pain for those websites that want to reach pre-XP SP3 machines once root CAs stop issuing SHA-1 certs.

    10. Re:I don't care. by david_thornley · · Score: 1

      But does it handle 2ROT-13 or any other more advanced version? 3ROT-13 has nearly double the key width of ROT-13, after all.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  4. First movers nothing. by Anonymous Coward · · Score: 5, Interesting

    First movers nothing. Firefox 32 just released, and it deprecated a bunch of certs without any real warning at all, causing some users to get mad (http://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/). Google waited for Mozilla to take the risk while planning to safely tell the user that the site is running outdated SHA-1 certs. Stop trying to paint them as heroes, they're just one of the players, and not even at the forefront of the effort.

    1. Re:First movers nothing. by Elbart · · Score: 1

      "without any real warning at all"
      Wrong. That time you added an exception back in 2013 was the warning. Now deal with it.

    2. Re:First movers nothing. by Anonymous Coward · · Score: 0

      Sure, for the site runners. But end users? It almost feels like that's why Google decided on a padlock icon, because they waited for Mozilla to try the really risky approach and said "nope, we'll play it safe instead".

    3. Re:First movers nothing. by obarel · · Score: 3, Funny

      There's no point in acting all surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for fifty of your Earth years so you've had plenty of time to lodge any formal complaints and its far too late to start making a fuss about it now.

  5. What MS and Mozilla might be thinking by lkangaroo · · Score: 2

    Do your job too well, and people start questioning if it's needed in the first place.

    1. Re:What MS and Mozilla might be thinking by jd · · Score: 1

      That's why you should never hire people, just small furry creatures from Alpha Centauri.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  6. Or, you know, warn and ask. by Anonymous Coward · · Score: 0

    Or just warn people and ask them if they wish to continue.
    Having support for it is so trivial it hurts.

    Banning it is stupid.
    Shit like that is why I instantly removed Firefox one day because it refused to let me access my router one time because some security bullshit they experimented with in whatever shit version it was.

    The instant any site doesn't work and I can't access it at all, the browser gets binned. Period.

    1. Re:Or, you know, warn and ask. by viperidaenz · · Score: 1

      They're not banning anything. They're progressively changing the lock icon, from gold padlock now, to one with a red cross on in it some time next year.

  7. SHA1 is not encryption by Anonymous Coward · · Score: 1

    The summary writers really need to stop adding terminology willy-nilly. SHA1 is a hashing function, not an encryption.

    1. Re:SHA1 is not encryption by stoploss · · Score: 3, Informative

      The summary writers really need to stop adding terminology willy-nilly. SHA1 is a hashing function, not an encryption.

      Yes, SHA-1 is a hashing algorithm, and anyone even remotely confused about the distinction should avert their eyes and NOT click on this link to an elucidating comment from a few years ago that indicated something... rather surprising... about the nature of hashing and encryption.

      Strange, eh?

    2. Re:SHA1 is not encryption by Anonymous Coward · · Score: 0

      Checked it out. Neat.

    3. Re:SHA1 is not encryption by Mr+Z · · Score: 1

      You still need a way to mix a key into the result if you want a symmetric cipher.

      In any case, certificate validation doesn't use SHA-1 as a cipher.

      --
      Program Intellivision!
    4. Re:SHA1 is not encryption by MikeBabcock · · Score: 1

      Its a cryptographic hash function that uses encryption algorithms to generate (what used to be) secure hashes.

      There are some pretty terrible hash functions that are not crypto (like parity bits) but SHA is crypto.

      --
      - Michael T. Babcock (Yes, I blog)
  8. People who just bought a multiyear certificate? by Anonymous Coward · · Score: 0

    Thank God I bought my 5 year certificate in 2012, just think if I had to throw away 4 years of that instead of 2!

  9. SHA-3 by Anonymous Coward · · Score: 5, Insightful

    Wouldn't now be the time to push toward a transition to SHA-3, rather than SHA-2? I realize SHA-2 implementations are much more common. But 1) SHA-2 was handed down from the NSA and 2) is in the same family as MD5 and SHA-1.

    Considering 1) the recent NSA scandals, 2) that SHA-3 was independently developed and won a public competition, and 2) that SHA-3 uses a newer family of one-hash algorithms which is provably more secure than SHA-2, it would seem prudent to use momentum to move to SHA-3 sooner rather than later.

    1. Re:SHA-3 by Anonymous Coward · · Score: 0

      Reproducing my reply from my blog:

      This is definitely a time to invest in SHA-3, for the reasons you described. But SHA-3 is very new, and I don't think client support is anywhere near what it would need to be to deploy SHA-3 anywhere right now. SHA-2 has been around long enough that it's supported in every browser except for WinXP SP2, and Android 2.3 and below.

      Never been a better time to push for SHA-3 support in more OSes and browsers!

    2. Re:SHA-3 by another+random+user · · Score: 2

      Interesting, didn't know that XP doesn't support SHA-2. As certs will have to move to SHA-2 or above, that means the XP users won't be able to connect any more - not an issue as far as I am concerned (would rather loose XP based people that those who use the latest Chrome builds etc and won't connect because of security alerts).

      Given this, does this mean we are getting close to a point where we can start using SNI - if people with systems that don't support SNI can't connect anyway because they also don't support SHA-2, then just go all in and switch to SNI anyway.

      Are there browsers that do support SHA-2, but don't support SNI? If there are, are they a set that are actually worth worrying about?

      --
      -1 troll is not supposed to be used simply because you don't agree
    3. Re:SHA-3 by Anonymous Coward · · Score: 0

      There is no evidence that SHA-3 is any better than SHA-2. In fact, SHA-2 is older, and has had more time for evaluation, and so far has stood up. SHA-3 is neither as old, nor has had the amount of review. Just because something has a higher number, doesn't mean it is better. It is a good idea to jump to the best hash function, but your assumption that SHA-3 is better than SHA-2 is flawed.

    4. Re:SHA-3 by Anonymous Coward · · Score: 2, Informative

      Interesting, didn't know that XP doesn't support SHA-2.

      Read the post again: XP sp2 doesn't support SHA-2.

      XP with sp3 does - I just tried it with a sha256 certificate.

      As certs will have to move to SHA-2 or above, that means the XP users won't be able to connect any more - not an issue as far as I am concerned

      Some of us want to have a website to serve all paying customers, even if they use an old operating system.

      Amazon is probably the best example - any browser can shop on Amazon, since long ago Amazon realized that annoying their customers with the latest buzzword ajax "responsive" junk doesn't sell their product.

    5. Re:SHA-3 by skids · · Score: 2

      Well, if x509 has simply allowed for multiple signatures, we could just put both SHA2 and SHA3 signatures on the certs, and consumers of the certs could move towards supporting SHA3 as their security requirements dictate, ignoring the SHA2 signatures when they have a SHA3 signature available to them.

      But as with everything PKI related, the people making the calls have some blind spots when it comes to making things forward compatible or even particularly maintainable. It's as if they've never had to a day of PKI gruntwork in their life.

      --
      Someone had to do it.
    6. Re:SHA-3 by another+random+user · · Score: 1

      As certs will have to move to SHA-2 or above, that means the XP users won't be able to connect any more - not an issue as far as I am concerned

      Some of us want to have a website to serve all paying customers, even if they use an old operating system.

      Amazon is probably the best example - any browser can shop on Amazon, since long ago Amazon realized that annoying their customers with the latest buzzword ajax "responsive" junk doesn't sell their product.

      Never mentioned anything about ajax or responsive etc, only about support for SNI. Also, but of selective quoting on the part about loosing XP customers, you forgot to include the bit where I said "would rather loose XP based people that those who use the latest Chrome builds etc and won't connect because of security alerts". - in other words if one of those two sets has to be lost for some reason, I would select to loose the older XP set. Obviously it would be best to loose neither, but given a enforced choice then the XP users are toast (and they count for less than 0.5% of our users, so really not going to loose any sleep over that)

      --
      -1 troll is not supposed to be used simply because you don't agree
    7. Re:SHA-3 by Anonymous Coward · · Score: 0

      It's hard to take someone seriously when they repeatedly show they don't know the difference between lose and loose. Fuckwit.

    8. Re:SHA-3 by Nick_Lowe712 · · Score: 1

      With large sites like Twitter having already gone to SHA-2 (SHA-256) based certificates and CAs soon being in the position where they must refuse to issue SHA-1 based certificates going forward, this will be mandated on everybody soon. People will simply have to update to continue to use much of the modern Web. The issue regarding XP SP2 also affects Google's Chrome with only Firefox operating independently of the operating system here. The biggest roadblock will be getting those still using it to install SP3 or to move to Firefox. I expect that Chrome will soon stop installing or updating under SP2 largely because of the lack of support for SHA-2. They have already dropped support for processors that lack SSE2 intrinsics.

    9. Re:SHA-3 by Anonymous Coward · · Score: 1

      SHA-3 is provably resistant to the types attacks that have been used to break MD5 and SHA-1. SHA-2 uses similar constructions to MD5 and SHA-1, Merkle-Damgaard, and some of these attacks are generic across the family. While SHA-2 looks to still be quite strong in practice, as attacks against SHA-1 improve they'll also likely improve against SHA-2. And while SHA-2 is stronger and is more conservative (the NSA may have foreseen the breakthroughs made by researchers in the 2000s), that's not a good position to be in.

      I don't think you actually know what you're talking about. Your advice sounds more like typical cargo cult "wisdom" that could be said of anything, including shoes or pencils, and still sound smart.

      It's not an assumption that SHA-3 is better than SHA-2. It's an objective fact, at least for the kinds of attacks we know about.

    10. Re:SHA-3 by Anonymous Coward · · Score: 0

      It's an objective fact, at least for the kinds of attacks we know about.

      Your qualification is more important than the while of the rest of your post. SHA-3 has been designed and attacked by some of the best civilian crypto experts. It's very unlikely to fall to an attack we already know. However, now it's our there with a relatively new and interesting design it's quite probable that someone comes up with a new and novel attack. That attack might also get SHA-2, but it's less likely since SHA-2 has been under attack for years and hasn't yet fallen. Standards should be starting to allow SHA-3 as an of by default option. Development should be being done. We shouldn't rush though.

    11. Re:SHA-3 by mcvos · · Score: 1

      It would be nice if certificate authorities gave the option of getting a SHA-3 certificate. Sell it as an extra high security cert that will remain secure for a lot longer, but make clear that it's not supported by older browsers. People who really want the extra security would have the option to get it, and they'd have to insist that their users upgrade to a more secure browser. Win all around.

    12. Re:SHA-3 by Anonymous Coward · · Score: 0

      > ignoring the SHA2 signatures when they have a SHA3 signature available to them.

      Why? That sounds incredibly stupid. Isn't the obvious method to validate both?
      And not allowing multiple signatures is rather idiotic design, no question about that.

    13. Re:SHA-3 by petermgreen · · Score: 1

      I thought chrome moved away from using the windows SSL support some time ago to allow it to support SNI on XP.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    14. Re:SHA-3 by Anonymous Coward · · Score: 0

      Given what we now know about the NSA, it's hard to believe that's an oversight and not a deliberate weakening of the specification.

    15. Re:SHA-3 by tlhIngan · · Score: 1

      Never mentioned anything about ajax or responsive etc, only about support for SNI. Also, but of selective quoting on the part about loosing XP customers, you forgot to include the bit where I said "would rather loose XP based people that those who use the latest Chrome builds etc and won't connect because of security alerts". - in other words if one of those two sets has to be lost for some reason, I would select to loose the older XP set. Obviously it would be best to loose neither, but given a enforced choice then the XP users are toast (and they count for less than 0.5% of our users, so really not going to loose any sleep over that)

      There should be no reason anyone's using XP SP2 as that's been obsoleted a LONG time ago in favor of XP SP3, which works just fine. It was only recently that XP SP3 fell out of extended support.

      So you're not likely to lose too many people (unless you cater to people running ancient unsupported highly vulnerable versions of Windows). I would think the majority of XP users would be running SP3 for a while now.

    16. Re:SHA-3 by Anonymous Coward · · Score: 0

      I don't think you actually know what you're talking about. Your advice sounds more like typical cargo cult "wisdom" that could be said of anything, including shoes or pencils, and still sound smart.

      Please reread your post. You make a lot of assumptions, some of which may not be true. Please reread my post. I made NO assumptions.

      It's an objective fact

      I don't think that means what you think it means. Different does not mean better. No, I don't know what I am talking about, but I am still more logically consistent. That's sad.

    17. Re:SHA-3 by Anonymous Coward · · Score: 0

      You make it sound like new algorithms are developed in a vacuum, like throwing darts at a dart board. SHA-3 candidates were developed with full knowledge of how pre-existing functions worked, including SHA-2, and full knowledge of their known and suspected weaknesses.

      Sure, there may be unknown attacks which work against SHA-3 and not SHA-2. But there's no reason to believe that statement. Or not believe that statement. It's 100% pure abstract conjecture. It's the kind of divorced-from-reality "what if" that is inimical to security engineering. And it's classic cargo cult, think-from-your-gut analysis.

    18. Re:SHA-3 by Anonymous Coward · · Score: 1

      You said, "There is no evidence that SHA-3 is any better than SHA-2."

      That is false. We know that SHA-3 is resistant to attacks that SHA-2 isn't. SHA-2 has known attacks, they're just not better than brute force. That's how MD5 and SHA-1 started out. In fact, most algorithms

      "In fact, SHA-2 is older, and has had more time for evaluation, and so far has stood up."

      This is false. It hasn't stood up. If cryptographers thought it was standing up and was going to stay secure, there wouldn't have been a push for SHA-3.

      "SHA-3 is neither as old, nor has had the amount of review."

      First of all, these algorithms aren't developed in a vacuum. What has been learned from MD5, SHA-1, SHA-2, has been applied to developing SHA-3. So the fact that SHA-3 is newer could just as well auger in its favor. Secondly, SHA-3 was subject to a public competition. SHA-2 wasn't. It's entirely feasible that SHA-3 has been subject to more analysis by more people precisely because of the long, open competition. It took years for people to point out flaws in other NIST standards, like DRBG, which weren't subject to open competition.

      "Just because something has a higher number, doesn't mean it is better. It is a good idea to jump to the best hash function, but your assumption that SHA-3 is better than SHA-2 is flawed."

      You seem to think that cryptography is based on intuition, persistence, and a bunch of fluffy pseudo-engineering thinking. But based on objective criteria, SHA-3 is objectively better than SHA-2. Sure, you can invent imaginary scenarios where SHA-3 is not better than SHA-2. Maybe in your Platonic universe my argument isn't being logically consistent. But that's because I'm _presuming_ that we can measure "better" using objective criteria.

      Have you actually read the literature? Did you following the SHA-3 competition? Did you read the papers? It's not just me saying that SHA-3 is better than SHA-2. It's the researchers. When a researcher says that SHA-3 is immune to an attack used against SHA-1 and SHA-2, that's an objective fact. Collect those objective facts and they all weigh against SHA-2, making SHA-3 "better". But we can play word games all day long.

      Granted, just because SHA-3 is better does not by itself mean we should ditch SHA-2. That's a different issue.

    19. Re:SHA-3 by skids · · Score: 1

      Why? That sounds incredibly stupid. Isn't the obvious method to validate both?

      You could do that too, but if the SHA3 is not deemed sufficient protection, then we are
      screwed anyway. Embedded devices might choose to ignore the SHA2 to save on
      compute resources.

      --
      Someone had to do it.
  10. What about Symantec Class 3 EV SSL CA - G2 by viperidaenz · · Score: 2

    Issuer: CN = VeriSign Class 3 Public Primary Certification Authority - G5, OU = (c) 2006 VeriSign, Inc. - For authorized use only, OU = VeriSign Trust Network, O = VeriSign, Inc., C = US
    Subject: CN = Symantec Class 3 EV SSL CA - G2, OU = Symantec Trust Network, O = Symantec Corporation, C = US
    Valid from: Thursday, 31 October 2013 12:00:00 p.m.
    Valid to: Tuesday, 31 October 2023 11:59:59 a.m.
    Signature algorithm: sha1RSA
    Signature hash algorithm: sha1
    Thumbprint algorithm: sha1
    Thumbprint: e4 99 59 a4 b3 36 ac bd 2d ac 75 9b b5 21 b9 46 03 3e 82 3a

    They're still issuing certificates. It appears they use sha1?

  11. Uhh yeah by Lirodon · · Score: 4, Informative

    Implying only Google is doing this. Microsoft is doing it too, and a Firefox bug has made a similar proposal shortly after said announcement. https://bugzilla.mozilla.org/s...

    1. Re:Uhh yeah by jd · · Score: 1

      Microsoft will probably implement SHA0. There's no value in SHA2 (and variants) now that SHA3 has been ratified, since SHA2 is just SHA1 with some lengthening. If SHA1 is brutally compromised, SHA2 will fall shortly after. Best to switch to NESSIE (Whirlpool) and SHA3 (something that sounds vulgar).

      Having said that, SHA3 involved dubious mid-contest rule changes and spurrious rejection criteria that might well have been NSA-inspired. I'd take a very close look at the Hashing Lounge for any second or third round reject that shows greater resilience across the board (pre-image vulnerabilities, etc) as a backup in case NESSIE and SHA3 are seriously compromised.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    2. Re:Uhh yeah by david_thornley · · Score: 1

      The problem with hunting down the best hash algorithm is that both your certificate authority and the user's browser have to support it. SHA-3 has at least the benefit of standardization, which puts it far ahead of a third round reject.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    3. Re:Uhh yeah by jd · · Score: 1

      Agreed, which is why it should be there.

      Nonetheless, there needs to be a backup plan in case it does turn out that the NSA or GCHQ have a backdoor to it. If it's been deliberately compromised (and I'm not keen on changes made AFTER it had been approved as SHA3 for that very reason), then the more paranoid amongst us need to have a backup plan. I certainly wouldn't suggest HTTPS over TOR use algorithms that are considered three-letter-agency-unsafe for any part of the security protocol, for example, since they're the ones doing most of the attacking.

      There's no easy answer to this, but I think that having SHA3 and NESSIE as the two standard choices and limited support for some third algorithm for when approval simply isn't good enough is the only real solution. The first two can be standard on all browsers and by all certificate authorities, the third only needs support on special-purpose browsers and OpenCA/OpenSSL/LibreSSL (since most uber-secure sites will roll their own certs).

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  12. https://www.google.com using SHA-1 by WaffleMonster · · Score: 5, Interesting

    Amazing www.google.com and every single link in its trust chain is using SHA-1 signature algorithm.

    1. Re:https://www.google.com using SHA-1 by return+42 · · Score: 3, Informative

      True. As mentioned in the article and a linked tweet, Google plans to migrate to SHA-256 by the end of 2015. Why it will take them so long is not stated.

      In the meantime, their certificates only last three months. Probably only NSA and GCHQ could forge a cert in that short a time — and they don't need to. (Though I'm sure they would prefer a nice quiet forgery to issuing an order that someone might blow the whistle about.)

    2. Re:https://www.google.com using SHA-1 by WaffleMonster · · Score: 1

      True. As mentioned in the article and a linked tweet, Google plans to migrate to SHA-256 by the end of 2015. Why it will take them so long is not stated.

      I only read Google's announcement and did not follow every link from others before posting.

      Hearing this only makes things worse... If Google themselves is not getting their act together until 2016 and concurrently the following is true:

      "Chrome 39 (Branch point 26 September 2014)
      Sites with end-entity (âoeleafâ) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as âoesecure, but with minor errorsâ.

      It is hard to imagine a situation whereby you can avoid everything appearing broken in much the same way everything is known to the state of California to cause cancer.

      In the meantime, their certificates only last three months. Probably only NSA and GCHQ could forge a cert in that short a time â" and they don't need to.

      What is the point of this?I don't understand the logic here.. how/who does this help?

      Google's cert would be useless as the attacker does not have google's private key and path restrictions of preceding prior trust path makes it useless to repurpose as an intermediary.

      Nobody is going to waste their time going after one companies SSL cert they are going to go after any vulnerable trust chain and fuck EVERYONE including Google regardless of how often they change their certs.

  13. Oh be serious, Google by Anonymous Coward · · Score: 1

    Why is the only form of encrypted password you accept via your Google Apps Directory Synchronization GADS tool SHA1? Not even salted. Just flat out SHA1. Let us sync salted strongly hashed passwords, and then we'll take your concern for security seriously.

  14. Hash in counter mode == stream cipher by tepples · · Score: 1

    I thought DJB's Snuffle construction turned any hash into a stream cipher by using the hash in counter mode.

    1. Re:Hash in counter mode == stream cipher by Mr+Z · · Score: 2

      While that may be true, web browsers aren't using SHA-1 for encryption, especially for validating certificates. It's a cryptographically strong hashing function, but not, on its own, encryption.

      --
      Program Intellivision!
  15. Thumbprint by tepples · · Score: 1

    The article states that trusted root CA certificates aren't compared by thumbprint; they're compared by identity.

    1. Re:Thumbprint by viperidaenz · · Score: 2

      That's not a root CA, it's an intermediate CA signed by the VeriSign root CA.

  16. The Real Reason? by Anonymous Coward · · Score: 0, Informative

    The announcement from Chromes mailling list:
    https://groups.google.com/a/ch...

    Link to mailling list archive: https://groups.google.com/a/ch...

    The real reason is Ryan Sleevi does not want to talk about is this brilliant idea he poo-pooed: https://groups.google.com/a/ch...

    He just divert attention from that.

    1. Re:The Real Reason? by Qzukk · · Score: 2

      Except that it's honestly a shitty idea given the history of witness unreliability. The human mind is pretty shit at remembering a real human's face you've only seen once. Worse, an uncanny valley fake face is going to look like every other uncanny valley fake face, especially without additional visible features like hair or glasses (and even then the memory is likely to recall "wears glasses" not a specific style or color).

      Also, the guy never explained what the hell the problem was that he wants the engineers to make a solution for, other than "it doesn't use this cool face-making library I wrote." Clearly we are all too stupid to see the value of having lawnmower man's face shown when we log into our banking website, if only we weren't engineers instead of PhDs.

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    2. Re: The Real Reason? by Fwipp · · Score: 1

      AC is very clearly trying to promote his own useless face-generation technique.

  17. US Gov migration from SHA1 by Anonymous Coward · · Score: 1

    A migration from SHA1 for US federal agencies was mandated at the end of 2013.

    1. Re:US Gov migration from SHA1 by userw014 · · Score: 1

      A quick check of https://www.irs.gov/ and https://whitehouse.gov/ failed SSL Certificate validation (for different reasons.)

      And https://www.healthcare.gov/ is using SHA1

  18. Re: Dip Shit Alert! It's a hash not crypto! by owlstead · · Score: 3, Informative

    Hash is crypto. Its not encryption although with a bit of effort it can be turned into a stream cipher.

  19. Dip Shit Alert! It's a hash not crypto! by Anonymous Coward · · Score: 1

    if you had studied computational complexity theory, you would understand that they are the same thing

  20. More information = less security by WaffleMonster · · Score: 0

    When you add decision points about issues the average user has no practical basis for making an informed determination you just make matters worse by adding confusion and uncertainty able to be leveraged by adversaries.

    Now instead of secure and not secure.. ideally working and not working... we are hurling FUD and technobabble at users whose day job is NOT technology.

    Who am I trying to kid.. .f@#uck...it...ya'll just need more reassuring padlock .gifs to adorn your secure sites.

  21. Re:Dip Shit Alert! It's a hash not crypto! by Anonymous Coward · · Score: 1
    Basic course in hash versus crypto

    -

    hash < huge > 160 bits (no way back)

    crytp < huge > huge (get it back exactly as before)

  22. SHA-1, git thee gone! by Anonymous Coward · · Score: 0

    An internet free of commit hashes is too much to hope for, I guess.

  23. Thats rich comming from Google, they sure love RC4 by citizenr · · Score: 3, Informative

    Google still REQUIRES RC4 for Youtube.

    https://news.ycombinator.com/i...

    --
    Who logs in to gdm? Not I, said the duck.
  24. Re:Thats rich comming from Google, they sure love by Nick_Lowe712 · · Score: 2

    Except that is out-of-date information so it is meaningless to this discussion: https://www.ssllabs.com/ssltes...

  25. Re: People who just bought a multiyear certificate by corychristison · · Score: 3, Insightful

    Not sure if serious...

    Most CA's offer free re-issues these days. Allowing you to change your key, and hashing algorithm, and possibly other stuff.

  26. Not encryption! by strikethree · · Score: 1

    Google recently announced Chrome will be gradually phasing out support for certificates using SHA-1 encryption.

    SHA-1 is a hashing Algorithm, not an Encryption Algorithm. Really people. How do you expect anyone to become educated if everything they see is inaccurate to begin with?

    http://en.wikipedia.org/wiki/H...
    http://en.wikipedia.org/wiki/E...

    The short story is that hashing is to prove information has not been altered. Encryption is to keep information secret. Both technologies are used to ensure a secure information exchange experience.

    --
    "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
  27. Why would CAs need to replace existing SHA-1 certs by Anonymous Coward · · Score: 0

    Reading various sources on this issue I can't understand why the main problem for CAs here is the replacement of existing SHA-1 SSL certificates? Why do they need to do that? Is it not enough for CA's to _stop_ issuing new certificates under SHA-1, as only new certificates would be the potential source of collision attacks? Is there any security gain whatsoever in upgrading any individual site from SHA-1 to SHA-2?

  28. Re:Thats rich comming from Google, they sure love by Anonymous Coward · · Score: 0

    You're testing the website, not where the videos are served. YOU are meaninless to this discussion.

  29. Re:Thats rich comming from Google, they sure love by citizenr · · Score: 2

    the only meaningless information is coming from you. Its not the YT portal that requires RC4, its servers serving actual video files

    r6---sn-2apm-f5fs.googlevideo.com
      accepted ciphers:
    TLSv1 128 bit RC4-SHA
    SSLv3 128 bit RC4-SHA

    and hundreds of other content farm servers

    --
    Who logs in to gdm? Not I, said the duck.
  30. Re:Thats rich comming from Google, they sure love by Nick_Lowe712 · · Score: 1

    Yup, my mistake. Eats humble pie!

  31. Re:Why would CAs need to replace existing SHA-1 ce by petermgreen · · Score: 1

    Is it not enough for CA's to _stop_ issuing new certificates under SHA-1, as only new certificates would be the potential source of collision attacks?

    Unfortunately SSL certificates have become a lowest bidder shithole market. In this environment ensuring that no CA continues to issue SHA-1 certs is impractical.

    Rejecting certs based on issue date doesn't directly solve the problem either because the "legit" and "fake" certs in the collision attack can have different issue and expiry dates. What it does do is strongly discourage CAs from issuing SHA-1 certs which has two positive affects

    1: it reduces (but does not eliminate) the risk that the attacker will find a cert issuing service that is vulnerable to SHA-1 collision attacks.
    2: it prepares for the eventual complete dropping of SHA-1 support.

    Is there any security gain whatsoever in upgrading any individual site from SHA-1 to SHA-2?

    Not directly. It is very unlikely that the legitimate certificate for a given site and the fake one obtained by an attacker will have any cryptographic relationship to each other.

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  32. Re:Dip Shit Alert! It's a hash not crypto! by Anonymous Coward · · Score: 0

    No. You're confusing cryptography with encryption.

  33. Double hash by Anonymous Coward · · Score: 0

    Why not improve certs to be able to use two or three hashes? You can collide one of the hashes, but colliding both of them at the same time is probably impossible enough (relative superlative? yes, of course) to be safe for aeons. MD5 + SHA-1 = impossible enough

    1. Re:Double hash by Sique · · Score: 1

      It is sufficient to collide one hash to compromise the certificate. With two hashes offered, you cut the strength of each hash effectively in half.

      --
      .sig: Sique *sigh*
  34. Didn't know you could encrypt things with SHA-1 by bhspencer · · Score: 1

    Poster says "phasing out support for certificates using SHA-1 encryption" SHA-1 is a hash function not an encryption function.

    1. Re:Didn't know you could encrypt things with SHA-1 by Anonymous Coward · · Score: 0

      This wise ass is not aware that SHA-1 can be used for encryption.