back to article Let's Encrypt plugs hole that let miscreants grab HTTPS web certs for strangers' domains

Let's Encrypt – a SSL/TLS certificate authority run by the non-profit Internet Security Research Group (ISRG) to programmatically provide websites with free certs for their HTTPS websites – on Thursday said it is discontinuing TLS-SNI validation because it's insecure in the context of many shared hosting providers. TLS-SNI is …

  1. Anonymous Coward
    Anonymous Coward

    Just before people start blasting Let's Encrypt saying that a free cert provider with an automated system is always going to be a risk the following should be considered first.

    - The issue was in the specification: TLS-SNI-01 and TLS-SNI-02

    - The specification did not take into account shared hosting providers who don't do domain validation

    - Many cloud providers allow any domain to be set up that isn't already in use so you can set up a complete system ready to go before pointing your dns to it

    - The issue affects subdomains where dns is pointing to the shared service and then has a binding on http (port 80) but no binding for https (443)

    - Other CAs who correctly follow the specification for TLS-SNI-01 and TLS-SNI-02 using automated methods may also have issues.

    - Let's Encrypt were extremely fast to respond to the incident disabling TLS-SNI within 2 hours of the first report

    1. Anonymous Coward
      Anonymous Coward

      "Just before people start blasting Let's Encrypt"

      Sure, even Intel chips were safe is OS developers didn't decide to map kernel memory into user space. Most vulnerability happen because of a chain of events - starting with something not as safe as ti should.

      Face it. To really trust certificates we need proper vetting procedures and identification of who's behind a certificate. Otherwise they are just good to encrypt communications with an unknown party - and you don't really need X.509 certificates for that.

      The other methods are not affected for *now*. Let's wait...

    2. brotherelf

      Let me just point out the affiliations of the authors of the spec: Cisco, EFF, *Let's Encrypt*, UMichigan.

  2. Anonymous Coward
    Anonymous Coward

    Why does this not affect HTTP-01 challenges as well, on a shared hosting provider that does both http and https?

    1. Lysenko

      With an HTTP-01 challenge, the client (cert requester) has to prove it controls HTTP (Port 80) for the domain. With TLS-SNI-01 it only had to prove it could reply from the same IP address as the domain.

  3. Anonymous Coward
    Anonymous Coward

    It seems something else is still fundamentally broken though.

    If someone points "investor.example.com" to the IP address a hosting provider but doesn't use it, it seems nothing stops another person on that hosting provider from setting up a virtual host for "investor.example.com"

    1. Anonymous Coward
      Anonymous Coward

      But this would be the case if you pointed a domain at anyone else's server, shared or not. they could set up a website on that server and use that domain.

      It's the reason you don't point a domain at a server you don't control.

  4. Anonymous Coward
    Anonymous Coward

    Too much trust being put into certificates?

    Why can't we treat HTTPS for what it is: an encrypted connection between the browser and the website, and nothing more. The audience is constantly meant to believe that HTTPS = more secure and although there is some truth in that I also think it becomes overrated when certificates are being used as some form of proof of identity.

    GPG works because it gives us users the freedom to determine our own web of trust. If I have your key it's up to me to decide if I trust you enough to validate other people's keys. Effectively resulting in your signature giving only as much value as I put trust in it.

    But X509 certs? Not so much. Basically we have to trust a bunch of CA's "because" (usually because they paid for the privilege) and that trust is more or less absolute. While we do have control over who we trust (though I doubt many people would rummuge around their cert storage) it's either "yes" or "no", there are no partials and you also can't demand that a key is signed by multiple CA's.

    I think it's strange (but also not that strange) that this has never been changed, maybe even trying to apply GPG's web of trust design into the X509 hierarchy. Of course it's not that strange because many bigger companies earn quite a bit of money with selling certificates so obviously they want to protect their revenue. There's a higher preference for adding even more "authentication" stuff based on closed standards within the x509 hierarchy than making things more accessible.

    But making things more accessible - generally speaking - also tends to increase overall security. I believe the open PGP standard is a good example of that.

    Why not simply use X509 for what it is: an encrypted connection which prevents 3rd party snooping as best as possible. But it doesn't mean squat about the legitimacy of liability of a website.

    1. Anonymous Coward
      Anonymous Coward

      Re: Too much trust being put into certificates?

      GPG doens't work exactly because you have no way but your judgement or direct communication to trust a key. It's OK for a small number of entities you know directly, it can't work at scale when you need to contact entities you never heard of before.

      The CA idea is correct - but it's implementation is not. CA can't be just commercial entities that makes money selling certificates. Otherwise they will chase the bottom line to sell as much certificates as they can. Just look at what happened to domain names.

      CA should have strict rules to emit certificates (with proper vetting) and be strictly monitored, and held liable for any mistake. That has a cost, but it's inevitable.

      Encryption without authentication can be handled without these certificates.

      We could split the system between authentication CA and their certificates, and encryption only one. The latter could be free or cheaper, but they should be flagged as potentially dangerous.

      Anyway you can install and trust your own CAs, but that's irrelevant.

      1. Anonymous Coward
        Anonymous Coward

        Re: Too much trust being put into certificates?

        > GPG doens't work exactly because you have no way but your judgement or direct communication to trust a key

        Beg pardon?

        There are many trust models to choose from with GPG and plenty of mechanisms for assigning trust (e.g., DNS, web key service, linked identities, ...), with face-to-face being just another one. Trust is not a binary quality either, and that is reflected in the OpenPGP model. At my company, our trust model is described in a policy document and implemented with a combination of processes and technologies going from WKS (web key service) to face-to-face key assignment to old school notarised documents on paper.

        For another, what you announce as a theoretical possibility of "splitting" authentication from encryption seems to describe trust on first use, which anyone who has ever typed "ssh" on a command line is more than familiar with, and which we are now also using with OpenPGP.

        OpenPGP works, and it works very well and in a scalable manner.

        1. Anonymous Coward
          Anonymous Coward

          "There are many trust models to choose from with GPG"

          And all of them imply you trust them - aka some kind of "authority" which is trusted by default, or because you choose to trust it - where's the difference from a CA?

          Good, inside your company, but outside of it? If you have to communicate, say, place an order with a company for the first time? Do you go through "old school notarised documents on paper" to ensure their website is actually theirs? Or when you book a room in an hotel in a city you never been before?

          All the authentication model work or on mutual trust, on relying on a third party "authority" trusted by both parties.

          1. Anonymous Coward
            Anonymous Coward

            Re: "There are many trust models to choose from with GPG"

            > And all of them imply you trust them - aka some kind of "authority" which is trusted by default, or because you choose to trust it - where's the difference from a CA?

            ??? Complete non sequitur. Not meaning to be offensive, but what exactly is your security background and experience?

    2. Orv Silver badge

      Re: Too much trust being put into certificates?

      I think the problem is encryption without some form of proof of identity only creates an illusion of security; you don't know if the connection is to your intended website, or to a man in the middle who's posing as the legitimate site (and then possibly forwarding the traffic on to it.)

      About the only thing that un-authenticated encryption does is slightly deter bulk data collection and storage. It does nothing for any kind of targeted interception.

      1. Anonymous Coward
        Anonymous Coward

        Re: Too much trust being put into certificates?

        You can't do a MITM unless you can get a wildcard certificate for every domain (or generate on the fly during the handshake) because you have a root certificate installed on the user's PC.

        This *should* never happen as the trusted root authority wouldn't allow the use of their trusted root to create new certificates by the MITM. It has happened in the past however and the root has lost its trust.

        Even the dodgy stuff that Symantec was doing has meant they no longer get to be a trusted root but the bigger browsers, effectively ending their business in that area.

        So an internet cafe couldn't intercept you secured comms and relay them, SSL doesn't work like that. A corporate entity can because they can install a trusted root onto your PC as you are a member of the domain. Many do so that they can check inside the SSL stream for malware or company information.

        However even that can be noticed by going to a site with EV on - this is used by many companies to show that the company is who they say they - the green validation box. Also certificate pinning which would alert you that a site is pretending to be a site you have visited previously (or sometime just on the HSTS list).

        So to imply it's easy for a MITM is routine and easy is not true. There is basic authentication of sites asking for a certificate to make sure you own that particular website (which is why this has appeared as an issued as it could be subverted). It does plenty for targeted an duntargeted inception. It is also easy to spot if it is being attempted.

        1. Orv Silver badge

          Re: Too much trust being put into certificates?

          I'm not saying that MITM is routine and easy in the *current* system. I was responding to the idea that trusted third parties are unnecessary. Without them, MITM is indeed quite simple.

    3. Michael Wojcik Silver badge

      Re: Too much trust being put into certificates?

      PKI is hard.

      The public hierarchical1 X.509 PKI is a huge frickin' mess. Anyone who's looked closely at it knows that. There are plenty of presentations (e.g. "The OSI of a New Generation"), papers, and books (e.g. Ristic's Bulletproof TLS) that detail the many, many problems with X.509 itself, in specification and implementation; and with how the public X.509 PKI was constructed out of it.

      But I've yet to see a PKI proposal that doesn't have problems. Yes, the modern OpenPGP PKI, with its combination of traditional PGP partial-trust and web-of-trust features on the one hand and well-known keyservers on the other, does better in some respects. And there are theoretical schemes like Identity-Based Encryption that have other advantages. They all also have flaws.

      And more importantly we have inertia. There's no widely-deployed TLS mechanism to use a PKI other than hierarchical X.509. Moving to one would require updates to browsers and servers, and probably a TLS extension. Look how long it's taking to roll TLS1.3 out. Completely replacing the PKI is almost certainly out of the question.

      And as DV certificates continue to be devalued, EV certificates become an important source of revenue for the remaining CAs (which in turn are quickly consolidating into a handful of large players in a sea of tiny, generally even-less-reliable local ones). They won't take kindly to further undermining the paying part of the certificate business.

      1There are standards for non-hierarchical X.509 trust topologies - there's an RFC that I can't be bothered searching for at the moment, for example - but none are widely deployed.

  5. Amos1

    If your company is really serious about HTTPS security, you will not be using Let's Encrypt

    Heresy, right? Not really.

    If your company is really taking the topic seriously they will set a DNS CAA record. It's a TXT record for Certificate Authority Authorization and lists the CA's allowed to issue certificates for your domain and subdomains. ALL CA's are required to check for the presence of that record. No record means any CA can issue a certificate.

    Use Let's Encrypt, even with a CAA record, and yeah, you know what they say about "free" products... From their FAQ: "Let’s Encrypt is run by a small team and relies on automation to keep costs down. That being the case, we are not able to offer direct support to our subscribers." That does not give me a warm and fuzzy feeling. They are providing a great service but my opinion is it's not for security-centric organizations.

    Use a real, paid-for CA and list them in your CAA record. You'll have two-factor logins for your account and probably IP address restrictions. That will keep someone from creating TLS certs for your domain without your knowledge unless they can social engineer the CA into lifting the source IP address restriction as well.

    Just as importantly, see if your domain registrar can set a "lock" on your domain registration at the top level domain. That will create a multi-step process involving PINs and phone callbacks before changes will be permitted to the authoritative DNS servers. It pretty much eliminates the most common domain hijacking attack.

    No, I do not work for a CA or a registrar.

    This site will help you learn about CAA records and can give you the needed syntax as well as test your record: https://sslmate.com/caa/

    No, I have no affiliation with them. They also have a Certificate Spotter service, free for up to five domains, which will alert you if a certificate is issues for your domain.

    1. Anonymous Coward
      Anonymous Coward

      Re: If your company is really serious about HTTPS security, you will not be using Let's Encrypt

      Would you care to share with us what is it exactly that your paid certificate provides that a Let's Encrypt one doesn't?

      If you already have deployed TLS, as you probably do, it is all down to securing your domains and servers from intrusion / hostile takeover and that's nothing to do with the CA.

      If you do not have yet deployed TLS, then whoever moves in first can, without great difficulty, impersonate your organisation to the extent necessary to obtain certificates issued under your organisation's name. Again, there is no inherent protection in this unless you decide to shell out for one of those extended verification jobs. But then again, how likely are your users to care if you have got one of those or not?

      In any case, CAA was created to stop *rogue* CAs from issuing certificates (or more precisely, to stop those certificates from being accepted by clients). It does not protect against the threat model that you present, which is someone fraudulently obtaining a certificate they are not entitled to. With that said, there is talk about extending the standard to allow tying certificates to one particular user within a given CA.

      1. brotherelf
        Boffin

        Re: If your company is really serious about HTTPS security, you will not be using Let's Encrypt

        > In any case, CAA was created to stop *rogue* CAs from issuing certificates (or more precisely, to stop those certificates from being accepted by clients).

        Um, no, on both counts. A client (e.g. browser) is not in a situation to find out which CAs were authorized to issue certificates for my domain many moons ago. (Remember, current legal lifetime of certificates can exceed 36 months.) And even if it was, it wouldn't do it – already we have things like OCSP stapling, because you really don't want to have extra validity requests to a third party with every outgoing request.

        A CAA record is an advisory measure from the entity controlling DNS to the CA if it is supposed to issue certs. (Browser Forum etc. make it pretty much a mandatory best practice, but that's social/legal and not technical. Nothing stops a malicious CA from issuing anyway, hoping they will be undetected. To expose them, you not only need the public ledger of issued certificates, you also need a public ledger of past DNS states.) CAA is mostly about impersonation attacks, where mycompany.com forces you to social-engineer the CA of their choice into giving you a certificate, and not Mom and Pop Best Certs & Fried Cat5fish.

  6. Mookster
    Facepalm

    Liability

    Without any liability for misuse, it's all a confidence trick. The identity proofing done by let's encrypt isn't that far from what's done by goMommy et al.

    1. Michael Wojcik Silver badge

      Re: Liability

      The philosophy of Let's Encrypt - which for most purposes is just the philosophy of the HTTPS Everywhere movement - is that DV (Domain Validation) certificates should not be understood as proof of identity, just proof that you're connecting to an endpoint with a given name.

      Personally, I'm no great fan of LE, or HTTPS Everywhere, or the devaluing of DV certificates. But in practice DV certificates issued for payment by commercial CAs were pretty much worthless, since commercial CAs have done such an incredibly poor job.

      What we really need is something between the ever-less-useful DV certificates and the expensive, hard-to-use EV certificates. The Code Signing Working Group decided last year that EV certificates should be required for code signing, for example, which causes all sorts of problems.1 For example, EV certificates require the key be kept on a FIPS 140-2 Level 2 (or better) HSM, and the options there are either awkward2 or very pricey.

      Just another way that the public X.509 PKI is a disaster...

      1If you obey the dictats of the CSWG, that is. Initially Microsoft said they were going to enforce them, but they backed off after the backlash from developers.

      2Mostly uncloneable USB tokens, so you can only have one signing server per key, which means RAS issues and big costs if you need more than one server.

  7. Name3

    They haven't updated their own blog for a while https://letsencrypt.org/blog/ , would be a good time to do so.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon