Protecting TLS services from MITM attacks

A few months ago, a Russian XMPP server had their TLS connections with users successfully attacked via a man-in-the-middle (in particular, their ISP and government appeared to have coluded to attack their routing and issue new certificates to a server in the middle). These kinds of attacks can be prevented even if your ISP or government are misbehaving by leveraging DNSSEC and CAA records (as well as vigilantly monitoring certificate transparency logs for your domain).

If you have a domain you host TLS services on, you should setup restrictive CAA records (if you use Let’s Encrypt, that means tied to an accountid and/or dns01 validation method), and you should setup DNSSEC. Without these, anyone who controls the routing of your IP address (your ISP, hosting provider, misbehaving BGP operators, etc.) can be compelled to obtain a certificate for your domain.

There are also upcoming technologies like DANE (TLSA records) that allow pinning of expected public keys for a domain in DNS, so that browsers can cross-check the expected certificates with what they received in the chain from the server.