Openalias Resolver Security Measures

Have you used openalias-resolver.org yet? If not, first read about OpenAlias here and here. Openalias-resolver.org is my web app for translating OpenAlias addresses, and also helping you to make your own one. It's useful because of many features...

Openalias-resolver.org has been designed for excellent privacy and safety. In this post, I will go over these privacy- and safety-enhancing measures.

What happens behind the scenes

  1. The user enters the OpenAlias address and chooses the right cryptocurrency on the webpage.
  2. The web browser first tries DNS over TLS. Then, if needed, it tries DNS over HTTPS (at step 5-6)
  3. The DNS over TLS query is sent as Websocket JSON data over TCP port 443 to a randomly chosen proxy server from a list.
  4. The proxy server changes the websocket request to DNS over TLS and sends it to one of two DNS servers, either Quad9 or Cloudflare.
  5. If that fails, the web browser makes a direct connection to Quad9 with DNS over HTTPS (TCP port 443).
  6. If that fails, the web browser makes a direct connection to Cloudflare with DNS over HTTPS (TCP port 443).
  7. The DNS server checks whether the domain in the OpenAlias record has DNSSEC.
  8. If no DNSSEC, the user is warned.
  9. The user can enter in a custom DNS server for all these steps.
  10. The user can enter in a custom DNS server and bypass the proxy server in steps 2-4.
  11. The user-chosen DNS server can only be accessed via a password; this password is saved on the local device in encrypted form.
  12. There is no unencrypted data transfer.

Why both DNS over TLS and DNS over HTTPS?

During testing, browsers with the strictest privacy settings rejected DNS over HTTPS (DoH). I didn't have time to work out why. Also, Quad9 didn't work with DoH. The team there said that it would probably work in the future, but I couldn't take that risk.

Using both DoT and DoH gives more options if using a custom DNS server. You can either go straight to the DNS server using HTTPS, or go via a proxy server using TLS. Since you have chosen your own custom DNS server, it makes more sense to use DoH and cut out the middleman. However, then you might need to tweak your browser settings. You might also need to tweak your anti-virus.

Why does DNS over TLS need a proxy server?

For a very good reason: Your webbrowser will view an ad hoc query to some DNS server not in your settings as a security risk.

The DNS over TLS proxy server trust issues

The proxy server in the middle does need extra trust. It can see your DNS traffic. Nobody else can, because of the TLS encryption. Trust issues are mitigated in the following ways:

The choice of DNS servers

I chose Quad9 and Cloudflare for their adherence to privacy. Quad9 is tried first, then Cloudflare. If you don't like them, you can set your own DNS server.

Client-side Javascript

A number of javascript programs must execute in the webbrowser for OpenAlias-Resolver to work.

Here are their basic roles:

clipboard-utils.js

This makes the copy button work.

crc-32.js

This does the crc-32 checksum in the openalias record; used if you make an OpenAlias TXT record with openalias-record-maker.js

custom-dns.js

This allows you to enter in a custom DNS server, store it on your device, and protect it with a password.

install-handler.js

This allows the user to install the webpage as a P.W.A. (Progressive Web App); more or less, loading the webpage locally on your device.

md5.js

This calculates an MD5 checksum. It is used along with openalias-resolver.js to lessen greatly the chance of a man-in-the-middle attack. Read the section below: here

openalias-record-maker.js

This outputs a format-correct DNS TXT record to be used for OpenAlias records.

openalias-resolver.js

This resolves OpenAlias queries based on user input. It is the main logic of the web app.

proxy-randomizer.js

This makes a pseudo-random algorithm for choosing one proxy server from an array. See here.

qrcode-svg.js

This formats a QR code generated from the resolved cryptocurrency-address.

qrcode.js

This is a typical program for making a QR code out of data.

Client-side Javascript Script Source Integrity

When your webbrowser asks for a Javascript program, there is an integrity check. This is done with SHA-256 hashes. It's part of the HTML specification. It looks like this:

<script src="js/crc-32.js" integrity="sha256-2Co7ANPgBRojh0m1up8jOmB9OHuRG29ugkaded+lKeU=" crossorigin="anonymous"></script>

This means that, when the Javascript program is downloaded, all its code is checked to see if it matches that 'integrity=sha256-etc.' string. If it doesn't, the webbrowser won't run it. If someone has changed the code even one character, it won't work.

This isn't so useful by itself. All my code comes from the same website, so it's likely that a malevolent hack of the website would change the code and the 'integrity' hashes. The usefulness comes in combination with a record of those hashes.

Here's what you do.

  1. For the relevant webpage, in your webbrowser, type in 'view-source:' before the webpage address.
    • e.g. view-source:https://www.openalias-resolver.org/
  2. Find all the instances of <script src=>
  3. Compare them at this website archived on the Wayback Machine.
  4. You can also verify all the hashes by using my public key on the same website.

How does MD5 help?

An MD5 hash is built into the OpenAlias queries.

I mean that the OpenAlias address which you're querying and the DNS server's URL are joined together and that is hashed. For example: 'donate@getmonero.org' and 'dns.quad9.net'.

You can check this for yourself. It is almost impossible for the website to use a fake DNS server or fake OpenAlias address. Digging into the browser's console can show you the server contacted. With that, it would takes months of calculations to have any chance of coming up with a fake MD5 hash.

Back to the index of blog posts

Tags