Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Encryption Facebook The Internet

SHA-1 Cutoff Could Block Millions of Users From Encrypted Websites (csoonline.com) 146

Posted by Soulskill from the privacy-versus-convenience dept.
itwbennett writes: As previously reported on Slashdot, browser makers are considering an accelerated retirement of the older and increasingly vulnerable SHA-1 function. But Facebook and CloudFlare are warning some 37 million users of old browsers and operating systems that don't support SHA-2 will be left without access to encrypted websites. The majority of them are located in some of the "poorest, most repressive, and most war-torn countries in the world," CloudFlare's CEO Matthew Prince said Wednesday in a blog post. Facebook has solved this problem by building a mechanism that allows its certificates to be switched automatically based on the browser used by the visitor.
This discussion has been archived. No new comments can be posted.

SHA-1 Cutoff Could Block Millions of Users From Encrypted Websites More

SHA-1 Cutoff Could Block Millions of Users From Encrypted Websites

Comments Filter:

  • Pretty sure... (Score:1)

    by Anonymous Coward

    That even Windows XP support the latest browsers still... or at least some variant of them.
    If they don't want to move on from IE 6, that's their god damn problem.

    • Re:Pretty sure... (Score:4, Interesting)

      by Locke2005 ( 849178 ) on Friday December 11, 2015 @01:49PM (#51101457)
      Problem for PCs is not browser availability or cost, problem is that for some people downloading a GByte of data to install a new browser is not feasible. Also, browsers are in everything now, including smartphones, smart TVs, and Nintendo DS, so you're stuck with what the hardware vendor supplies you. (Don't get me started on my Smart TV not showing videos because most hosts support video using Adobe Flash only, and Adobe refuses to license flash to most hardware manufacturers. HTML5 has been a standard for how many years now?)

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Errr... a GByte of data? Are you missconfussed with the pushed Windows 10 update?

        Firefox was less than 50MB last time I did a full install.

        The real problem in this case may end being that the overbloated browsers drop support for older systems.

      • Has nothing to do with Adobe not licensing to "most hardware manufacturers." You bought a smart-TV. It will most-likely never get a firmware update, and the DRM-scheme for Flash streaming was updated --- Flash "broke" on your "smart' TV... as it's not really "smart" --- its a locked content device.

  • Think of all the Oracle users? (Score:5, Funny)

    by mveloso ( 325617 ) on Friday December 11, 2015 @01:15PM (#51101253)

    Some of the older Oracle products only support SHA-1. Upgrading to a newer version or Oracle will cost them millions. Won't someone think of the Oracle user base?

    • Free Oracle upgrades available everywhere (Score:2, Funny)

      by Anonymous Coward

      Some of the older Oracle products only support SHA-1. Upgrading to a newer version or Oracle will cost them millions. Won't someone think of the Oracle user base?

      Nonsense. Postgres is free.

      • Re:Free Oracle upgrades available everywhere (Score:4, Interesting)

        by mveloso ( 325617 ) on Friday December 11, 2015 @02:05PM (#51101573)

        Porting from Oracle to Postgres is free too, if you want everything to break.

      • Postgres is free.

        PostgreSQL is free until the application that you just tried to migrate from Oracle Database to PostgreSQL throws a syntax error. Then it costs time (which is money) to fix the apps if they're in-house or free, or it costs money to either purchase an upgrade to add PostgreSQL compatibility to a proprietary application or to migrate entirely from a proprietary application for which PostgreSQL compatibility is not available. Or does PostgreSQL's PL/pgSQL parser accept all PL/SQL and MySQL syntax to allow it t

    • Asking for it (Score:1)

      by Anonymous Coward

      Oracle users deserve all the pain they can get!
      Don't complain of neck pain after hanging yourself.

    • Serves them right.

      When will people stop and realize not to dig yourself into a vendor only based solution.

    • Well admittedly, having to pay sudden exorbitant fees is something that Oracle users are not wholely unfamiliar with. They've probably already have contigency plans.

  • Facebook -- ??? (Score:4, Insightful)

    by plover ( 150551 ) on Friday December 11, 2015 @01:15PM (#51101257) Homepage Journal

    So let me see if I understand Facebook's approach here: there are non-secure certificates. Facebook will fix the problem by downgrade connections to use non-secure certificates. Bad guys would never pretend to need a non-secure certificate. Therefore, Facebook remains safe?

    • Pretty much, yes. Facebook supports SHA1 certificates, same situation as yesterday.
      • Sure, but... who cares if someone's Facebook account gets hacked? Hell, a lot of people log into Facebook on other people's devices (e.g. in stores) and leave themselves logged in!

        • Persistent login is a completely orthogonal problem to TLS certificate forgery. What's going on is that Mozilla and Facebook are continuing to make SHA-1 access available and dealing with forgeries on a reactive basis until enough of the user base has migrated to allow the proactive approach of allowing only SHA-256 access.

    • Re:Facebook -- ??? (Score:4, Interesting)

      by Errol backfiring ( 1280012 ) on Friday December 11, 2015 @01:28PM (#51101351) Journal
      My first thought was a kind of "degrading man in the middle" attack. Alter the requests so that non-secure certificates are negotiated, then tune in to the less secure communication while the browsers show that the connection is secure. You'd still need a lot of computing power to crack the SHA-1 encrypted stream, but for criminals, either government or otherwise, that is not a huge problem.

      • Re:Facebook -- ??? (Score:4, Insightful)

        by Anonymous Coward on Friday December 11, 2015 @01:54PM (#51101489)

        Nope.

        Here's how this spins out.

        If you got a nice shiny new SHA-2-only browser, and you go to the real Facebook, it has a SHA-2 cert and everything works, and you're safe
        If you got a crappy browser that can't handle SHA-2, and you go to the real Facebook, it shows a SHA-1 cert, which you trust, you are at risk, but only because you've got a crappy browser. Hate the risk? Get a newer browser
        If you got a nice shiny new SHA-2-only browser and a bad guy pretends to be Facebook, sends the SHA-1 cert, your browser says "Ugh, insecure, No" and you're safe and the bad guy wasted their time
        If you got a crappy browser that can't handle SHA-2 and a bad guy pretends to be Facebook, they might _if they spent a lot of money / resources_ fake you out. So you should have got a nice shiny new browser.

        • They can't do this reliably (Score:4, Interesting)

          by madbrain ( 11432 ) on Friday December 11, 2015 @02:10PM (#51101607) Homepage Journal

          The problem with that is that there is no actual way to detect that an old browser doesn't support SHA-2.
          For example, older versions of Firefox/NSS since 2003 have supported SHA-2 server certificates, but not SHA-2 in TLS cipher suites as the MAC algorithm, which wasn't specified until years later.

          The TLS ClientHello message does not specify which types of hash algorithm the client supports for certificates, only the list of cipher suites that the client supports.

          Thus, Facebook, or anyone else, has no way of determining if a client really doesn't support SHA-2 server certificates.

          What they are probably doing is assuming that clients that don't support SHA-2 MAC in TLS cipher suites . But that's a wrong assumption. Many older clients will be downgraded to SHA-1 server certificates as a result, even though they support SHA-2 certificates. And they will have no way of knowing that this happened.

          • If a browser will trust SHA1 certificates then it doesn't really matter whether the legitimate site sends a SHA1 cert or a SHA2 cert. What matters is that they will accept a SHA1 cert from an attacker and there is nothing the legitimate site can do about that.

            • I think the OP is referring to browsers that *won't* accept SHA1 but are improperly presented with it thus locking those users out. That may be a lesser percentage than those who will get locked out of SHA1 is done away with entirely.

          • Re:They can't do this reliably (Score:4, Informative)

            by Ed Tice ( 3732157 ) on Friday December 11, 2015 @02:49PM (#51101857)
            Rather than guess what they are probably doing, the source code is here. https://github.com/facebook/wa... [github.com] But you were pretty close. You're right that *some* browsers that *could* get an SHA2 certificate will get the SHA1 version. An improvement would be to present the SHA2 certificate if you're sure that the browser can accept it. Otherwise show the SHA1 certificate. Put a warning page up when presenting the SHA1 certificate suggesting that people upgrade browsers. For those that have older browsers that want the SHA2 certificate but are getting an SHA1, offer an alternative like sha2.facebook.com. I imagine that this is a very small set of users. And as has been mentioned already, certificate pinning is your friend.

          • The problem with that is that there is no actual way to detect that an old browser doesn't support SHA-2.
            For example, older versions of Firefox/NSS since 2003 have supported SHA-2 server certificates, but not SHA-2 in TLS cipher suites as the MAC algorithm, which wasn't specified until years later.

            The TLS ClientHello message does not specify which types of hash algorithm the client supports for certificates, only the list of cipher suites that the client supports.

            Thus, Facebook, or anyone else, has no way of determining if a client really doesn't support SHA-2 server certificates.

            It might be possible to fingerprint clients based on what they advertise.

        • > they might _if they spent a lot of money / resources_ f

          It's not that much money. This article was from 2010, with the resources available then.

                          http://www.geek.com/news/resea... [geek.com]

      • Re: (Score:3)

        by DarkOx ( 621550 )

        SHA-1 encrypted stream

        SHA-1 is NOT used to encrypt the stream. Its used to authenticate the certificate. Some other cipher like RC4, AES, 3DES, etc is selected to encrypt the stream.

    • Re: (Score:2)

      by DarkOx ( 621550 )

      It might not be as bad as you think. If you have upgraded to a newer browser you probably can and should enable certificate pinning which would help you discover if you were being subjected to the sort of down grade attack you are describing.

      OOTH it leaves the people using older technology with about the same security posture they had before.

      The sad part being all those people in repressive regimes most likely need to be the most concerned. "The right thing to do" is probably go ahead and let them get cut

      • Re: (Score:2)

        by tepples ( 727027 )

        Certificate pinning doesn't help when each server in a load-balanced cluster generates its own private key and CSR and thus needs its own certificate. IIS is believed to do this by default [serverfault.com].

        • Re: (Score:2)

          by DarkOx ( 621550 )

          What??

          That makes no sense if you using a 3rd party certificate authority, you will be either doing in bound SSL termination on the load balancer and put the cert there, or you will be copying the cert and its private key to each server in the farm.

          If you are running a web farm you are not having IIS auto generate CSRs unless its only to make requests to an internal CA for the trust relationship between the servers and the balancer.

          • Re: (Score:2)

            by tepples ( 727027 )

            you will be either doing in bound SSL termination on the load balancer and put the cert there

            And once your traffic has grown past one load balancer's capacity, you have to cluster your load balancers.

            or you will be copying the cert and its private key to each server in the farm.

            I guess some big banks are paranoid about letting any private key get exported from any machine.

        • If you don't have a certificate, many server applications (I guess IIS included) will automatically generate one for you. It's not from a trusted CA and your browser will complain loudly about it. But if you accept *and pin* the certificate it guarantees against impersonation. That works fine for internal apps. For production sites, you don't use the auto-generated cert. What applications are doing is similar to what SSH does on new connections. As long as you can guarantee the authenticity of the fir

          • For production sites, you don't use the auto-generated cert.

            Correct: you export a CSR from the auto-generated keypair and use that to buy a certificate. Normally, you'd export one server's auto-generated keypair, export a CSR, buy the certificate, and import it to the other servers. But if you're paranoid about never exporting a private key, you'll end up with a separate certificate on each server in your load-balancing cluster.

            • Exporting the private keys is often done very poorly. I've certainly seen people email such certificates in plain text, and provide access to backups of load balancer backups with unencrypted local keys. Some web servers bother to require manual passwords at start time to unlock an encrypted private key, but I've seen only a very, very few high security sites do that.

    • So let me see if I understand Facebook's approach here: there are non-secure certificates. Facebook will fix the problem by downgrade connections to use non-secure certificates. Bad guys would never pretend to need a non-secure certificate. Therefore, Facebook remains safe?

      No. The risk remains regardless of what individual sites do so long as the users browser remains willing to accept certificates signed with broken hash algorithms.

      If your browser supports SHA-1 and Facebook uses only the most secure hash algorithm available an attacker can still pretend to be Facebook by leveraging SHA-1.

      Fix is exclusively client side... servers just need to upgrade so that clients will continue to want to speak to them after clients no longer accept SHA-1.

  • This is nonsensical fear mongering (Score:2, Funny)

    by Anonymous Coward

    I have one of these old browsers, and I'm not being cut off of the we

    • Re: (Score:1)

      by Anonymous Coward

      I have one of these old browsers, and I'm not being cut off of the we

      You forgot the "%#$%@#$ NO CARRIER".

  • Slashdot will remain accessible (Score:5, Insightful)

    by Ksevio ( 865461 ) on Friday December 11, 2015 @01:44PM (#51101425) Homepage
    Fortunately, slashdot will remain accessible as it still hasn't entered the 2010's and added encryption yet!

    • Slashdot doesn't even support unicode.

      It doesn't need to, though, really.

    • Fortunately, slashdot will remain accessible as it still hasn't entered the 2010's and added encryption yet!

      Get a grip. Not every connection on the web needs to be encrypted. I would argue that *most* connections on the web do not need to be encrypted - Slashdot for example. It's like TV stations bragging that even their news is in high-def - it's the fucking News.

      • Without encryption, anyone can sniff your session cookie, clone it, and post Goatse as fahrbot-bot.

      • It's well worth using encryption for every possible website if only to stop malicious parties from injecting payloads into the html coming back from servers.

      • Fortunately, slashdot will remain accessible as it still hasn't entered the 2010's and added encryption yet!

        Get a grip. Not every connection on the web needs to be encrypted. I would argue that *most* connections on the web do not need to be encrypted - Slashdot for example.

        Nonsense. There are multiple reasons that all connections need to be encrypted and authenticated.

        One obvious one is to prevent malicious parties from injecting malicious payloads into your web pages. You think you're downloading a page from slashdot, but someone else modifies the data in transit, injects a XSS attack to gain access to the banking site you're logged into in another tab, or injects malicious content that exploits some security vulnerability in your browser or OS to pwn your system and add i

        • Nonsense. There are multiple reasons that all connections need to be encrypted and authenticated.

          What I find amusing everything you mention is a problem in no way solved by the use of encryption.

          One obvious one is to prevent malicious parties from injecting malicious payloads into your web pages.

          You think you're downloading a page from slashdot, but someone else modifies the data in transit, injects a XSS attack to gain access to the banking site you're logged into in another tab

          If banking site is vulnerable to CSRF you would think it would be in their own interests in fixing this before the problem is exploited the next time same user clicks the wrong link from a Google search or opens the wrong email.

          or injects malicious content that exploits some security vulnerability in your browser or OS to pwn your system and add it to a massive botnet which DoSes the forces of goodness and light. Or, worse, installs the Yahoo toolbar.

          If you encrypt all the transports nothing changes. People will still exploit vulnerabilities in all the same ways. The only way to fix this is to fix bugs and all deficiencies that all

          • One obvious one is to prevent malicious parties from injecting malicious payloads into your web pages.

            You think you're downloading a page from slashdot, but someone else modifies the data in transit, injects a XSS attack to gain access to the banking site you're logged into in another tab

            If banking site is vulnerable to CSRF you would think it would be in their own interests in fixing this before the problem is exploited the next time same user clicks the wrong link from a Google search or opens the wrong email.

            The point is that the attack can be carried out without the user visiting any malicious site. Yes, the bank should fix its bugs, but enabling malicious injection of content into other sites opens up new attack vectors for the attacker who can manipulate your traffic. If I can convince you to connect to my public Wifi service (trivially easy to do in coffee shops and other areas that offer open Wifi) and you use a non-TLS service, then I don't have to figure out how to send you e-mail, or find some way to so

            • The point is that the attack can be carried out without the user visiting any malicious site.

              The wire simply is not the instrument being leveraged against vast majority of users.

      • But Google says every site needs to be encrypted. Must.... follow... google.... must.... follow..... google... must ..... follow...... google.....

        • But Google says every site needs to be encrypted. Must.... follow... google.... must.... follow..... google... must ..... follow...... google.....

          Google wants things encrypted to protect their ad and analytics revenue streams.

      • Not every connection on the web needs to be encrypted.

        "Anything you say may be used against you in a court of law."

        It's like TV stations bragging that even their news is in high-def - it's the fucking News.

        No, it's like TV stations keeping their front doors locked: just a sensible precaution.

    • By definition, anyone here is someone the NSA doesn't care about anyway, so who cares about encryption?

    • Re: (Score:2)

      by tepples ( 727027 )

      For a long time, Slashdot offered "subscriptions" that allowed ad-free use, and it redirected non-subscribers' HTTPS hits to HTTP because ad networks took so long to add encryption support. But over the past year at least, it has switched from a subscription model to offering reduced-ad access to users with Excellent karma, possibly on the basis that comments from Excellent users bring in more page views.

      • But over the past year at least, it has switched from a subscription model to offering reduced-ad access to users with Excellent karma, possibly on the basis that comments from Excellent users bring in more page views.

        Slashdot has allowed users with Excellent karma to disable ads for a very long time. I don't recall how long, exactly, but it's several years. Well before subscriptions were introduced.

        • Re: (Score:2)

          by GiMP ( 10923 )

          Subscriptions were added in 2002. I think the ad-free for Excellent Karma users followed, but I could be mistaken. It's been well over a decade in either case.

          • I'm pretty sure I already had ads disabled when subscriptions were added. I remember wondering why I would pay to get the same thing I already had. Though I did actually subscribe for a while, mostly because the site was valuable and I wanted to support it. Getting to see articles a few minutes early was nice, too.

    • True. And while slashdot comments aren't encrypted, most of them are obfuscated.

  • At least we hope so.

  • How long has this warming been occurring? (Score:3)

    by QuietLagoon ( 813062 ) on Friday December 11, 2015 @01:55PM (#51101499)
    Why should we downgrade the security of the internet for stragglers who refuse to update their security?

    .
    Maybe a loss of Internet access is just the jolt they need to get off their butt and upgrade.

  • Most web servers do that automatically. I'd be willing to bet that 99.999% of the web servers in use do, actually. Even the ones that can't do SHA-1 anymore, still have multiple levels they support; the server should negotiate for the highest shared level. Why is this being painted as some sort of innovation Facebook has miraculously engineered? (Effectively) every single web server and web browser out there is already doing this...

    • If I understand the issue correctly, this isn't something that can be negotiated. The problem is the hash algorithm used by the CA to sign Facebook's public key, not hash used for the content itself (which would be negotiated). Under normal circumstances a site only has one CA-signed certificate which it presents to all clients. The problem is that new browsers won't accept certificates signed by the CA with a SHA-1 hash, while older browsers will reject certificates signed with SHA-2.

  • It's irrelevant (Score:3)

    by Alioth ( 221270 ) <no@spam> on Friday December 11, 2015 @02:12PM (#51101621) Journal

    It's irrelevant, anyway - PCI-DSS will mandate it at some point for any site that accepts credit cards (if it hasn't already: PCI-DSS already mandates that support for all versions of SSL is dropped, and "early TLS" is dropped - they've not defined "early TLS" but TLS 1.0 is known to be vulnerable to attacks already, and TLS 1.1 is structurally weak, so I bet within a year this will be clarified to mean "both TLS 1.0 and TLS 1.1 must not be enabled" by the webserver. By June 2016 you have to get rid of TLS 1.0 if you accept credit card payments.

    Some quite recent browsers don't support TLS 1.2 by default (I think some fairly recent versions of Internet Explorer need TLS 1.2 switching on manually).

    • Never mind 2016, one of the payment processors that we are using (FirstData) forced us to turn off TLS1.0 back in June of this year!

    • Re: (Score:2)

      by mysidia ( 191772 )

      It's irrelevant, anyway - PCI-DSS will mandate it at some point for any site that accepts credit cards

      It is already required by PCI-DSS to be using the proper encryption strength, which would be SHA-2 for TLS certificates, and using SHA-1 would clearly be strictly non-compliant with the PCI DSS requirements, since current vendor recommendations and best practices say not to use certificates with old weak hashing algorithms such as MD5 and SHA-1, and Google/Microsoft have already announced that SHA1 i

      • Re: (Score:2)

        by Alioth ( 221270 )

        Google Chrome already treats SHA-1 as insecure (big red crossed out HTTPS in the address bar). Unfortunately, one of the users of SHA-1 is my bank! The very same bank that insists we be PCI-DSS compliant.

  • You have to update eventually... let the old things rot. Why do we even have to support the old junk anymore?
  • Why, exactly, would it be a good thing to use some sort of janky hack to allow people to use encryption that we strongly suspect of being dangerously broken, or close to it?

    Yes, it's unfortunate that there are people stuck on hardware or software that can't handle updated algorithms; but their ability to use encrypted communication is compromised by the fact that SHA1 is tottering, not by the fact that some servers might stop negotating connections using it. Is there some benefit I'm not understanding he

  • that don't support SHA-2 will be left without access to encrypted websites.

    This is much ado about nothing. The devices that cannot support it are dead ended already, They are not safe to use, so it makes sense that very soon they won't even be allowed to be used with SSL websites, even if the Webmaster wanted them to work. All the SSL websites I manage are already using SHA-2 certificates Besides you DONT use an OS without SHA2 support and have zero issues today

    Also, the SHA-1 certs are consid

  • How does Facebook/Cloudflare fallback mechanism work?

    I have saw a few explanation here about SHA1 cipher negotiation, but this is about certificate, not cipher.

Slashdot Top Deals

"I don't believe in sweeping social change being manifested by one person, unless he has an atomic weapon." -- Howard Chaykin

Close