Securing the Internet is important. However, many design decisions are broken: For example, encrypted web pages are considered less secure than unencrypted pages, even outright dangerous, unless you regularly pay a lot of money to certificate authorities, which have shown to make the Internet less secure.
The new kid on the block, DANE (DNS-based Authentication of Named Entities), shows promise to solve the problems and make ubiquitous encryption a reality. It also increases the flexibility of server administrators as well as speed and simplicity of many processes.
Encryption is bad?
At least, this is what your browser wants you to believe.
Why? The default in the Internet is to send information unencrypted: Most web sites are unencrypted and most mail servers exchange your private letters in the plain, for everyone to read.
Everyone? You are sitting comfortably at McDonald’s, Starbucks, your hotel, or any other public place with WLAN and think of no evil. Even when the hotspot asks you for a password on the web page, your actual data packets likely will be unprotected in the air. So the helpful guy in the business suit at the next table or the posh lady in the next room, both can easily listen to all your traffic: Which web sites you’re interested in (e.g. disease treatments), which comments you post in blogs, or what your friends message you.
Adding encryption would be a good thing, wouldn’t it? However, if you just create encryption keys for your server and enable encryption, many applications (including most browsers) will actually trust your encrypted server less than the previous unencrypted server! Even though eavesdropping on your WiFi connection is not good enough anymore, and someone wishes to read your traffic first needs to install some of his own equipment with strong compute power between your machine and the server.
The old role of certificate authorities
|Issuer||any of 300+ CAs||domain owner|
|Flexibility||any server with that name||individual service|
|Verification||server claims name||domain prescribes service credentials|
|Revocation||unreliable, slow, expensive||almost immediate, reliable, free|
|Costs||dozens to thousands â‚¬/year (some playgrounds for free)||no additional|
Weirdly, raising the bar for attackers does decrease the amount of trust the average browser puts into the server. Unless you pay tens or hundreds of Euros annually to a certificate authority (CA) for creating a few digitally signed bytes saying „We trust this server, so should you“.
Even though the verifications are often minimal such as calling you on the phone asking for your birthday, now your server is considered to be trustworthy by the browsers. Strange!
It gets even weirder when you think that your neighbor, competitor or ex-lover can go to any of the other 300+ certificate authorities and ask them to give him a certificate for your server. Answering the above phone call correctly should not be a problem. There have been
- CAs which did not properly secure their systems, so anyone could hack into their systems and issue certificates to impersonate anything they wanted, and
- CAs which did hand out certificates in the name of other organizations, including Google.
Besides the abuseÂ potential with 300+ CAs, all fully trusted by the applications, the current CA infrastructure has the problem when revoking compromised certificates or encryption keys.
In short, CAs currently are all-powerful but neither do live up to their responsibilities nor can they solve today’s problems. They are 300+ single points of failure, as each is able to bring the entire system down, but not really providing any of the efficiency or efficacy benefits commonly associated with centralized solutions.
Changing the game
DANE to the rescue!
DNS-based Authentication of Named Entities, or DANE, is on the way to revolutionize the certificate problems. The goal is to put the control over certificates and encryption keys to where they belong: To the organization operating the servers and holding the domain name associated with the server.
The Domain Name System, DNS, already today directs client computers wishing to talk to
www.example.com to IP addressÂ
192.0.2.2. With DANE, they get additional information about what keys or certificates to expect once they connect.Â DNSSEC, the security extensions to DNS, allow the receiver to verify the authenticity and freshness of this information. Thanks to the direct connection to the organization responsible, DANE is much more direct, reliable, and can react more quickly; solving the problems related to maintaining Certificate Revocation information and ensuring their accessibility.
There is no need for a separate, unencrypted by design (!), and possibly error-prone revocation infrastructure. Just change your DNS records, and the problem is solved.
The new power of DANE
In those traditional X.509 certificates provided by CAs around the world, it is impossible to distinguish between several services assigned to the same name. For example, the web server at
example.com, the mail server for
example.com’s instant messaging server all have the power to impersonate each other. If these services are provided by different companies, CAs require you to trust these companies for all what you can do, not what you want them to do. DANE plays well with this and allows your `private‘ services to have different and better secured keys than your `public‘ services, where you have stronger security requirements.
DANE also supports virtual servers much better than old-fashioned certificates, as the certificate is attached to the server and service it offers, not to its name. This provides much more flexibility and faster reaction time to changes, due to scalability needs or system outages.
Furthermore, it can be used to streamline the workflows of setting up a new server, to be completely under your control.
The new role of certificate authorities
Under the new regime, CAs are not really needed anymore for binding between the server’s name and the server’s key. Instead, owners of domain names just register their DNSSEC keys with their DNS Registrar with which they already have a business relation. Then, the owners simply insert the relevant information about the server keys into their DNS servers. This is good as this removes one step in the chain.
However, binding keys to servers is not the only service CAs offer. They also bind the server name to the owner. This is especially visible for the extended validation (EV) certificates used mostly by financial institutions, which result in the well-known green bar in your browser. Tying the real-world company name to the domain name is an important aspect, as it can help distinguish the fake paypal-international.com from the real paypal.com.
DANE will make the Internet more secure, because it makes setting up encryption to servers and services easier and cheaper. It also puts the control over server and service encryption keys to where they actually belong: Not the server tells who he is, but the system which tells you which server to contact will tell you which encryption and authentication keys you should expect. This is the way it should have been done all along, telling you that
google.com is reachable at
18.104.22.168 with key
12345678 in one step.
The certificate authorities will have to change their business model from association of keys to server names to the proliferation of trust: Is the domain
faceb00k.com really associated with the company you know as Facebook, Inc.? This should have been independent of the actual key exchange in the first place. Trust goes beyond this; CAs will need to achieve this next step as well.
However, user certificates â€“ the ones used to sign and encrypt S/MIME emails and/or to prove your identity to servers as a secure replacement for entering a password â€“ are a different beast. It will take longer for them to be replaced by a DANE-like mechanism.
When it comes to authenticating server names, the tables are being turned now. Soon, all major applications will support and trust DANE. For email servers, we already see stronger support for DANE than for traditional CAs, which never worked well for email server-to-server communications. [1,2]