SSL Without Built In Browser Certificates

October 21 2010 / Updated March 26 2011

Verifying websites using signed SSL certificates has always been something I have considered as weird, the goal of encryption is just to encrypt, the goal of verifying the identity of a website is something else. It is not the case for most browsers, when you visit a website that uses a self signed certificate to encrypt the data, your browser tells you "Oh no! They did not get their certificate signed in exchange for money: trust at your own risk".

In any case, I do not see how a site can be more secure when you get a signed certificate from a company who only verified your bank account, as a matter of fact, if you visit a phishing site (a compromised website with an extra new page that resembles often a banking site), they could as well have a valid SSL certificate and you wouldn't see the difference unless you actually look at the URL. Example, example.com gets a certificate for https://example.com, now you can see the little lock in your navigator saying "this site is secure", their website gets compromised and a new hidden page like https://example.com/phishing/bank.html is added, you still have the little lock that says "hey, this site is still secure !".

Just an Idea

So now that we can agree that third party SSL verification is useless what can we do ? First, always check the URL. Second, I have a new idea, what if I generate my own SSL certificate and ask YOU to verify it ? Here is how:

Considering your navigator is Mozilla based

Visit https://manurevah.com/
It will say "Secure Connection Failed"
Click "Or you can add an exception… then "Add Exception"
Then "Get certificate" and "View"
Check the SHA1 fingerprint
Interesting part, check the TXT DNS records for the domain you have in the URL bar, in this case: manurevah.com, using dig (ignore the SPF record): dig manurevah.com TXT to be really sure: dig manurevah.com TXT +trace

If the SHA1 fingerprint and the DNS record match you can be sure that whoever administers the zone and the website agree on what SSL certificate should be used to encrypt the data connection.

what we know from this

domain.tld resolves to IP
this site uses encryption
the encryption is verified by DNS

This is not total verification but most of the time this is enough (forums, newspapers, media, anywhere that I do not share critical data). It doesn't cost anyone extra money and doesn't involve any third party where there is no need for it. If you still suspect a Man in the Middle you could still: check DNS records from a different location (call a friend etc.. .).

This is actually the same level of verification (or higher ?) as required to purchase a basic valid ssl certificate, by valid I mean one that your browser already trusts, see https://www.trustico.com/validation/how-fast-is-my-ssl-certificate-issued.php These certificates verify that the certificate holder is the owner of that domain and they do that by sending an email to something generic like admin@domain.tld. When choosing to purchase a domain validated SSL Certificate an Approver will be chosen during the ordering process. We will send an Approver E-Mail to the designated Approver. For the basic certificates we have the same level of identity verification.

It would now be practical if this verification could simply be integrated in our navigators.

Actual verification

If the application/ressource you are accessing requires actual verification (email, banking, etc) then you should verify the fingerprint by contacting the site's owner. In other words, if you actually require verification than you might want to actually verify the identity yourself.

For example lets say you do online banking, your bank should provide you their fingerprint on paper (it should be on all their papers). Your browser should then allow you to verify the identity and mark the pair, website and certificate, as "verified".

If they maintain many websites they could/should also have their own certificate authority for which they provide the fingerprint as well, on paper and/or DNS.

An example of the CA being in the DNS (this should be used as a double/triple checking mechanisms) one could simply have another TXT entry for say: ca.domain.tld, in my case:

dig ca.manurevah.com TXT

This should show the fingerprint of my root CA (DO NOT INSTALL unless you actually trust me)

In the end the user should verify the identity of website's certificate and/or root certificates they trust, everyone can be as careless or paranoid as they want depending on the data they are communicating and their own security requirements/policies. In any case it logicaly seems careless to have everyone blindly trust all certificates signed by all the root certificates installed by default in most browsers. People can and should decide themselves wheter they want to simply trust a website or one or more root CAs.

The case of the CNAME

Let's say a single IP hosts multiple domains, they may have to share a certificate. Some of the sites may even use a CNAME instead of an A record to point to the web space, not a problem DNS queries should follow and we should use the TXT field of the destination of the link. That will give the SHA1 of the mutualised space. For example:

dig www.loozah.com TXT

This should return the TXT entry of loozah.com:

;; ANSWER SECTION:
www.loozah.com.         3600    IN      CNAME   web.manurevah.com.
web.manurevah.com.      10800   IN      TXT     "SHA1 Fingerprint=5E:3C:F1:BB:BF:56:67:F3:AA:42:80:C9:6D:F0:0B:30:71:03:26:8C"

So please, mister and misses developers of most people's web navigators, stop wiping out encrypted websites from the face of the internet just because. Thank you.

Inspiration

Update

Since there have been a few RFC drafts, my favorite is Using Secure DNS to Associate Certificates with Domain Names For TLS - draft-ietf-dane-protocol-06.. This seems to be close to the above idea but definitely more precise and extends to any service by default (in short, WAY better).