10

Why not get rid of all certificate authorities and all the special kind of SSL certificates there are (extended validation etc. etc.) and instead just require anyone who wanted SSL to write their own self signed SSL certificate and then have them stored in DNS records.

Wouldn't that be easier then having to put trust in both 3rd party certificate authorities and in DNSSEC? Also then you could remove those security warnings given by browsers when using self signed certificates, I mean as long as your DNS wasn't poisoned then there wouldn't be a problem, also you have a huge number of choices when it comes to DNS providers which you don't have when it comes to certificate authorities trusted by common browsers.

jake192
  • 367
  • 2
  • 8

2 Answers2

15

Why not get rid of all certificate authorities and all the special kind of SSL certificates there are (extended validation etc. etc.) and instead just require anyone who wanted SSL to write their own self signed SSL certificate and then have them stored in DNS records.

There is even a standard for this: DANE. And it is already in use with some sites, but currently mainly for SMTPS and not HTTPS.

But, it needs DNSSec to make sure that DNS lookups are not spoofed. Because otherwise a man-in-the-middle attacker could simply send its own certificate inside the DNS lookup. Unfortunately DNSSec is not widely used at the moment, so for now we have to live with the established PKI structure.

But once DNSSec is deployed deep enough DANE is a promising technology and you can use it to either use your own self-signed certificates or to have an additional trust path with the traditional CA based certificates.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Great answer, I'd also like to add this regarding DANE http://sockpuppet.org/blog/2015/01/15/against-dnssec/ it's a good argument against replacing SSL CAs with DNSSEC – Eva Lacy Aug 27 '15 at 13:00
  • @EvaLacy: I don't share the views of this article against DNSSec. The author seems to ignore that some protocols like SMTP depend on a secure DNS and TLS alone is not sufficient: if the attacker is able to provide its own MX record it will connect to the attackers host with TLS and will successfully check the certificate of the attackers host against the name of the attackers host. Similar problems are with VoIP (SRV records). – Steffen Ullrich Aug 27 '15 at 17:07
4

For as many problems as CAs have, DNS is significantly less trustworthy than the SSL CAs. SSL is one of the tools that can protect you when your DNS is being tampered with by verifying the identity of the remote server. If you move the certificates to DNS (without DNSSEC to verify the trustworthiness of the DNS response) you've just given someone who owns your DNS the ability to own your entire connection without any way for you to detect it. You mentioned DNSSEC, but it seems that you want to do the certificates without it, and that's an approach that's doomed to failure.

DNS tampering is trivial:

At the end of the day, if you're on the same network as me and I can passively see your traffic, I can tamper with your DNS responses, even without performing a MITM. DNS normally uses UDP, so when I see your request, I can "race" the legitimate server to return a response. If it needs to do a recursive lookup, or if you're going out to the internet for OpenDNS or Google Public DNS, I'm almost certainly going to win the race and inject my fake response.

David
  • 15,814
  • 3
  • 48
  • 73
  • 3
    On the other hand, the *biggest* example of DNS tampering in history was [perpetrated by Verisign itself](http://en.wikipedia.org/wiki/Site_Finder) so how much sense does it really make to trust them to provide the *solution* to DNS tampering? –  Sep 28 '14 at 21:58
  • 2
    All it takes to get a certificate is being able to read unencrypted mails sent to the domain. So if you can tamper with the DNS records, you can get a certificate for the domain anyway. – kasperd Sep 29 '14 at 00:15