Using HNS websites securely

TLSA records, SSL Certificates, and the future of browsing the Handshake-enabled web.

Handshake is a proof-of-work blockchain designed to secure a decentralized DNS root zone and certificate authority. Most Handshake users have figured out the DNS stuff already. If you have an HNS resolver set up on your computer you can explore this psychedelic website hosted directly on a TLD registered on the Handshake blockchain: http://willcroteau./

So that’s DNS naming, but what about certificate authority? On the legacy internet, SSL certificates are authorized by trust anchors that come installed on your computer when you buy it. These certificates enable us to communicate securely and privately with the websites we browse to, encrypting all data like passwords and web content. The protocol to embed certificate authority in DNS (or HNS) records is called DANE and already exists, but until major web browsers support it, can we even use HNS websites securely?

Yes, but it’s a little tricky.

There’s nothing stopping HNS name owners from adding TLSA records to their zone and implementing SSL with their webservers, but without a trusted certificate authority, your computer needs a little tough love to give the user confidence that their data is secure.

The owner of the HNS name 3b has set up their zone and webserver with DANE:

$ dig _443._tcp.3b TLSA +dnssec

That TLSA record is a hash of the SSL certificate that the webserver will use to secure the connection to the client.

What we need is a way to verify that the SSL certificate matches the TLSA record (which is authorized by the records committed to the name on the blockchain), then convince Chrome that we, THE USER, trust the certificate without appealing to any centralized authority.

Image for post
Image for post
How can we turn this…
Image for post
Image for post
…into THIS?!

We can use the hdns library in a new script to do the verification, and then export the certificate as a file. We can then install the .crt file in our operating system as a new trusted anchor. The video below shows the process, which works like this:

  1. Get the TLSA record from the nameserver delegated by the HNS record
  2. Get the SSL certificate from the webserver
  3. Verify 1 matches 2
  4. Save the certificate as a file (to the Desktop)
  5. Add the certificate to the system’s keychain
  6. Set the trust level on the certificate
  7. Check out https://3b

This is so lame.

Yes it is! But it works… for now. What can we do to make this more convenient for users? Ultimately, we need a web browser to integrate HNS name resolution with DANE for the smoothest possible operation and shortest transition for average internet users. In the meantime, the process I illustrated above can be simplified by a browser extension, stand-alone application, or even a trusted proxy server.

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store