Slashdot Mirror


Security Collapse In the HTTPS Market

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.

35 of 185 comments (clear)

  1. So offer a cost effective replacement by brunes69 · · Score: 5, Insightful

    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.

    1. Re:So offer a cost effective replacement by Anonymous Coward · · Score: 5, Insightful

      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.

    2. Re:So offer a cost effective replacement by philipmather · · Score: 5, Funny

      Spock. I win.

      --
      Regards, Phil
    3. Re:So offer a cost effective replacement by jellomizer · · Score: 4, Funny

      Paper disproves Spock

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    4. Re:So offer a cost effective replacement by Anonymous Coward · · Score: 2, Interesting

      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.

    5. Re:So offer a cost effective replacement by gstoddart · · Score: 3, Funny

      Paper disproves Spock

      And Spock Scissors Fingers.

      --
      Lost at C:>. Found at C.
    6. Re:So offer a cost effective replacement by Anonymous Coward · · Score: 2, Funny

      Romulans kill federation spy.

    7. Re:So offer a cost effective replacement by CaptainJeff · · Score: 2

      Indeed, HTTPS was originally designed as a solution for e-commerce.

    8. Re:So offer a cost effective replacement by ArhcAngel · · Score: 4, Funny

      Please don't put IE in a post recommending a security replacement for the web. It scares me.

      --
      "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
    9. Re:So offer a cost effective replacement by Code+Herder · · Score: 2, Informative

      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 that's just been busted for being a drug dealer den. It's all automatic, they just had to tell the datamining tools to flag every single person that came in and out of that house since the drug dealer moved in 4 years ago.

      I would like to say it's alarmist and stuff but for example where I live in Canada, Cop cars now have automated license plate scanners. It's all tied to your police file, DMV, ticket, etc. If *anything* is out of order like unpaid plates, broken tail light 2 days ago that you needed to repair, etc it's going to popup a warning that they should check you. I was pulled over ( rightly so ) because I was 2 days late on my driver license, the cop car just happened to be parked on the side of the street and when I drove by it signaled that a car ( with picture ) just drove by with an owner that hadn't renewed his driver license on time. The next step of this, is already in the works,it's going to be total surveillance of all car plates all the time. It's nothing ground breaking but I know where I live it's being worked on, we have a shitload of camera everywhere to monitor traffic, it's just a natural extension of that. They'll just signal in somewhat real time the position of a car the cops want tracker and I imagine at some point they'll extend it to unpaid license plates and stuff. Obviously that system works mostly in urban areas. I can't find the news article about it, but I read about it almost a year ago IIRC.

    10. Re:So offer a cost effective replacement by CastrTroy · · Score: 5, Interesting

      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.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    11. Re:So offer a cost effective replacement by NatasRevol · · Score: 4, Insightful

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

      --
      There are two types of people in the world: Those who crave closure
    12. Re:So offer a cost effective replacement by hey! · · Score: 4, Interesting

      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."

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    13. Re:So offer a cost effective replacement by __aaclcg7560 · · Score: 2

      I'm sure the Gorn loved being fingered by a Vulcan.

    14. Re:So offer a cost effective replacement by Curunir_wolf · · Score: 2

      Why do you care when you are not liable?

      Maybe. Sometimes. I'm currently out $120 from a fraudulent charge that was approved anyway (it was a debit card on my bank account). The bank credited me when the fraud report was submitted, but then the merchant came back and said "Well it looks legit to us, even though a completely different name than the one on the card was used, and we shipped the stuff to a different state." MasterCard went along with that, and took my $120 and handed it over to Newegg. Since April, numerous letters, calls, and emails have yielded no response at all.

      So if MasterCard decides they're not going to cover it, that's it. You pretty much have no recourse. And they do that, even when the charges are clearly fraudulent.

      --
      "Somebody has to do something. It's just incredibly pathetic it has to be us."
      --- Jerry Garcia
    15. Re:So offer a cost effective replacement by Solandri · · Score: 2

      Why do you care when you are not liable?

      Why do you think caring should stop with liability? The merchant who ends up paying for fraud just raises their prices to make back the lost money. So you are still paying for the fraud whether or not you're directly liable.

    16. Re:So offer a cost effective replacement by IgnitusBoyone · · Score: 2

      I would cancel my relationship with mastercard. It might also help to never shop at newegg again and to convince others as well. My highschool job was working retail. I was taught something like one unhappy customer was 200 grand in business.

      That story is pretty convincing you. I would make it my goal to make people aware of it.

      --
      Momento Mori
    17. Re:So offer a cost effective replacement by lister+king+of+smeg · · Score: 2

      telnet is great for wathcing ascii art starwars, there is a suitable application

      (telnet towel.blinkenlights.nl)

      --
      ---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
  2. locks, doors, ... by silfen · · Score: 4, Insightful

    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.

    1. Re:locks, doors, ... by Anonymous Coward · · Score: 2, Insightful

      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.

    2. Re:locks, doors, ... by CopaceticOpus · · Score: 4, Insightful

      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.

  3. Problems with TLS and PKI by NotInHere · · Score: 4, Insightful

    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.

  4. For internal use? by phorm · · Score: 3, Insightful

    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 name" registrar.

    Perhaps one solution would be to have an easily deployed appliance/distribution that runs as an internal certificate store.

  5. broken implementation! = bad protocol by raymorris · · Score: 5, Informative

    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.

  6. Folks.... by Anonymous Coward · · Score: 5, Interesting

    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.

    1. Re:Folks.... by Curunir_wolf · · Score: 4, Insightful

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

      --
      "Somebody has to do something. It's just incredibly pathetic it has to be us."
      --- Jerry Garcia
    2. Re:Folks.... by WuphonsReach · · Score: 2

      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 and possible corner cases, but it's far better then depending on the current CA model.

      --
      Wolde you bothe eate your cake, and have your cake?
    3. Re:Folks.... by Marillion · · Score: 2

      For example: Hong Kong Post Root; DoD Root CA 2; Federal Common Policy CA; Staat der Nederlanden Root CA - Any of these CA can mint a certificate for ANY website.

      Keep in mind that any sufficiently powerful nation is better served sending lawyers rather than hackers. Step One: All it takes is to send a court ordered warrant with gag-order to get the private key for "Go Daddy Root Certificate Authority - G2". Step Two: Mint certificates

      We should do two things. 1) Browsers should also start displaying the root CA. If I go to Google and I know it's Google because "Autoridad de Certificacion Raiz del Estado Venezolano" says so, I'd be suspicious. 2) Fix the all or nothing problem. Somehow limit the domain scope of a CA. "Google Internet Authority G2" mints certificates for Google.Com. What's to keep them from minting one for MyBank.com?

      --
      This is a boring sig
  7. If there's a systemic problem by nine-times · · Score: 2

    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.

  8. HTTPS is not flawed by Aethedor · · Score: 5, Insightful

    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.

    --
    It doesn't have to be like this. All we need to do is make sure we keep talking.
    1. Re:HTTPS is not flawed by Josuah · · Score: 2

      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, understandable, and convenient) other than the "I trust X and X trusts Y so I can trust Y" approach we are using today.

    2. Re:HTTPS is not flawed by Kevin+by+the+Beach · · Score: 2

      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)

  9. Re:Technical flaws are beside the point by timeOday · · Score: 4, Informative
    Give the article some credit, that is largely what it is about:

    To evaluate both legal and technological solutions, an understanding of the economic incentives of the stakeholders in the HTTPS ecosystem, most notably the CAs, is essential. This article outlines the systemic vulnerabilities of HTTPS, maps the thriving market for certificates, and analyzes the suggested regulatory and technological solutions on both sides of the Atlantic. The findings show existing yet surprising market patterns and perverse incentives: not unlike the financial sector, the HTTPS market is full of information asymmetries and negative externalities, as a handful of CAs dominate the market and have become "too big to fail." Unfortunately, the proposed E.U. legislation will reinforce systemic vulnerabilities, and the proposed technological solutions are far from being adopted at scale. The systemic vulnerabilities in this crucial technology are likely to persist for years to come.

    Most all the responses I see to this story so far are kneejerk response to the summary, not very relevant.

  10. after thousands of years, why now? by raymorris · · Score: 2

    Your main point is a good one - there are good reasons for the complexity.

    I'm curious about the other thing you suggested. People have been making and breaking ciphers for thousands of years. For thousands of years, every algorithm* has been broken. Why would you say today's won't be? MD5 was believed to be secure for a long time, now it's thoroughly broken. What evidence is there that SHA-3 doesn't have an undiscovered weakness, given that every other algorithm has had some?

    Further, quantum computers have now actually factored semiprimes, proving the theorems. So we already know how to break existing keys, given large quantum computers. At this stage, with so little knowledge about what medium-scale quantum computing, is it not hubris to think our kids won't come up with ways to use the new powers of quantum computing to solve problems that we don't yet know how to solve efficiently?

    * "every algorithm " meaning all algorithms useful for this purpose. OTPs specifically, aren't applicable to the problem, though they are unbreakable if properly implemented.

  11. This PKI paper is a rewrite of a rewrite by ocelot.wreak5016 · · Score: 2

    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.'