back to article How to nab a HTTPS cert for a stranger's website: Step one, shatter those DNS queries...

Researchers in Germany have discovered how to obtain HTTPS security certificates for web domains they don't own – even if the certs are protected by PKI-based domain validation. Essentially, some certificate authorities can be tricked into incorrectly issuing the cryptographic certs, meaning a miscreant can get a SSL/TLS …

  1. Nick Kew

    Compromised CA

    Once again, the finger points at CAs as unreliable. What we need is to dispense with this single point of failure. For instance, replace the CA model with Distributed Trust Authorities, so an attacker would have to compromise every authority rather than just a single point of failure.

    1. Charles 9

      Re: Compromised CA

      I don't think so. They would only have to compromise ONE and then block the rest. Still quite possible. And I don't know of a way around this kind of system. DNS basically relies on Trent to work, and Trent can be replaced or subverted.

      1. Nick Kew

        Re: Compromised CA

        Nope. If one part of a DTA is compromised, the whole verification fails and the site flags as Not Verified.

        Oh, and btw, what's "Trent" in this context?

        1. Arthur the cat Silver badge

          Re: Compromised CA

          Oh, and btw, what's "Trent" in this context?

          Crypto-speak for a Trusted third party. Here's a complete list of names used for cryptographic roles.

          1. Korev Silver badge

            Re: Compromised CA

            Thanks, I've just learnt something new -->

        2. Charles 9

          Re: Compromised CA

          Don't think compromised. Think subverted either with or without the authority's knowledge. And as long as one is there for them to subvert, they can just block all the rest so that there's a chain of one who can give all the correct signals...don't trust him, you don't trust anyone and it becomes a DoS attack, so it's lose-lose.

  2. Lee D Silver badge

    So if you can fake packets to the nameservers coming from the IP in question, intercept the response and break it into pieces and modify the second piece, and then forward that on as if you were the original nameserver WITHOUT (or presumably BEFORE) the original nameserver packet returns... and you do this all while someone is trying to verify their domain (or else you're generating an awful lot of emails from CAs to the victim in question which will raise their suspicion), then you could get a fake cert with their name on?

    Seems to me that there's a lot easier ways to cause damage in that situation, not least just proxying / intercepting / modifying / falsifying every little packet in question including - EMAILS coming into their mailservers, which you could use to activate a domain.

    An attack, yes. One solved by DNSSEC already, no need for some fancy fix. One that hinges on what we've always known was the primary assumption - that DNS is authoritative (if these guys can proxy between you and the root and modify DNS with IP-spoofing, nobody who connects to your secure site is safe anyway). One fixed by fixing that assumption not making up ever-more-complex rules. Things like... the ACME protocols used by LetsEncrypt, for instance.

    1. LeahroyNake

      Thanks for explaining

      Your post makes more sense to me than the article.

  3. NoneSuch Silver badge

    Paranoid AF

    Strong independant crypto is a necessity to stop invaisive governments and corperations from raping our data at will.

    Almost eighty years ago, boffins in Bletchley Park cracked (up to) 88 bit Enigma by mechanical means. Today we have 256 bit AES protecting bank accounts, medical info and other private info. How secure do you really think we are today?

    Avoid any US government approved encryption method, use the strongest possible keys and above all educate yourself.

    Be paranoid, they are after you, journalists, whistleblowers and anyone who opposes our "public servants."

    1. Adam 1

      Re: Paranoid AF

      How secure are we? Our key space is 374144419156711147060143317175368453031918731001856 times larger than that 88 bit key.

      Also worth noting that enigma wasn't cracked by manually brute forcing on the 309485009821345068724781056 possible keys. At 100 billion guesses per second, this would take on average ~50 million years to search.

      Rather they used some systemic weaknesses like how it wasn't possible for a character to encipher to itself, pattern analysis to guess how many teeth were on the cogs, tricking the originator into resending the same message with multiple keys, stealing codebooks when the opportunity arose, and automating the scanning of that substantially reduced possible key surface. The weakest link of course was and still is the meat sack not following process.

      If I was $EvilGovernment$, I wouldn't even bother attacking AES directly. It doesn't have those weaknesses inherent to enigma. Much easier task to compromise the random number generator so that keys are poorly chosen, or even easier would be to exploit vulnerabilities in the system holding the keys, or trick those systems into revealing their key to an imposter.

      1. Rajesh Kanungo

        Re: Paranoid AF

        I would definitely go after the RNG too. Or the software stack to retrieve the keys. One has to just look at to realize how vulnerable our software is.

    2. Rajesh Kanungo

      Re: Paranoid AF

      Key size is not a measure of crypto strength when the algorithms are different. Enigma had fundamental flaws. It doesn't mean AES doesn't. But we currently don't know of any real ones.

      Just to further confuse the issue, AES-128 is stronger than AES-256. AES-256 refers to the key size and not the block size. Bruce Schneider and others pointed out that the number of rounds were too few.


      Look up Dan Bernstein's ChaCha, Salsa and Poly series of ciphers and MAC. They have been adopted by many non-government related entities like Google, are being proposed for various RFC's etc.

      You are right to be paranoid for a different reason ... quantum crypto attacks are coming.

      And badly implemented crypto can lead to side channel attacks. The simplest one is a timing attack ...

  4. Claptrap314 Silver badge

    Fundamental design

    Again, again, and again. If packets can be split, then the sewing back together has to be cryptographically secure. Anything else, and this will<bs><bs><bs><bs>almost certainly is being actively exploited by your local TLA.

    1. Charles 9

      Re: Fundamental design

      "...has to be cryptographically secure."

      But worse comes to worse, the TLAs can dirty the communications channels to be sure the process can NEVER be cryptographically secure: turning it into a DoS attack. IOW, if they can't sniff the channels, they can block them instead, which amounts to the least-bad scenario for them.

      1. Claptrap314 Silver badge

        Re: Fundamental design

        The TLAs have many, many ways to DOS a service. What does this one issue have to do with that?

        1. Charles 9

          Re: Fundamental design

          Point is, a truly evil regime would be willing to go MAD rather than risk losing.

  5. bert hubert

    blog post with more details

    I documented some of the history & provided diagrams describing this problem on the PowerDNS blog:

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