«Замочку» в адресной строке теперь можно доверять больше. Chrome вводит строгие правила против хакеров
NewsMaker11 устаревших способов подтверждения домена уйдут в историю к марту 2028 года.
Индустрия 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-записи или в другом заранее оговоренном месте, после чего центр проверяет результат.
Индустрия 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-записи или в другом заранее оговоренном месте, после чего центр проверяет результат.