Announcing AS 208323!

We are excited to literally announce our own Autonomous System :)

One week ago we started announcing AS 208323. On the same day we migrated our main Tor server to it. Here are some of the factors that motivated us to apply for our own ASN:

  • Bandwidth: Having your own Autonomous System Number is one of the technical requirements to join Community-IX. Community-IX provides non-profit organizations that meet their requirements with free IP transit capacity.

  • Routing Security: Running our own BGP routers allows us to define our own policies and RPKI based Route Origin Validation has been part of our AS from the very first second it went online.

  • Redundancy: Until we moved into our own ASN we had only a single fiber connecting us to the world which basically never was a real issue but now we got two which allows us to keep running even when our upstream needs to do maintainance.

  • Abuse Management. Due to our limited Tor exit policy we never had much abuse emails but running our own AS gives us the freedom to choose a more open Tor exit policy in the future should we want to.

  • Anycast. Having our own ASN will come handy should we ever run our DNS privacy resolvers in multiple Anycast locations, which is not something we can do currently due to the additional required IP prefixes but having that option in the future is nice.

From a technical point of view we run BIRD 2 and Routinator 3000, but we are not entirely happy with the setup since BIRD on BSD apparently has some limitations (no support for privilege dropping, worse syncing with kernel table, no ECMP) so we might change OS or BGP daemon in the future.

Our ASN shows up on the Tor network top 10 ASNs already:

Screenshot of Relay Search, showing that we are currently at position 7 in the ASN overview.

In the next few weeks we will deploy a RIPE Atlas probe and we are planning to join the MANRS initiative.

Thank you to everyone who made this possible!

Encrypt all the things, DNS included!

tldr; Today we are launching our new DNS Privacy Services supporting the DNS-over-TLS and DNS-over-HTTPS protocols.

DNS traffic is revealing

DNS is an old protocol that has been around for over 30 years. The scalability of DNS still serve us well even on today's internet size but the protocol is lacking confidentiality properties. With successful efforts like Let's Encrypt that significantly increased the share of encrypted HTTP traffic the cleartext nature of DNS is becoming more of an issue that needs to be solved since it is one of the few remaining ways how observers can learn the sites visited by an internet user. DNS traffic can reveal a lot about a user, it basically discloses the entire browser history at a domain level.

There have been multiple efforts to protect DNS traffic and in the last few years these efforts also included protocols that got specified in RFCs.

DNS-over-TLS

In 2016 DNS-over-TLS also known as DoT got published but its adoption remained relatively low and some implementations still have some significant deficiencies like establishing a new TLS connection for every single DNS query instead of reusing a connection for multiple queries to reduce the connection setup overhead. Luckily this is slowly changing, as an example Android 9 ships with DoT enabled by default. Even the default opportunistic mode that does not authenticate the TLS connection to the resolver is still positive progress. We hope to see DoT software evolve in particular with regards to connection handling and TLS authentication.

DNS-over-HTTPS

The second protocol, DNS-over-HTTPS also known as DoH, published in October 2018, has seen fast adoption particularly from browser vendors. Mozilla Firefox experimented with DoH already before the RFC got finalized. At this point users can opt-in to use DoH but Mozilla expressed intentions to enable DoH by default eventually. Google Chrome will also ship DoH support but does not have a user interface to enable and configure it yet.

From a pure protocol perspective we prefer DoT over DoH because it contains less unnecessary metadata (no HTTP and all the potential issues that come with it). We do support both protocols because we want to bring encrypted DNS to the users and at this point it is a lot easier to enable DoH in a browser than to install and configure additional software that talks DoT with the resolver.

And there is a small but important implementation-specific dependency: Firefox unfortunately requires using DoH for DNS to make use of encrypted SNI. You can not use ESNI while using a system wide DoT resolver because Firefox needs to retrieve the keys for ESNI via DNS and it only supports DoH for that (no DoT). ESNI (an active Internet-Draft) will close another loophole disclosing the visited sites at the TLS layer. The dependency to use DoH for DNS is not a requirement by ESNI but a shortcoming of Firefox and we are not sure whether this will change anytime (soon).

Some of the concerns voiced around DoH are not directly about the protocol itself but rather about the way how applications (mainly browsers) might select the DNS resolver since Mozilla partnered with Cloudflare to provide the DoH server capacity. Some other big players might simply fear loosing access to lots of DNS data that they got for free until now.

We share concerns about centralization but that should not be used as an argument against the protocol. It is important that DoH client sofware offers users an option to select their preferred DoH server and that more resolver operators offer DoH and DoT support, which brings us to the next point.

With browsers implementing DoH, the client portion is well covered, but for resolver operators the DoH software options are currently still looking dire. At the time of writing no major resolver software ships a released version with DoH support yet which makes it harder to offer and operate DoH servers but we like to hope that this will change within the next few months.

The actual goal behind all of this

Users should be able to browse the web privately without an observer learning all the sites they visit. Even with encrypted DNS this goal is not met yet. Observer can still learn visited domain names after a user enabled DoH or DoT due to information disclosed in TLS (SNI) but encrypted DNS is nonetheless a requirement towards protecting that information until the specification for encrypted SNI is completed and implementations are made available.

Our DNS Privacy Services

We operate public DNS Privacy resolvers in the following flavors:

  • two DoT endpoints
  • an experimental DoH endpoint
  • an experimental DNS-over-Onion endpoint

(we do not offer plain DNS over UDP endpoints)

More details can be found on our service page.

If you'd like to know what we log and for how long you should have a look at our privacy policy.

A few months ago when we decided to offer DNS privacy services for the general public as our next privacy enhancing service we didn't anticipate the attention this topic is getting these days. We are glad DNS privacy is gaining traction.

If you would like to learn more about these DNS privacy protocols come to our talk "DoH, DoT, what? - An Introduction to DNS Privacy Protocols." at easterhegg 2019 in Vienna (19.04.2019).

Our First Donation Stats

logo

Since we are collecting donations to help cover our costs for the privacy infrastructure we operate for you - the general public, we want to give you some insides on how much we collected and how much we spent. We would also like to encourage other similar organizations to publish comparable numbers.

So far we collected a total of 776 Euro since we launched until the end of November 2018. This includes donations and membership fees (excluding "internal" donations from the core team itself).

On the spending side we had a total of 2451 Euro of expenses.

This money was primarily used for our infrastructure providing privacy enhancing services to the general public free of charge.

With that money we routed a total of over 5800 TiB of Tor traffic (rx+tx).

So statistically speaking we pushed more than 2.3 TiB of privacy enhancing traffic for every Euro spent. This should give you an idea on how efficiently your donation is transformed into privacy enhancing services like Tor bandwidth and since our monthly throughput is still growing our cost efficiency is also expected to get even better next year.

Until the end of next year we are aiming to collect a total of 3000 Euros via donations and membership fees to help cover some of our costs.

Thanks for supporting the operation of privacy enhancing technology services!

Die Foundation for Applied Privacy sagt Hallo!

logo

Nachdem wir diesen Tag schon länger vorbereitet haben, wollen wir heute unseren Verein, die "Foundation for Applied Privacy" vorstellen. Der Verein setzt sich für

  • den praktischen Einsatz,
  • die Verbreitung und
  • für die Verbesserung und Erforschung

von "Privacy Enhancing Technologies" ein.

Dies umfasst:

  • Betrieb kostenlos nutzbarer technischer Infrastruktur zum Schutz der Privatsphäre im Internet für die Öffentlichkeit.
  • Förderung von freier Software und Forschung die dem Schutz der Privatsphäre und der sicheren Kommunikation dient.

Gleichzeitig mit dem Verein starten wir auch unseren ersten Tor-Exit-Knoten

Wir werden unseren Verein auch auf der PrivacyWeek im Oktober 2018 in Wien vorstellen.

Um immer auf dem letzten Stand zu bleiben, folgt uns einfach auf Twitter oder Mastodon.

Gerne könnt ihr uns auch unterstützen!