Где расшифровывается TLS и у кого лежит ключ

Любая проверка на прикладном уровне — правило WAF, разбор логики запроса, сканирование файла — требует незашифрованного содержимого.

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

Правильный вопрос начинается дальше: что хранится в точке расшифровки, у кого ключ и как расшифрованный трафик передаётся потом?

Первый — TLS расшифровывается на границе у провайдера. Это самый простой и распространённый путь: сертификат у провайдера, трафик расшифровывается, проверяется и передаётся на origin.

Второй — TLS расшифровывается на устройстве или в приложении внутри вашей сети. Провайдер только передаёт пакеты. Контроль сохраняется, но защита работает только там, где вы её поставили.

Третий — смешанный: расшифровка на границе, но ключ остаётся под вашим контролем. Это сложнее всего, и для многих регулируемых отраслей это единственный приемлемый вариант.

Чаще всего забывают именно про отрезок между границей и origin. Пользователь приходит на границу по TLS, но если граница ходит на origin обычным HTTP, там трафик идёт открытым.

Обычно это опирается на допущение «внутренняя сеть, значит безопасно». На практике этот путь нередко проходит через интернет и открыт.

Правильная настройка — второе TLS-соединение и, по возможности, взаимная аутентификация. Тогда origin принимает трафик только от границы, и напрямую к нему никто подключиться не может.

Самый простой случай — сертификат и закрытый ключ хранятся у провайдера. Это работает, но вы отдали ключ другой организации.

Второй вариант — ключ лежит в аппаратном модуле (HSM), а провайдер только запрашивает операцию подписи. Сам ключ наружу не выходит.

Третий вариант — принести свой ключ. По названию это даёт контроль, но на практике ключ всё равно оказывается в среде провайдера. Выбирать, не понимая разницы, нельзя.

Истёкший сертификат — самая частая и самая легко предотвратимая причина простоя. Случается это всегда в праздники или в ночь на выходные.

Решение — автоматическое обновление, но и оно требует контроля: оповещение о неудачном обновлении должно приходить минимум за несколько недель до истечения.

И обновление должно проходить во всех точках. Сертификат, обновлённый на границе, но оставшийся старым на origin, ломает взаимную аутентификацию — снаружи это не видно.

TLS 1.0 и 1.1 больше нигде не нужны, их следует выключить. Обычно это лёгкое решение: клиентов, которые ими пользуются, почти не осталось.

Сложнее вопрос набора шифров в TLS 1.2. Там всё ещё остаются слабые варианты, и оставлены они чаще всего «ради старых клиентов».

Практический приём — посмотреть статистику: сколько соединений за последний месяц пришло по каждому протоколу и шифру. Обычно выясняется, что «старые клиенты» — это сканеры и боты.

Допущение, что сертификат для вашего домена можете получить только вы, неверно. Его получит и тот, кто перехватил управление DNS-записью или занял брошенный поддомен.

Поэтому за журналами прозрачности сертификатов наблюдают: каждый новый сертификат для вашего домена виден. Неожиданный сертификат — событие для немедленной проверки.

Вторая мера — запись CAA: в ней перечисляются удостоверяющие центры, которым разрешено выпускать сертификаты для вашего домена. Это одна строка, закрывающая множество путей.

Четыре вопроса поставщику. Где расшифровывается трафик? Где хранится закрытый ключ и кто может его увидеть? Зашифрован ли участок от границы до origin и есть ли там взаимная аутентификация?

Четвёртый — про журналы: какая часть расшифрованного трафика сохраняется? Если тело запроса сохраняется целиком, вы перенесли клиентские данные в другое место, и знать об этом нужно.

И последний вопрос себе: можно ли подключиться к origin напрямую, минуя границу? Если да, всё перечисленное выше не имеет значения — атакующий просто обойдёт её.