9

In light of recent attacks on SSL/TLS communication, people have been asking about ways to improve the security of SSL webserver communication. Several great solutions have been mentioned in the following links (example 1, 2, 3 and blog posting).

There is a general agreement that if a network administrator uploads the website's SSL public key (or its hash) into DNS, security could be improved

The drawbacks of the proposed solution is that:

  • All recommendations for this particular solution require DNSSec, which adds complexity and has a cost associated with it.

  • Client software (browsers, Operating Systems) will require an update to actually check DNS for certificate information

In the spirit of providing immediate relief to the very broad security issue at hand, I'm questioning the assumed requirement of DNSSec. By removing this requirement, and simply allowing the website owner to dictate the SSL intermediates (or specific public keys) they want to use via DNS, we allow the content publisher (or e-commerce site) to declare what is trusted, and therefore make some attack vectors much (much) more difficult to overcome.

Questions

  1. Is DNSSec required for public key/hash distribution?

    • According to this link, DNS hacking is not a concern for the majority of users on the internet. Notable exceptions include WiFi users and certain SoHo routers are of concern. If DNSSec is only needed for these edge cases, why delay implementation for a borderline technology?

  2. Are there any threat models comparing using regular DNS as a repository as opposed to DNSSec?

    • The premise of this question assumes that although using regular DNS is imperfect, it does make great strides protecting users against a general, system-wide vulnerability.

  3. What should be stored, the hash, or the full public key?

  4. How difficult would it be for vendors to support this extra validation of a SSL/TLS certificate?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536

5 Answers5

5

Is DNSSec required for public key/hash distribution?

Yes. One has to have a trusted starting point, and in this case that's the signature of the root domain. From there, each corresponding subdomain is signed so there is a chain of continuity to demonstrate that your request was not hijacked at any step of inquiry.

Are there any threat models comparing using regular DNS as a repository as opposed to DNSSec?

DNS spoofing is already a common and low-barrier method of attack. DNSSEC was implemented primarily to prevent that. Verifying the server's certificate in the same channel as an unauthenticated DNS query provides no real security enhancement.

What should be stored, the hash, or the full public key?

In theory, one could store either to the effective same level of security. However, DNSSEC is designed around storing the whole key in order to sign zones, so I would gather that one might as well stick to storing full keys and signatures for every application.

How difficult would it be for vendors to support this extra validation of a SSL/TLS certificate?

I think the code complexity would be lower than that of verifying an SSL cert (that X.509 parsing is quite a nuisance). I suspect most browser vendors could roll this out with relatively little effort. More complex plugin systems (such as Convergence.io) are regularly written.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • Regarding "Is DNSSec required": [This answer indicates](http://security.stackexchange.com/questions/6827/how-easy-difficult-is-it-to-spoof-dns-are-some-scenarios-safer-more-risky-than-o) the threat of DNS attacks only applies to a subset of the internet, and not a majority of users. Therefore it may be acceptable to use "unauthenticated DNS queries" to solve the issue at hand, which is to reduce the risk of CA spoofing. – makerofthings7 Sep 05 '11 at 04:41
  • @makerofthings: I wouldn't want to be in that "subset of the internet". Neither would anyone. Therefore, no one would use any proposed scheme without a foundational trust as Jeff pointed out. – Nam Nguyen Sep 05 '11 at 13:06
  • 1
    @makerofthings: Spoofing DNS has challenges, though it is easiest as an active intermediary. Using a spoofed SSL certificate for an attack requires being an active intermediary. The utility of DNS key distribution without DNSSEC is *very* limited. – Jeff Ferland Sep 05 '11 at 13:30
  • @Jeff - I see your point (that is why I was interested in a threat model). Originally, it wasn't clear to me that both scenarios *require* being an active intermediary. Thank you! – makerofthings7 Sep 05 '11 at 14:01
2

DNS-Based Authentication of Named Entities (DANE) is a Standards Track RFC that allows a website owner to place the public key of a given host into DNS. A client can then use DNS to verify integrity of the current SSL session.

Section 1.2 of the RFC describes how it's possible to use DANE to trust a certificate that isn't in the trusted root store. (read: locally generated/free certificates)

Notable requirements

  • DNSSec is required
  • A secure transport such as TSIG, SIG, or IPSec must be used
  • Either the Full certificate or "SubjectPublicKeyInfo" is stored in DNS
  • One of the two items in the previous bullet will be stored or hashed in DNS
  • Certificate rotation/rollover is supported by adding multiple records for the same host
Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
2

See DNSSEC Certificates now in Chrome Stable

This allows sites to use DNSSEC, rather than traditional, certificates and is aimed at sites which currently use no HTTPS, or self-signed certificates.

It should be noted these DNSSEC Certificates do not use the DNS client-server protocol at all, so your computer will not perform any additional DNS requests:

These certificates are self-signed X.509 certificates with a DNSSEC chain embedded in an extension. The alternative would be to have the client perform a DNSSEC lookup itself.

Remember that it is just an experimental feature to play with:

The most likely outcome is that nobody uses them and I pull the code out in another year's time.

curiousguy
  • 5,028
  • 3
  • 25
  • 27
  • What is the difference between this and DANE http://tools.ietf.org/html/draft-ietf-dane-protocol-17 – makerofthings7 Mar 07 '12 at 20:04
  • There is no "TLSA RR" used in Chrome, or any unusual RR. The DNSSEC proof is sent (in place of the usual certificate chain) in the TLS session itself, so no DNS special configuration, DNS server support, DNS resolver support ... is needed. The firewall will see no "strange" packets, and this _might_ work in special conditions where full IP connectivity is not a given (like a Wifi captive portal). – curiousguy Mar 08 '12 at 21:22
1

According to this link, DNS hacking is not a concern for the majority of users on the internet. Notable exceptions include WiFi users and certain SoHo routers are of concern. If DNSSec is only needed for these edge cases, why delay implementation for a borderline technology?

DNS hacking certainly is a concern for the same people for whom the recent SSL hacks are a concern: people under oppressive governments. By controlling the ISPs they can (and perhaps do?) block/intercept traffic on a large scale through DNS.

Is DNSSec required for public key/hash distribution?

Yes. If your attacker is capable of MITMing your HTTP connections, forcing you to use SSL, he could very well be able to MITM your DNS as well.

Are there any threat models comparing using regular DNS as a repository as opposed to DNSSec?

Don't know, but try this: choosing SSL over plain HTTP is done to mitigate some of the same threats as choosing DNSSEC over DNS. Both assume an attacker that is able to intercept your traffic.

chris
  • 3,000
  • 14
  • 22
0

Without DNSSec, you can't tell that an adversary hasn't modified the certificate record you're querying for in-flight. A man-in-the-middle could easily do this.

As to how difficult it would be, that varies greatly by vendor, but it would be involved. Lots of parts of browsers, system APIs, resolver libraries, and more would have to be updated. (This would be in addition to supporting DNSSEC in general.)

Steve Dispensa
  • 3,441
  • 16
  • 20