Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Bug Encryption The Internet Apple

Security Collapse In the HTTPS Market 185

CowboyRobot writes: HTTPS has evolved into the de facto standard for secure Web browsing. Through the certificate-based authentication protocol, Web services and Internet users first authenticate one another ("shake hands") using a TLS/SSL certificate, encrypt Web communications end-to-end, and show a padlock in the browser to signal that a communication is secure. In recent years, HTTPS has become an essential technology to protect social, political, and economic activities online. At the same time, widely reported security incidents (such as DigiNotar's breach, Apple's #gotofail, and OpenSSL's Heartbleed) have exposed systemic security vulnerabilities of HTTPS to a global audience. The Edward Snowden revelations (notably around operation BULLRUN, MUSCULAR, and the lesser-known FLYING PIG program to query certificate metadata on a dragnet scale) have driven the point home that HTTPS is both a major target of government hacking and eavesdropping, as well as an effective measure against dragnet content surveillance when Internet traffic traverses global networks. HTTPS, in short, is an absolutely critical but fundamentally flawed cybersecurity technology.
This discussion has been archived. No new comments can be posted.

Security Collapse In the HTTPS Market

Comments Filter:
  • by brunes69 ( 86786 ) <slashdot.keirstead@org> on Friday September 26, 2014 @11:26AM (#48003643)

    Yes HTTPS is flawed. Name one protocol that is not.

    Unless someone can offer a cost effective replacement (IE one that can be deployed and scaled into without breaking existing technology) then the best approach is to continue and fix the flaws as they are found.

    The solution to a problem is not always "throw it away and re-write it". In fact the longer you are around in technology, the more you will realize that this is hardly ever a good idea.

    • by Anonymous Coward on Friday September 26, 2014 @11:33AM (#48003709)

      As with all security, your requirements depend on your threat model. What are you trying to protect against?
      I suspect most of us just don't want thieves stealing our bank passwords, social security numbers, or credit cards.
      HTTPS is probably sufficient for that.
      If you're trying to make sure the NSA can't get at data of yours that it wants, you need something else. What that is, I don't know.

      • Folks.... (Score:5, Interesting)

        by Anonymous Coward on Friday September 26, 2014 @12:01PM (#48003981)

        It's not HTTPS that's insecure, it's the current certificate authenticity chain.

        Eliminate that chain, work out a public exchange and verification program (something akin to bittorrent for
        gpg signed certificates from other people you trust.) and plug that in in place of the current certificate authority
        model and you're set.

        This does of course require you to have people you trust who have some way to verify they got the 'original'
        copy of the certificate, and doesn't preclude using the equivalent of modern certificate authorities if desired.
        It simply provides 3rd party verification if something appears to be up.

        If you need a good example of how this might be carried out, look up 'WASTE', then imagine combining that with slashdot's rating system utilizing the old Kevin Bacon skit about 6 degrees of separation. That should provide secure peering with a layer of trust model that would dwindle the farther away from you a 'trusted individual' is positioned. It's not as 'cheap' in terms of cpu, disk space, or memory requirements as the current system, but it would be harder to exploit than the current centralized system.

        • Re:Folks.... (Score:5, Insightful)

          by Curunir_wolf ( 588405 ) on Friday September 26, 2014 @01:12PM (#48004605) Homepage Journal

          Mod parent up. While the poster's solution may not be the right idea, he's absolutely identified the problem: profit-driven central authority.

          • Re: (Score:2, Insightful)

            by Opportunist ( 166417 )

            The problem is not that it is for-profit. The problem is rather that we're supposed to implicitly trust them despite us having no reason to do so, and in the light of various revelations lately, have every reason to actually DIStrust a fair lot of them. Not because they are "evil". Just because they could not defend against the country they reside in requiring them to ... let's say "comply".

        • Eliminate that chain, work out a public exchange and verification program (something akin to bittorrent for gpg signed certificates from other people you trust.) and plug that in in place of the current certificate authority model and you're set.

          Or rather than eliminating it, secure it. A couple of proposals:

          http://www.certificate-transparency.org/ provides a distributed mechanism for near real-time monitoring of certificates in use, to very quickly identify and block certificates that weren't issued legitimately.

          http://convergence.io/ makes the observation that MITM attacks result in some subset of the Internet seeing a different certificate from a given server. A distributed system of crosschecks identifies sessions which are being attacked.

        • Eliminate that chain, work out a public exchange and verification program (something akin to bittorrent for gpg signed certificates from other people you trust.) and plug that in in place of the current certificate authority model and you're set.

          DNSSEC + DANE

          It limits the damage a lot more then the current "trust the CA completely" model. A rogue CA can only damage / MitM certificates that they have issued without raising red flags in the SSL stack.

          Is DNSSEC+DANE perfect? No, it has some rough edges
        • by chihowa ( 366380 ) *

          A decent stepping stone would be to allow multiple CA signatures on a certificate. Then, a user can decide how much they trust a certificate based on which CAs trust that certificate. As an added bonus, and verified through DANE [wikipedia.org] or the like, it would be necessary to compromise multiple CAs in order to present a forged certificate. This moves us toward the big web of trust that you propose.

          Once this is set up, we can start pruning the massive implicitly trusted root CA list and bring a little sanity to who w

      • Indeed, HTTPS was originally designed as a solution for e-commerce.
        • by CastrTroy ( 595695 ) on Friday September 26, 2014 @12:14PM (#48004097)
          And it's the wrong solution. The solution is that I shouldn't have to send my credit card number to every retailer I want to do business with. The credit card companies and banks should have set up a system long ago so that I can send money to a retailer without having to divulge my private information to a non-trusted third party. Paypal offers something which is halfway in between. I can pay people without having to send them my credit card info. Unfortunately, I have to trust PayPal. It would make much more sense for the bank to be in control of this, since they have all the information anyway, and I would hope that they know how to keep it secure.
          • by NatasRevol ( 731260 ) on Friday September 26, 2014 @12:27PM (#48004237) Journal

            Sounds like you just listened to the Apple Pay part of their announcement at the beginning of the month.

            • by thule ( 9041 )
              I know people think Apple invented NFC payments, but they didn't. This is NOT unique to Apple Pay. Apple Pay is an implementation of a standard. Google Wallet is an implementation of the same standard. Either way, the vendor/POS terminal does NOT get the CC# during the transaction.
          • Our over-reliance on credit card numbers as "keys to the kingdom" is indeed bad, but what does it have to do with SSL?

            15 years ago I had an MBNA credit card. On their website you could generate a one-time credit card number that was only good for the stated amount. That was a big improvement. I guess not enough people bothered to use it though.

            • Well, in the original days of the web when everything was wired, and even so to an extent today, even with so much stuff being wireless, it's not very likely that somebody is going to steal your information by listening in on your connection to steal 1 credit card number. Instead, they're just going to break into the retailer's servers and steal 100,000 credit card numbers at once. A lot more gain for a lot less effort.
            • by Lorens ( 597774 )

              15 years ago I had an MBNA credit card. On their website you could generate a one-time credit card number that was only good for the stated amount. That was a big improvement. I guess not enough people bothered to use it though.

              I have this system today, and my "real" card number, while valid, is systematically declined for Internet transactions. It's common enough that Amazon (at least the French Amazon) has an FAQ on the problems it can cause (bigger orders can be split up, and Amazon debits each packet separately). Some sites refuse the virtual card, but I can real-time the on/off switch on my bank's website to use my "real" card number just for the necessary number of seconds. Not ideal, but better than most.

          • The solution is that I shouldn't have to send my credit card number to every retailer I want to do business with.

            The online retailer knows what you are buying and it needs a shipping address, and e-mail address and/or or phone number as a point of contact. Simply shopping the brick and mortar stores exposes pretty much everything anyone would want to know about your health, income, employment, housing, marital status, lifestyle choices and so on.

          • by mwvdlee ( 775178 )

            In the Netherlands, we have such a system (called "iDeal").
            As far as I know, atleast Germany and a few scandinavian countries have similar systems.
            I dare bet a lot of countries have such systems as well.

          • Google "Secure Electronic Transactions.". TL;DR: It got a bit of traction in Europe but basically none in the U.S. (presumably due to different credit card liability laws).
          • I really liked PayPal's solution for limiting risk when paying sites that didn't support PayPal. Their Virtual Debit Card product was great. I could provide whatever information I wanted, restrict the virtual card to exactly the amount of the transaction, and optionally allow it for recurring transactions. They were awesome, especially when purchasing from small companies with very little information about if they were legitimate or not.

            PayPal if nice and all, but plenty of people fall for the common t

      • Re: (Score:2, Informative)

        by Code Herder ( 937988 )
        I agree that currently, objectively even if it's uncomfortable to have the government read and log all my electronic communications I'm not *currently* hugely worried about it. I'm much more worried about thieves, etc.

        The problem is what's going to happen moving forward? The logical end game, is total surveillance of everything electronic/physical ( with cam, image recognition ) where the police comes knocking on your door because your phone GPS logs and CCTV show that 2 months ago you were in a house th
      • by reikae ( 80981 )

        Or our Battle.net accounts, which have better security measures* than anything on your list :-)

        *Stronger passwords than my online banking allows plus a one-time pad and SMS confirmation for actions such as changing passwords. My bank has a one-time pad too but from what I've gathered from comments on /. that's not as common as it should be.

        • What kind of one-time pad? If it is not a true two factor system (i.e. the old fashioned paper OTP numbers) it's worthless.

          • by reikae ( 80981 )

            It's just an indexed list of short codes, bank's website tells which index to use when logging in and also when doing wire transfers or other important stuff. Each of the 300 codes are used only once obviously.

            Could you elaborate on the worthless systems? Is my bank's system one of those and if not, what would these systems be like exactly?

            • Imagine a trojan in your computer that is able to manipulate webpages in between them arriving at your machine and you seeing them. Like, say, a browser plugin. Adblockers and the like do pretty much that. And no, sadly HTTPS is no safeguard against that because these plugins hit after decryption and before encryption, i.e. they get the plain text. Then, the plugin waits for you to make an actual transfer. And here is what happens then:

              You type in that you want to transfer, e.g., 100 bucks to Water&Powe

      • A few tactical nukes, well placed, should do.

    • For internal use? (Score:3, Insightful)

      by phorm ( 591458 )

      HTTPS/SSL, but with the signing, distribution, and recovation done in-house. The big SSL vendors seem to often be prone to poor security, as well as possibly succumbing to the demands of certain government agencies and providing "private" keys.

      At least if your certificate is signed in-house, you have control of your certs and a certain amount of extra protection against the above. This might not be a good solution for smaller shops, but mid/medium shops could accomplish this, it's just easier to use a "big

      • by devman ( 1163205 )

        SSL cert vendors should never have your private key, and I've never seen one that needed it. They only sign you public key when you generate a certificate signing request.

        • by tepples ( 727027 )
          If your SSL cert provider is also your web hosting provider, then your SSL cert provider has your private key because your web hosting provider needs your private key in order to provide service.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      There was an offered solution, and a damn good one that was highlighted here on /.
      http://it.slashdot.org/story/12/07/25/1612236/father-of-ssh-says-security-is-getting-worse

      SSH extension to http and some clever simplistic key management for end users. DONE.

      • by tepples ( 727027 )

        http://it.slashdot.org/story/12/07/25/1612236/father-of-ssh-says-security-is-getting-worse

        The article linked from that Slashdot story states:

        Page not found

        The Network World page that you have requested cannot be found by our friendly robots. The page you are looking for may have been removed, had its name changed, or may be temporarily unavailable. If you followed this link from outside our site, we'd appreciate if you'd let the owner of the referring site know.

        So is the solution just to take everything off the web entirely? But then I realized that can't be right, and the real article is here [networkworld.com]

    • Like all technology, it's really about what you are trying to protect. For most people and applications HTTPS is probably enough, if you're protecting multi-billion dollar transactions or infrastructure then you should use something stronger. Think of it like door locks -- all are flawed, but it's not worth spending $1 million on security to protect a $300,000 house.

      I'm reasonably satisfied with the level of protection from HTTPS for my twitter posts and even banking.

      As an aside, is the Microsoft HTTPS impl

    • by ArhcAngel ( 247594 ) on Friday September 26, 2014 @12:05PM (#48004025)
      Please don't put IE in a post recommending a security replacement for the web. It scares me.
    • ...the best approach is to continue and fix the flaws as they are found.

      You mean *after* they've been known about for years by blackhats - or far more likely and terrifying - the TLAs.

    • IE

      The sooner that corporate IT can abandon Internet Explorer (especially IE6), the better off everyone will be.

    • by hey! ( 33014 ) on Friday September 26, 2014 @12:29PM (#48004265) Homepage Journal

      Yes HTTPS is flawed. Name one protocol that is not.

      TELNET. Of course "flawless" means "meeting its design goals," it doesn't mean "suitable for any application."

    • by mlts ( 1038732 )

      Problem is that SSL, and to a lesser extent SSH suck, but almost everything out there is worse, barring physically dropping off a large drive array and using one time pads on each endpoint.

      SSL for public web servers is tough to fix. Have more than 2 CAs sign a key? What keeps two CAs from being compromised? Have a revocation list, the bad guys can block that from propagating. Have a key get "known" may be an add-on, but some sites use hundreds of server keys and change them out often.

      For other tasks, it

      • Have a key get "known" may be an add-on, but some sites use hundreds of server keys and change them out often.

        Then let an organization be the CA for its own registered domain, and let it issue certificates for these "hundreds of server keys". DNSSEC with DANE was supposed to do this, at least at the same assurance level that domain-validated certificates are intended to provide.

        Other tasks might work with an out of band method for distributing and authenticating keys.

        Good luck describing that out-of-band method for distributing the key for every single web site you visit. The only decent proposals I've read are the status quo (X.509), DANE, and Perspectives. Perspectives checks a server's key fingerprint

  • locks, doors, ... (Score:5, Insightful)

    by silfen ( 3720385 ) on Friday September 26, 2014 @11:32AM (#48003691)

    Every lock, every door can be attacked and broken. It's no different with protocols. We don't stop locking our bikes or cars just because a government soldier with an M16 can shoot the lock open.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Exactly. Security requirements depend on the threat model.
      Just because the NSA can read your data doesn't mean the civilian crooks can get your bank password.

    • by CopaceticOpus ( 965603 ) on Friday September 26, 2014 @11:51AM (#48003869)

      Physical locks still need to be broken manually, one door at a time.

      When it comes to https, all locks can potentially be opened at once, remotely, with the click of a button, and with no sign of intrusion. It's hardly the same.

    • by arth1 ( 260657 )

      Every lock, every door can be attacked and broken. It's no different with protocols. We don't stop locking our bikes or cars just because a government soldier with an M16 can shoot the lock open.

      But in real life, we also are better at spotting when locks don't serve a purpose. Most of us don't have double bolt locks on our bathroom doors, and businesses don't keep their doors lock and run out to unlock it for every customer.

      Sometimes it's not the door that needs protection, but the valuables themselves.

    • by hey! ( 33014 )

      If your bike was made of solid gold, then a conventional bike lock would be useless. Also your bike would be very heavy.

      The point is that your analogy has some flawed interpretations. What you're saying is that the use value of riding your bike anywhere outweighs the expected cost of its being stolen. That's completely valid. Likewise the marginal cost of a more sophisticated lock may not be worth the marginal reduction in expected theft-cost.

      But information has a wider range of uses and values than a bi

  • by NotInHere ( 3654617 ) on Friday September 26, 2014 @11:49AM (#48003843)

    goto_fail is just a bug like every else. Its a major bug, yes, but its "only" a bug. There are more systemic issues.

    PKI is broken. Diginotar was just one indident we know of. CAs can secretly give everybody any cert they want. We need a system where the CAs need have to publish their certs, and which itself can't forge. Certificate transparency only centralises this "tree of trust". We still need to give the tree a ground to stand on. This can be achieved by gossip protocols. With all these measures, we don't need CAs anymore. CA is a multi-million dollar industry, they won't like being obsolete.

    Third point: Microsoft. They haven't added usable perfect forward secrecy until april 2014.

    Fourth point: the users. They don't care, or other things are more important to them (stability, etc): Most of them don't update their browsers regularly. I don't critizise clicking away security warnings [microsoft.com].

  • by raymorris ( 2726007 ) on Friday September 26, 2014 @11:56AM (#48003921) Journal

    OpenSSL's heartbleeed bug was a bug in openssl, a buffer overrun that didn't really have anything to do with ssl. A similar bug in any other server software would be approximately as bad. Where https protocol specified a ping, openssl instead leaked the contents of arbitrary memory locations .

    Apple's goto bug was Apple's bug. Again, little to do with the protocol. Ssl/tls/https didn't fail here, the company failed to implement https.

    The one "fault" of the protocol in the cited cases could be that it isn't brain-dead simple. Since the standard isn't idiot-proof, idiots can screw it up.

  • That's why I prefer to use a VPN
  • by nine-times ( 778537 ) <nine.times@gmail.com> on Friday September 26, 2014 @12:12PM (#48004075) Homepage

    If there's a single systemic problem with HTTPS, it's that we're still largely relying on Certificate Authorities which charge a lot of money. The expense and complexity discourages people from using SSL more ubiquitously.

    I'm not saying it's a perfect security scheme, but my point is that the single biggest problem with it is that we're not using it enough.

    • by heypete ( 60671 )

      If there's a single systemic problem with HTTPS, it's that we're still largely relying on Certificate Authorities which charge a lot of money. The expense and complexity discourages people from using SSL more ubiquitously.

      Cost is an issue if you're buying VeriSign certs for hundreds of dollars, but why waste your money? (Answer: nobody got fired for buying VeriSign, and big companies think customers care about the "trust seals"). Other CAs offer OV or EV certs for less than $200/year.

      DV certs are incredibly cheap. StartSSL offers DV certs for non-commercial purposes free-of-charge. For paid certs, they only charge for what costs them money: ndividuals can get their ID verified for $60/year and issue unlimited Class 2 certs.

      • DV certs are incredibly cheap.

        But the certificate is not the only cost of upgrading from HTTP to HTTPS, as not all browsers still in use support Server Name Indication [wikipedia.org]. Without SNI, a browser can see only the first certificate associated with port 443 of a given IP address, which requires your domain to have its own IP address as opposed to name-based virtual hosting. In the era of IPv4 address exhaustion, some hosts have started charging $60 per year for a dedicated IPv4 address (source: godaddy.com). The leading SNI-ignorant browsers

  • Well done, authors obviously spent a lot of time on it. Splitting implementation and deployment was refreshing to see.

    Fundamental problem is aggregation of power/value is an irresistible beacon of abuse. From criminals to states the more value protected the bigger the effort to coopt the system.

    I have two "practical" ideas which might help slightly..

    1. Replace CA's with DANE or something like it. We already have global view of naming.. Trust should flow from ownership of names as a standard feature of do

    • I'm convinced that the refusal of browser companies to implement DANE is directly influenced by security services and CAs.

  • by Aethedor ( 973725 ) on Friday September 26, 2014 @12:18PM (#48004151)

    From a technological point of view, it's a good protocol. It works and when implemented correctly, it's very secure. However, a PKI is not much about technology. It's mostly about organisation. In other words, it's not about PK, but all about I.

    And that's were most things go wrong. Yes, Heartbeat was about technology, but people who paid attention moved away from OpenSSL a long time ago. There are more than enough alternatives. GnuTLS and PolarSSL for example. Apple's gotofail was also about technology, but name me one piece of software that is 100% bug free.

    The real problem with HTTPS is how it's organized. When I install a browser (or get one via the OS), I also get a shit load of CA's which I'm supposed to trust. CA's from China, Turkey, Taiwan and other countries from which I don't even speak the language. I will never need a certificate from one of those CA's, because I will never need a secure connection with any website protected by their certificates. If the people from Iran were wise enough to realize that they don't need Diginotar because they don't speak Dutch, they would never be at risk because of Diginotar's epic failure. The first thing I do when installing a web browser is get rid of all the irrelevant CA's. Just to be sure, just to be safe.

    And that's what's wrong with HTTPS. That's what needs to be fixed. Trust shouldn't be imposed by a browser maker. Trust should be earned.

    • by Josuah ( 26407 )

      I had tried using GnuTLS for a while in one of my builds (with libcurl, I think), but found it didn't always work right while OpenSSL did. I'm not sure if that is because I had to do something different with GnuTLS, but it just wasn't happy as a drop-in replacement.

      Anyway, I don't think "trust should be earned" works. If you visit a banking or shopping web site, in what way are they supposed to earn your trust before you do business with that web site? I can't think of a particularly good way (scalable, und

      • I encourage you to try PolarSSL. It's really good and easy to learn. I replaced OpenSSL with PolarSSL in my own open source project within a few days and the only thing I regret is not doing it earlier.
    • Great comments and observations. CA's are the weak link in the current HTTPS model. (unfortunately trust has been broken, and millions of computers are delivered with CA configurations that most users are not aware of)
  • Security prevents casual theft. When vulnerabilities are found, we fix them, to maintain a basic level of security. Sufficiently determined criminals may be able to break your security anyway. With https, the route that is always open is directly monitoring your computer directly, where the data is unencrypted. They are, after all, criminals - and it is the job of our governments to help chase them down and put them out of business.

    What is frightening about the today's situation is the discovery that many w

  • These guys have been refreshing and flogging variants of this paper for a year or two. Annoying, particularly as they continue to parrot some inaccuracies that have already been refuted many times by the security community (such as the "1000s of CAs"). This is just a new incarnation of their paper; I liken it to 'kicking a dead whale down the beach.'
  • HTTPS isnt flawed. Any protocol like this would have implementation issues. These are implementation problems, not a problem with HTTPS design itself.

The computer is to the information industry roughly what the central power station is to the electrical industry. -- Peter Drucker

Working...