Новые технологии ломают интернет. Часть 1.

Иногда долго работая в ИТ, начинаешь видеть, как вещи ломаются. Как технологии, которые раньше работали как часы, перестают работать. Наблюдать как новые технологии ломают то, что хорошо работало, вызывает грусть. Потому что, когда тебе нужно забить гвоздь ты берешь молоток. И оказывается, что молоток перестал заколачивать гвозди и теперь к одной задаче заколотить гроздь, возникает другая — найти молоток. Это не прогресс новых технологий, а регресс. В этом посте будет несколько примеров таких технологий. Пост разделен на две части для удобства. Это первая часть.

Спиритуальное продолжение этого поста

1. SPF, DKIM не работают без DMARC.

ОК, здесь все работает, только обязательно связке.

Для защиты от спама используются следующие DNS записи:

  • SPF— указывает какой сервер может отправлять почту с домена. Защищает поле MAIL FROM. Это поле передается в SMTP сессии и не видно почтовому клиенту.
  • DKIM — указывает публичный ключ. Защищает поле FROM. Это поле передается в теле письма и видно почтовому клиенту.

Проблема в том, что SPF и DKIM не работают без DMARC.

Пример.

  1. Злоумышленник регистрирует DNS домен fake-bank.org
  2. Злоумышленник создает в домене записи:
    • A — mail.fake-bank.org IN 1.1.1.1
    • MX — mail.fake-bank.org
    • SPF — v=spf1 mx ip4:1.1.1.1 -all. Публикуется в корне fake-bank.org.
    • DKIM — v=dkim1;p=pubkey. Публикуется в поддомене selector._domainkey.fake-bank.org.
  3. Злоумышленник шлет подделанное письмо жертве притворяясь настоящим банком
  4. Почтовый сервер получает письмо от злоумышленника
    MAIL FROM: fraud@fake-bank.org - RFC5321.MailFrom
    FROM: manager@bank.org - RFC5322.From
    DKIM: d=fake-bank.org
  5. Почтовый сервер проверяет MX запись. Письмо было отправлено с сервера mail.fake-bank.org. Который отвечает за отправку писем в домене.
  6. Почтовый сервер проверяет SPF запись. Письмо было отправлено с домена fake-bank.org. Который разрешает отправку писем севером mail.fake-bank.org
  7. Почтовый сервер проверяет DKIM запись. Заголовки и письмо не менялись. Потому что публичный ключ домена fake-bank.org подтверждает это.
  8. Почтовый сервер пропускает письмо как валидное.
  9. Клиент открывает письмо и видит, что оно отправлено от менеджера его банка.
  10. Происходит подлог. И это проблема безопасности.

Вывод.

  • Без DMARC записи SPF и DKIM не работают. Нужно использовать DMARC совместно с SPF и DKIM. Именно DMARC задает действие при котором SPF или DKIM не проходят проверку.
    DMARC позволяет использовать соответствие (alignment) поля FROM: полю MAIL FROM:.
  • DMARC указывает действие (p=), которое должен совершить получатель письма, если DKIM и SPF не проходят проверку. Если один из них проходит, то письмо валидное.
  • Чтобы прошла DKIM проверка. Домен в DKIM заголовке письма (DomainKey-Signature: a=rsa-sha1;s=selector;d=fake-bank.org) должен соответствовать домену в поле FROM (bank.org).
  • Чтобы прошла SPF проверка. Домен в RFC5321.MailFrom (MAIL FROM) или RFC5321.EHLO/HELO поле SMTP должен соответствовать домену в поле FROM (bank.org).
  • Если ни одна из проверок не проходит, то письмо невалидное. Клиент применяет политику, указанную в записи DMARC.
  • В рассматриваемом примере проверка DKIM не пройдет.

DMARCv=dmarc1;p=none. Публикуется в поддомене _dmarc.bank.org. Защищает получаетеля сфабрикованного письма от домена bank.org от злоумышленника.

Проверка записи DMARC

nslookup -type=TXT _dmarc.bank.org

Проверка записи SPF

nslookup -type=TXT bank.org

Проверка записи DKIM

nslookup -type=TXT selector._domainkey.bank.org

Источник 1
Источник 2
Источник 3
Источник 4
Источник 5
Источник 6
Источник 7
Источник 8
Источник 9
Источник 10

2. HTTP2 connection reuse и reverse proxy

HTTP2 использует TLS1.2 и выше для шифрования и аутентификации. Клиент по TLS указывает в поле SNI к какому серверу идет подключение. Таким образом адрес сайта передается два раза: в TLS Client Hello поле SNI и в HTTP заголовоке Host.

Небольшое отклонение: в новом HTTP они перевели HTTP/1.1 Host заголовок в HTTP/2 :authority заголовок. И с их использованием возникают проблемы. 😐
Использование заголовка :authority в HTTP2 для той роли, что играл заголовок Host в HTTP1.1 имеет объяснение. Название идет из RFC 3986, в котором authority имеет следующий вид
authority = [ userinfo "@" ] host [ ":" port ]
Однако часть userinfo обозначается устаревшей и запрещается к использованию в HTTP2. Т.е. в authority будет включен имя хоста и порт опционально.

А еще в HTTP3 версии (т.е. в следующей после HTTP2) они убрали поддержку передачи открытым тексктом (в HTTP2 была такая возможность) и перевели на транспортный протокол UDP.

HTTP2 использует постоянное подключение. При подключении к одному северу на один порт клиент предпочтительно будет использовать установленное подключение.
Из-за этого может произойти объединение (HTTP2 coalescing). Два сервера за обратным прокси начинают выглядеть для клиента как один. Т.е. в HTTP2 когда адрес резолвится в IP адрес и совпадает с предыдущим IP и сертификат совпадает с предыдущим сертификатом, то используется текущее соединение. В HTTP1.1 каждый запрос создавал новое подключение. И это проблема безопасности.

Пример

  • Обратный прокси (HAProxy)
  • Два HTTPS веб сайта опубликованы на нем: site1.example.org и site2.example.org
  • Прокси использует использует SNI из запроса для направления на веб сервер (SNI proxy)
    • site1 располагается на веб сервере .1
    • site2 располагается на веб сервере .2
  • Оба веб сайта используют один wildcard *.example.org сертификат
  1. Клиент веб браузер подключается к первому сайту site1.example.org
  2. Клиент получает адрес обратного прокси
  3. Клиент запускает этап согласования TLS
  4. Прокси получает TLS Client Hello
  5. В SNI запроса указан сайт подключения — site1.example.org
  6. Прокси пропускает запрос на веб сервер .1
  7. Клиент получает сертификат сайта *.example.org
  8. Клиент успешно подключается
  9. Клиент запрашивает подключение ко второму сайту site2.example.org
  10. Веб браузер видит, что IP адрес и сертификат те же самые
  11. Клиент использует HTTP2 установленное соединение
  12. Клиент пропускает этап согласования TLS
  13. Прокси не получает TLS Client Hello
  14. Прокси использует существующее подключение
  15. Прокси пропускает запрос на веб сервер .1 вместо .2
  16. Веб сервер .1 получает данные, предназначенные для веб сервера .2. И это проблема.
  17. Клиент получает ошибку 404

Для данной ситуации был создан специальный код HTTP 421. Веб сервер может его отправить, если определит, что клиент запрашивает не тот сервер. Но это не всегда работает.

Misdirected Request
The client needs a new connection for this request
as the requested host name does not match the Server Name Indication (SNI)
in use for this connection.

Вывод.

Отключить HTTP2 на стороне сервера. Если это возможно. Например HTTP2 также не поддерживает аутентификацию Windows authentication (NTLM/Kerberos/Negotiate) там сломаны картинки

Чтобы в IIS отключить HTTP2:

  1. Пуск → regedit
  2. Открыть путь: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
  3. В папке Parameters, правой кнопкой мыши создать 2 новых DWORD (32-bit) значения:
  4. EnableHttp2Tls
    EnableHttp2Cleartext

  5. Проверить что оба зачения установлены в 0(отключено) изменив нажав правую кномку мыши и выбрав «Изменить…»
  6. Перезагрузить систему

Другой вариант. Использовать разные сертификаты. Или использовать разные IP адреса.

Начиная с 1 сентярбя 2020 браузеры перестанут принимать сертификаты дольше чем на 398 дней.

Источник 1
Источник 2
Источник 3
Источник 4
Источник 5
Источник 6
Источник 7
Источник 8
Источник 9
Источник 10
Источник 11
Источник 12
Источник 13
Источник 14
Источник 15
Источник 16
Источник 17
Источник 18
Источник 19
Источник 20
Источник 21

Вторая часть.

One response to “Новые технологии ломают интернет. Часть 1.

  1. ссылка на вторую часть в конце не робит

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s