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...;; ANSWER SECTION:_443._tcp.3b. 217 IN TLSA 3 1 1 139C3B9BA2797224C7BC9AD78E57730419EB84095D8FFAD7E23800A9 F3731323 _443._tcp.3b. 217 IN RRSIG TLSA 8 3 3600 20200616113421 20200608083421 64038 3b. cRH3KtOVz9+6ui5qT3dY7SvtdtK1MOhLu2vbVaJDT3W/W8RuZJCs6lBD MAcTqNWyQdRPaaU54ZcuRfXhUuWdlFyzLIR3a8jNYFhV5yBWAqhBuSBr W2q2NaRpTuB97KsObHbE7k7xXmm2dLSL7eijxjkeLzgnbO5FxnAfeUN7 4nw0TCBQasbDR+SlpbT2y9gp0p6ti/cIUYStNPuLGo41a6yMBYmaimH9 jX9nPU+td9mGoOIfXzVtHBZJK1cjhkyPgqy/sVU9VG2y/GIU8U+JlovN B8gYoXQ+DGtoYCdX4Lxy9tQMw6YwvC9/yjHCs5lsFsVwFmmKDf+QxVcA BRmnJQ== ;; SIG0 PSEUDOSECTION: . 0 ANY SIG 0 253 0 0 20200609001844 20200608121844 40474 . G9+ZlLp+dYh3JzavvuuWWnDkG2adXazwpPIcODt2eRQMYPS37Vus6lDU vyTJqnjQ2jAK++hixpnEgKhAVpgi9w==
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.
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:
- Get the TLSA record from the nameserver delegated by the HNS record
- Get the SSL certificate from the webserver
- Verify 1 matches 2
- Save the certificate as a file (to the Desktop)
- Add the certificate to the system’s keychain
- Set the trust level on the certificate
- 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.
