2024-01-15 11:54:00 -06:00
|
|
|
|
+++
|
|
|
|
|
|
title = "Protecting TLS services from MITM attacks"
|
|
|
|
|
|
description = """\
|
|
|
|
|
|
A public service announcement about how to use CAA records to protect services
|
|
|
|
|
|
you host against MITM attacks. \
|
|
|
|
|
|
"""
|
|
|
|
|
|
date = 2024-01-15
|
|
|
|
|
|
[taxonomies]
|
|
|
|
|
|
tags = [ "selfhosting", "privacy", "security", "networks" ]
|
2025-01-15 13:50:07 -06:00
|
|
|
|
[extra]
|
|
|
|
|
|
show_only_description = true
|
2024-01-15 11:54:00 -06:00
|
|
|
|
+++
|
|
|
|
|
|
|
|
|
|
|
|
A few months ago, a Russian XMPP server had their TLS connections with users
|
|
|
|
|
|
successfully [attacked via a man-in-the-middle][0] (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.
|
|
|
|
|
|
|
|
|
|
|
|
[0]: https://notes.valdikss.org.ru/jabber.ru-mitm/
|
