33 lines
No EOL
1.5 KiB
Markdown
33 lines
No EOL
1.5 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" ]
|
||
[extra]
|
||
show_only_description = true
|
||
+++
|
||
|
||
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/ |