Напомним, что это не первый шаг такого рода. Ранее корпорация уже выступала за сокращение сроков SSL-сертификатов. И все эти инициативы подчинены одной цели – Google последовательно борется за достижение полной автоматизации процесса выдачи, переоформления и продления сертификатов. Только автоматизация привнесёт в экосистему скорость, безопасность, стабильность и простоту, объясняют в Google. Именно на простоте процесса делает акцент компания, продвигая значимые изменения, которые касаются удостоверяющих центров (CA): www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together.
Google сообщает, что предлагаемые изменения уже находятся на рассмотрении членами рабочей группы CA/Browser Forum Server Certificate, что однако не мешает компании продолжать проводить опросы CCADB и собирать реакцию на предлагаемые изменения от владельцев CA. Так что же такого предлагает компания, рассказывая про поощрение современной структуры и гибкости:
— Сокращение максимального срока для корневых CA, чьи сертификаты включены в корневое хранилище Chrome.
O 30 годах доверия можно смело забыть. Предлагаемая продолжительность срока составляет всего семь лет, считая с начальной даты включения сертификата. Срок действия сертификатов CA, уже включенных в Chrome Root Store, начнётся, когда вступит в силу политика, вводящая требование. Владельцам CA рекомендуется подать заявку с заменой сертификата через пять лет после включения, который должен содержать открытый ключ субъекта, который ранее не распространялся Chrome Root Store. Введение ограничения срока действия для корневых CA позволит экосистеме воспользоваться постоянными усилиями по совершенствованию, предпринимаемыми сообществом Web PKI.
— Сокращение максимального срока действия для подчинённых CA.
По той же логике предлагаемое ограничение максимального срока действия сертификата подчиненного CA до трёх лет должно способствовать повышению гибкости в экосистеме за счёт более надежных методов эксплуатации, снижению зависимости экосистемы от конкретных сертификатов подчинённых CA, которые могут представлять собой единые точки отказа, и препятствовать потенциально опасным методам, таким как привязка ключей.
— Сокращение максимального срока действия сертификата подписчика аутентификации сервера TLS с 398 до 90 дней.
Короткий срок побуждает всех участников автоматизировать процесс, что должно избавить экосистему от причудливых, трудоёмких и подверженных ошибкам процессов ручной выдачи. Сокращение срока действия сертификата также уменьшит зависимость экосистемы от сбоев при отзывах, что нарушает целостность защиты.
Google также предлагает сделать необязательными сервисы Online Certificate Status Protocol (OCSP) из-за случайных или преднамеренных раскрытий (например, из-за утечки данных в журналах или из-за повестки в суд).
Интернет-гигант отмечает, что многоцелевые корневые центры сталкиваются с новой реальностью и необходимостью в сжатые сроки удовлетворять многочисленные наборы требований абонентов. С этой точки зрения снижение сложности Web PKI полезно для повышения безопасности и стабильности экосистемы. В качестве ориентира Google приводит требование, которое может появиться в будущем обновлении политики или бюллетене CA/Browser Forum:
Ограничить значение extendedKeyUsage в новых подчинённых CA и сертификатах подписчика аутентификации сервера TLS только значением «id-kp-serverAuth». Изменение определения выделенной иерархии PKI TLS для запрета использования других значений extendedKeyUsage (т. е. id-kp-clientAuth) в новых сертификатах CA, способных выдавать сертификаты сервера TLS, более тесно согласовывает практику CA с вариантами использования веб-браузера (т. е. на сайты). Кроме того, он устраняет риск и непреднамеренные последствия других вариантов использования (например, IoT) от негативного влияния на аутентификацию веб-сайта.
Предлагаемые изменения тесно связаны с желанием Google поэтапно отказаться от существующих многоцелевых корневых сертификатов CA, включённых в корневой магазин Chrome, так чтобы Chrome Root Store в будущем принимал только сертификаты корневого центра сертификации кандидатов, которые являются частью иерархии PKI, предназначенной для выдачи сертификатов аутентификации сервера TLS.
Стремление к простоте и автоматизации всего процесса побуждает компанию активно продвигать открытую среду автоматического управления сертификатами (ACME, RFC 8555), которая без проблем позволяет запрашивать, выдавать, устанавливать и постоянно обновлять сертификаты аутентификации сервера во многих реализациях веб-серверов с обширным набором хорошо документированных параметров клиента, охватывающих несколько языков и платформ. Сегодня более 50% сертификатов, выдаваемых Web PKI, основаны на ACME. Кроме того, примерно 95% сертификатов, выдаваемых Web PKI сегодня, выпускаются владельцем ЦС с той или иной формой существующей реализации ACME, доступной для клиентов. И спрос, согласно опросу, проведённому Chrome Root Program, только растёт.
Поэтому неудивительно, что Google планирует ввести требования, которым должны соответствовать все заявители Chrome Root Store:
— быть частью иерархий PKI, которые предлагают услуги ACME для выпуска и управления сертификатами аутентификации сервера TLS.
— поддерживать ACME Renewal Information (ARI, Draft RFC ) для дальнейшего повышения гибкости экосистемы.
С включенным ARI владельцы CA смогут уменьшить негатив для клиентов, вызванный незапланированным отзывом, улучшить управление рутинными действиями по обновлению сертификатов (например, избежать того, чтобы значительная часть сертификатов обновлялась в узком интервале времени и позволить центру сертификации сообщить предпочтительное расписание и пройти поэтапное обновление, экономя ресурсы).
Готова ли индустрия к подобным изменениям уже сегодня, сказать сложно. Но очевидно, что все участники сообщества Web PKI понимают их важность.
Оптимизация и совершенствование методов проверки доменов также являются важными для Google. В своём блоге компания продвигает многообещающую технологию Multi-perspective Domain Validation (иногда называемую Multi-Vantage-Point Domain Validation ), позволяющую проводить проверку домена из нескольких географических местоположений или интернет-провайдеров, чтобы снизить вероятность применения маршрутизирующей атаки (например, перехват BGP) для мошеннического выпуска сертификатов аутентификации сервера TLS.
С целью повышения защиты доменов Google также предлагает в будущем обновлении политики или предложении бюллетеня форума CA/Browser
— сокращение периодов повторного использования проверки домена, а также сокращение максимально допустимого срока действия сертификата проверки подлинности сервера TLS с 398 до 90 дней.
— требования к владельцам CA выполнять проверку домена и проверку записей CAA с нескольких точек зрения.
Безусловно, все озвученные предложения являются также шагами в подготовке к «постквантовому» миру, которое сообщество Web PKI и рабочие группы CA/Browser Forum приближают всеми силами.
Нам же, как участникам этого процесса, необходимо держать руку на пульсе, быть в курсе событий и всегда соответствовать новым требованиям.
Комментарии (7)
mixsture
00.00.0000 00:00+5Стремление к простоте и автоматизации
Но, позвольте, простоте не нужна автоматизация! Автоматизация нужна там, где сложно!
Замена сертификатов раз в год — это простота, а 4 раза в год — сложнее и нужна автоматизация. Причем ACME время от времени переходит на новые версии протоколов и автоматизацию еще и переписывать раз в какое-то время нужно.
Кроме того, вероятность отказа ничуть не уменьшается при прочих равных: там где раньше была 1 операция, а теперь 4 — и вероятность отказа вырастет в 4.И спрос [на ACME], согласно опросу, проведённому Chrome Root Program, только растёт.
Так он разве потому растет, что всем нравится перевыпускать сертификаты? Он растет, потому что эти сертификаты можно бесплатно получить (let's encrypt например). Поставьте и обычные сертификаты по нулевой цене и тогда можно сравнивать, какой тип сертификатов удобнее сообществу.
adeshere
00.00.0000 00:00Поясните, пожалуйста, для чайника. Вот у меня есть собственноручно написанная программа под Windows, которой пользуется несколько коллег по работе. Она работает без специальной установки - ее просто переписывают на другой комп и запускают. Но из-за некоторых особенностей архитектуры примерно в половине случаев моя программа на новом компе не запустится, пока я не пропишу каталог с exe-шниками в исключениях Windows Defender. Хотя в других случаях - запускается почему-то... (Причины отличий мы так и не смогли выяснить, но на десятке проблем явно больше, чем на семерке, а на XP их вообще не было).
А теперь вопрос: может ли сертификат подлинности ПО помочь решению этого глюка (чтобы переписанная на новый комп самодельная программа запускалась без танцев с бубном вокруг Защитника Windows?).
И если да, то второй вопрос: может ли независимый и непрофессиональный разработчик некоммерческого ПО бесплатно и быстро получить такой сертификат для своей программы? Причем, новые версии появляются примерно раз в неделю, и каждая версия - это примерно 30 exe-шников (то есть это не совсем программа, а скорее пакет программ). Поэтому сложные (а тем более платные) процедуры, требующие длинной цепочки действий для каждого exe-шника, не годятся.
В идеале,
я бы хотел отправить архив со своими exe-шниками на сайт, и спустя полчаса (максимум - день) получить обратно некий файл (сертификат) с контрольными суммами, который можно просто записать в каталог с моими программами. И чтобы после этого при запуске этих моих программ у любого коллеги винда проверяла совпадение этих контрольных сумм и не мешала программам работать. А то сейчас у нас все как-то поставлено с ног на голову: операционная система - это не "обслуживающий персонал" для прикладных программ, а БигБосс, который может соизволить этим программам сделать что-то полезное для юзера, а может и запретить...
freeExec
00.00.0000 00:00Можешь создать самоподписанный сертификат и установить его в винде как доверенный, тем самым ты проверишь помогают они от брандмауэра или нет.
А бесплатных нету, их и для интернета-то не было до let's encrypt, но это как мы видим в интересах гугла.
Komei
00.00.0000 00:00препятствовать потенциально опасным методам, таким как привязка ключей.
Короче говоря, никакого обмена информацией без разрешение Гугла.
Короткий срок побуждает всех участников автоматизировать процесс, что должно избавить экосистему от причудливых, трудоёмких и подверженных ошибкам процессов ручной выдачи.
Заменив их множеством уязвимостей в ПО и железе. И если вы не Гугл и не можете сами разрабатывать HSM, то и безопасность вам не положена.
Google также предлагает сделать необязательными сервисы Online Certificate Status Protocol (OCSP)
Причём, конечно же, в том режиме, когда браузер делает независимый запрос к CA, сливая кто, когда и какой сайт посещает. Ну и конечно же Гугл является владельцем одного CA (а может контролирует и ещё какие-то - я не в курсе).
Chrome Root Store в будущем принимал только сертификаты корневого центра сертификации кандидатов, которые являются частью иерархии PKI, предназначенной для выдачи сертификатов аутентификации сервера TLS.
Единственно реально полезная вещь.
dvachu
00.00.0000 00:00А будет так. Закон примут, сертификаты почистят. В результате остатки сертификатов российских пользователей улетят в трэш. А новые мы уже не получим. А потом и краник с Let's Encript нам перекроют. Как-то так...
ifap
Здесь и зарыта собака: гугль хочет плотнее окружить своей заботой ЦС, чтобы они почаще приходили на поклон и лучше помнили, кому надо кланяться, чтобы не пролететь со своим корневым сертификатом.
Evengard
Вот да, тоже сложилось впечатление что это про контроль, а не про "безопасность". Как раз постоянный геморрой с включением всё новых и новых корневых сертификатов может наоборот помешать этой самой безопасности.