31 lines
1.4 KiB
Markdown
31 lines
1.4 KiB
Markdown
|
+++
|
|||
|
|
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" ]
|
|||
|
|
+++
|
|||
|
|
|
|||
|
|
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/
|