Skip to content

Using HTTPS records for onion services

As of this writing, HTTPS records are still a draft standard. However, experimental support for them has already been implemented in numerous browsers, including Firefox, and I think it is worth noting their value for Tor Browser and onion services.

Exit nodes are difficult to operate, and anything that conserves their bandwidth is important. The primary way to do this is to have website operators run onion services alongside their clearnet addresses. The Onion-Location header accomplishes this by (loosely speaking) redirecting the user to an onion address.

This leaves several issues:

  • The user has to contact the original server over an exit node, which does little to help latency. This does not apply to links pointing at the onion service itself, but those create the problem below.
  • The user ends up at an unfamiliar onion address, and if they grow accustomed to that they become vulnerable to trivial phishing attacks by anyone who can set up an onion service with a similar-looking address. TLS certificates cannot help with this.
  • Tor Browser does not support cleartext HTTP/2, and it remains difficult to automate TLS certificates for an onion address. As such, this tends to force the user into HTTP/1.1, which is noticeably less performant in many cases.

What ultimately matters to the user is that they type in an address and get an authoritative response for it. In this respect, Opportunistic Onions are a superior approach: the user still has to make initial contact over an exit node, but they get responses that are provably authoritative for the original address. On top of that, they can still use HTTP/2.

HTTPS records solve the final outstanding issue of Opportunistic Onions: the initial connection. A website that offers an onion service capable of issuing authoritative responses for a host can easily instruct browsers to take advantage, without even requiring non-standard tags. And thanks to DNSSEC1, this is still resistant to tampering.

The following set of records, based on draft-ietf-dnsop-svcb-https-10, demonstrate how to use this.

saklad5.com. 86400  IN HTTPS 1 xuahkwjssci42ywuenj5zvn5jdm4o5zcgrqqhbs25sd75dhmz6yyvmqd.onion alpn="h2"
saklad5.com. 86400  IN HTTPS 2 . alpn="h3,h2"

It’s probable this will work without Tor-specific changes once the standard is finalized and Firefox starts using it by default. If so, all that’s needed is awareness on the part of website operators. In the future, users may be able to download Tor Browser, enter <nytimes.com>, and never even hit an exit node2.

Onion-Location isn’t entirely obsolete in light of this: if an onion service for a clearnet server is hosted separately, it may not have access to an appropriate TLS certificate. This seems uncommon in practice, though, and due to that last layer of encryption you could still reverse-proxy the traffic to a clearnet server that does have a certificate without leaking more than the ClientHello (not even that, once ECH is finalized and implemented).

This was reposted from a Discourse topic at the request of a moderator.

  1. If DNSSEC isn’t required, this is only slightly less secure: an attacker could insert a malicious onion service, yes, but they could also insert a malicious IP address in the first place. The onion service’s provenance is verified by having a TLS certificate for the clearnet address, not by being in the DNS record. ↩

  2. Depending on what the DNS resolver is, of course. ↩

Edited by Jeremy Saklad