Hacker News Reader

Comment by ryanlol | Hacker News Reader

Wait, what the fuck? Is this for real?

Here's the sample code cloudflare posted:

  foo:~$ cat /usr/local/bin/pubkeygrab.sh
  #!/bin/sh
  
  USER=$1
  
  /usr/sbin/unbound-host -v -D -t TXT ${USER}_pubkey.example.com \\
       | /usr/bin/grep -v "no TXT record" \\
       | /usr/bin/grep ' (secure)' \\
       | /usr/bin/sed 's/.* "\(.*\)" (secure)/\1/'

They aren't actually doing any authentication besides DNSSEC , giving the people managing the TLD and your registrar root access to your server doesn't seem like such a good idea.

I seriously hope I'm missing something here, but with cloudflares security track record that seems pretty unlikely.

Edit: Made the mistake of assuming that grep was actually supposed to do something here, it doesn't actually do anything at all.

View on HN

The registrar only has your public key and Cloudflare handles the private one for you. If you distribute the public key to your servers as part of the validation this means that your largest risk is actually a breach in Cloudflare.

I really really trust them, they have an impressive history of contributions to the web and commitment to security. If your servers are behind another access control layer, like a corporate VPN, this shouldn't be a big concern, since they would have to disclose breaches anyway.

Finally, I think this interesting because basically DNSSEC gives you an easy way to distribute data globally in a secure way with a TTL. This is the best benefit compared to using certificates for access control where revocation is usually very painful.

Consider this an initial look on how to use those benefits of DNS. I agree another layer of security would be great. Think something like asymmetric signature of the actual TXT record so that DNSSEC helps control expiration and then the other key validates origin. You are using DNSSEC only for the benefits of TTL validation.

I'd like to clarify that there's a _major_ issue to consider. Here's my comment on the article explaining:

Cloudflare delivers signatures for records that last more than the TTL of the record. This has the problem of replay attacks. If one employee that had access at some points configures a machines DNS to return an old DNS response it will be valid until the expiration of the signature, hence having access for more time than the actual TTL.

I just checked and Cloudflare generates signatures expiring +2 days in the future. This means that I have a TTL of 5 minutes on my record but the client is receiving old queries, authentication would pass without a problem for as long as the RRSIG is valid.

Ideally Cloudflare should sign every record with the same frequency as the records TTL, that would solve the issue.

After finding this out I think you should _not_ use Cloudflare's DNSSEC because revoking access to a user wouldn't be 100% effective until the RRSIG expiration date given the replay attack scenario.

I get why that would jump out immediately and you'd stop reading from there on, but straight after that block of code, from the article:

"Now I'm certain that a lot of readers will have something to say about the style or the efficiency of this shell script, I just wrote it that way to highlight what steps need to be taken:

    it retrieves a TXT record, and doesn't output anything if the record doesn't exist
    if unbound-host has not confirmed that the record was correctly DNSSEC signed, it doesn't output anything
    if the above is successful, it filters out the text to return only the public key
    it doesn't try to do anything complex, because complexity is the enemy of security (or at least, that’s a point of view that I share with a few people)
    it works with multiple records

I'm sure you will write your own program to do the above. Just make sure it works only when you want it to. It is critical to ensure that it doesn't return anything at least when:

    a record for the corresponding user doesn't exist
    the records are not signed or not properly signed
    the local copy of the root key (/var/unbound/root.key, here) is corrupted.

I agree that it wouldn't be a good idea to use this, unless you had configured the local resolver with overrides for the DS records forthe domain (to avoid the risk of ICANN / TLD (registry) / registrar malfeasance), but at that point, why not setup a private CA to sign the user keys? I guess maybe you wouldn't get easy distributed key revocation that way.

It verifies that the string ' (secure)' is present, as opposed to ' (insecure)'. I could have made sure it was at the end, though. I'll correct that.

Reply on news.ycombinator.com