Optimised Routing and Opportunistic Tor Enabled
In the past few days, I've enabled some new functionality on my delivery network, affecting (almost) every domain being served by it.
Those using a browser which supports these changes should see improved delivery performance, and enhanced privacy.
This post details the changes that have been made, and what they mean to you
The Issue
Over the past few years, we've seen an increasing focus on improving privacy on the internet, particularly in terms of what information is made available to those on the wire. This is, in general, a positive thing.
However, one casualty of this has been the geolocation systems commonly used by global delivery networks (such as CDNs). These systems operate at the DNS level and are used to identify the Point of Presence (PoP) - group of servers - closest to you, and direct you there so that you get the lowest possible latency when requesting content.
In order to do this accurately, the query they receive needs to contain EDNS Client Subnet (ECS) information - essentially a close approximation of your IP address (it's masked a little, so 192.168.1.50 becomes 192.168.1.0/24). This information (when present) is added by the DNS server that you use.
Without that information, the networks must instead route based upon the IP address of the DNS server contacting their routing system on your behalf. This can mean that the calculated location isn't at all representative of your real location, resulting in you being routed to a (far) less than optimal PoP.
For a while, ECS was increasingly becoming available in queries. However privacy concerns were raised because the query from your DNS server to the routing systems contains your subnet in plaintext, so a well placed observer could essentially sit and identify (roughly) which subnets were visiting which sites.
Various providers, such as Quad9 and Cloudflare decided not to include ECS information in their queries (OpenDNS also doesn't by default, unless you register your nameserver details with them). However, because of the size of these providers, queries sent on your behalf can, at times, originate from a completely different country. Or, in some cases, will always geolocate back to the USA.
The impact on routing is massive, there could be a PoP next door to you, but you won't get routed there because routing cannot know your actual location. It's notable that Cloudflare is least impacted by it's decision because they use Anycast routing for their CDN.
This isn't something that wasn't known about, and was a deliberate choice, prioritising privacy over performance.
My delivery network was as affected by this as any other, although as RequestRouter is fairly flexible I have been able to mitigate it to some small extent.
New Feature
The aim of the new functionality on my network is to help address the issue above.
Now, when you access a site that I deliver, you'll go through routing as normal. However, when you then connect to the server you've been routed to, it'll place a HTTPS request against a component of my routing system to check routing for your subnet (your IP is, as with ECS, masked).
If routing responds that you could have been routed a more optimal location, the server will inject a RFC 7838 Alt-Svc header into it's response to you - containing details of the server(s) it recommends you use instead.
If you're using a browser than supports the functionality (such as Firefox), your browser will then run some checks against the suggested server(s). If it decides any of those perform better than the one you're currently connected to, it will silently start using that server instead.
So, for example, if as a German, you're using Cloudflare's DNS and my routing system decides you're in the US, you'll connect out to a North American server, which will answer your request but also direct you to a European server:
Alt-Svc: h2="206.189.120.26:443"; ma=900
All of this can quite happily happen within the space of one webpage load.
The changes to RequestRouter needed to support this were released as part of V0.4, and I've also published a reference implementation for adjusting an edge to make calls to it (though the version on my edge is more heavily optimised to my use case).
Improved Privacy
I was already making changes to my infrastructure in order to make this change, so I decided to make an additional related change at the same time.
The Alt-Svc header also contains the address for a Tor Hidden service:
Alt-Svc: h2="206.189.120.26:443", h2="liyyqnujwdudahxg.onion:443"; ma=900
(This will change to a V3 address later)
So, if you're using tor, then your browser will opportunistically switch to the hidden service. It'll stop using exit bandwidth and instead hit whatever site you're viewing via the Hidden Service instead. Again, this is all transparent, so you'll not see a change of address in the address bar.
This means that you'll no longer be transiting a potentially untrusted exit node, and will free up a little bit of Tor's valuable exit bandwidth in the process.
Conclusion
So, if you're accessing content delivered by my network (or using me to deliver content for you), you should see an uptick in performance - although currently it'll be limited to Firefox users. Once Chrome's support is properly in place though, a much wider performance gain should be seen.
Tor users can also rest easy knowing they'll benefit not from having not just HTTPS, but Tor's encryption protecting their connections in flight, without site operators having to manually create a hidden service for each site (and then publish the addresses somewhere etc).
