«Замочку» в адресной строке теперь можно доверять больше. Chrome вводит строгие правила против хакеров

Индустрия HTTPS-сертификатов начинает поэтапно отказываться от менее надежных способов подтверждения прав на домен: Chrome Root Program и CA/Browser Forum утвердили новые требования к центрам сертификации, которые постепенно выведут из употребления 11 «наследных» методов Domain Control Validation (DCV).

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

Решения закреплены бюллетенями SC-080, SC-090 и SC-091 и будут внедряться постепенно, чтобы владельцы сайтов успели перейти на современные схемы. Полный эффект от ужесточения должен быть достигнут к марту 2028 года, когда устаревшие проверки окончательно уйдут в прошлое. Авторы изменений связывают их с публичной дорожной картой Moving Forward, Together, запущенной в 2022 году: тогда это было скорее направлением развития, а обновления TLS Baseline Requirements превращают курс на «автоматизацию и модернизацию инфраструктуры» в обязательную для отрасли политику, продолжая волну инициатив по повышению безопасности, которые ранее удалось продвинуть до статуса общих стандартов.

DCV — это критически важная процедура, которая должна гарантировать, что сертификат выдается только реальному оператору домена, а не постороннему. Без такого контроля злоумышленник мог бы получить вполне «валидный» сертификат для чужого сайта и использовать его для подмены ресурса или перехвата трафика, оставаясь формально в рамках доверенной цепочки. В современных моделях проверка обычно строится как challenge-response: центр сертификации выдает случайное значение, а заявитель подтверждает контроль, размещая его, например, в DNS TXT-записи или в другом заранее оговоренном месте, после чего центр проверяет результат.

Исторически в ходу были и обходные методы, завязанные на косвенные признаки владения — например, на контактные данные из WHOIS или на переписку с адресами, которые «похожи на правильные». Именно такие практики и признаны проблемными: в рамках поэтапного отказа прекращают использовать проверки, опирающиеся на сообщения на контакты домена или IP-адреса через email, факс, SMS или обычную почту, «сконструированные» адреса электронной почты для домена, а также рассылку на контакты, указанные через DNS CAA или DNS TXT. В ту же категорию уходят телефонные подтверждения через контакт домена, через «телефон в DNS TXT», через «телефон в DNS CAA» и через контакт IP-адреса, а также схема с обратными проверками по IP-адресу и reverse address lookup.

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

В результате отрасль сильнее опирается на стандартизированные, современные и аудируемые методы DCV, включая автоматизацию по типу ACME, а заодно получает стимул ускорять и упрощать управление жизненным циклом сертификатов. В конечном итоге речь идет о том, чтобы убрать слабые звенья из процесса, на котором держится доверие к защищенным соединениям в интернете, и сделать эту базовую инфраструктуру устойчивее для всех.