Предложение Ballot SC22 по сокращению максимального срока действия SSL-сертификатов до одного года (точнее: до 397 дней) было отклонено большинством голосов. Активные обсуждения, связанные с этим, велись в CA/B Forum на протяжении последних нескольких месяцев.

В данный момент максимальный срок действия SSL-сертификата составляет 2 года (точнее: 825 дней).

Как показали результаты Ballot SC22, все опрошенные поставщики браузеров проголосовали за сокращения срока действия сертификатов. Также к ним присоединились Let's Encrypt, Sectigo, Amazon и некоторые другие компании.

Среди противников данного нововведения выступили Certum, Entrust Datacard, GlobalSign, GoDaddy и еще 15 компаний.

За сокращение срока действия сертификатов до года проголосовало в общей сложности 37% участников CA/B Forum.

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

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

www.leaderssl.ru

Разработчики крупнейших браузеров Google Chrome и Mozilla Firefox анонсировали отказ от вывода наименования компании в EV (Extended Validation) SSL-сертификатах. В данный момент наименование организации выводится в адресной строке браузера.


Начиная с версии Chrome 77, которая по плану должна появиться в сентябре, в адресной строке браузера больше не будет присутствовать наименование организации. Аналогичное нововведение будет реализовано и в версии Firefox 70, которая запланирована на октябрь.

Почему разработчики браузеров решили отказаться от индикации EV в адресной строке
Всю информацию о EV SSL-сертификате теперь можно будет посмотреть при щелчке по иконке замочка.

Причина отказа от EV-индикаторов в адресной строке браузеров проста: крупные компании, включая Twitter, Amazon, YouTube, Facebook, не используют эти сертификаты.

В долгосрочной перспективе разработчики Chrome хотят вообще отказаться от иконки замочка для HTTPS-сайтов. То же самое будет реализовано и в Firefox 77.

По мнению специалистов Google, наименование EV-сертификата занимает ценное пространство экрана браузера и ломает целостность UI для всех остальных видов сертификатов.

Еще одна проблема: в мобильных браузерах чаще всего не отображается EV-индикация (или отображается, но для большинства пользователей она незаметна). Специалисты Apple уже отказались от вывода наименования компании для EV-сертификатов в Safari на iOS 12 и macOS 10.14.

Безусловно, отказываться от EV SSL-сертификатов не понадобится – они по-прежнему используются и гарантируют максимальную защиту передаваемых данных.

www.leaderssl.ru

CA/B Forum, регулирующий орган индустрии SSL, принял большинством голосов Ballot SC19, согласно которому владельцы доменов теперь могут публиковать номера телефонов в записях DNS CAA, что используется для выполнения валидации.

Правила «Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates» были изменены, о чем мы расскажем далее.

Добавлена секция 3.2.2.4.17
Данный раздел определяет правила телефонной связи при помощи номера, определенного в DNS CAA.

Согласно секции 3.2.2.4.17, удостоверяющий центр может подтвердить контроль заявителя над доменным именем при помощи совершения звонка по номеру, который указан в DNS CAA. Во время одного телефонного звонка могут быть подтверждены несколько доменных имен, если для них был указан один и тот же телефонный номер.

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

Метод подходит в том числе и для проверки Wildcard-доменов.

Добавлена секция B.1.2.
В приложении описывается свойство CAA contactphone и его синтаксис. Свойство принимает значение телефонного номера. В качестве значения должен использоваться глобальный номер, что определено в секции 5.1.4 RFC 3966. Глобальные номера начинаются с символа «+» и включают в себя код страны. Также номера могут содержать визуальные разделители.

Пример:

$ORIGIN example.com.
CAA 0 contactphone “+1 (555) 123-4567”

www.leaderssl.ru

Протокол ACME (Automated Certificate Management Environment) был официально стандартизирован Инженерным советом Интернета (IETF). С помощью протокола ACME удостоверяющие центры могут автоматизировать процесс выдачи и проверки сертификата.

Преимущества стандартизации ACME
Наличие стандартизированного протокола, позволяющего выпускать сертификаты и управлять ими, несет в себе следующие преимущества:

• Повышается качество программной экосистемы. Разработчики могут придерживаться одного протокола, вместо того чтобы поддерживать разные компоненты посредством произвольных API.
• Упрощается переключение между удостоверяющими центрами. Происходит минимизация технической привязки к одного УЦ.

В данный момент, как следует из описания протокола, ACME вряд ли подойдет для выпуска OV и EV SSL-сертификатов, однако он может сыграть важную роль в этом процессе. Потенциально ACME позволяет автоматизировать некоторые шаги процесса валидации, которые требуются для выпуска OV и EV сертификатов.

Крупные удостоверяющие центры уже начинают внедрять ACME протокол. Как следует из открытых источников, DigiCert тестирует внедрение поддержки ACME в свою платформу управления сертификатами CertCentral. Также поддержка ACME присутствует в менеджере сертификатов Sectigo.

www.leaderssl.ru

На днях CA/B Forum, регулирующий орган индустрии SSL, большинством голосов принял Ballot SC16, призванный уточнить использование атрибутов поля Subject в SSL-сертификатах.

Суть предложения Ballot SC16
В секцию 7.1.4.2 базовых требований (Baseline Requirements) теперь добавляется уточнение: «атрибуты Subject не должны состоять из одних метаданных (нельзя в качестве значения приводить такие символы, как точка, дефис или пробел). Недопустимым является любое указание на то, что значение отсутствует, неполное или не применяется».

Секция 7.1.4.2.2(j.) была дополнена следующим уточнением: «в поле Subject могут присутствовать другие атрибуты. Если они имеются, то они должны содержать информацию, проверенную удостоверяющим центром».

Также Ballot SC16 меняет и правила расширенной проверки «Guidelines For The Issuance And Management Of Extended Validation Certificates».

Секция 9.2.8 теперь содержит следующее уточнение:

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

Также добавляется секция 9.2.9, гласящая:

Удостоверяющий центр может добавлять только те атрибуты Subject, которые указаны в секции 9.2

Предупреждения о небезопасности сайтов, передаваемых по HTTP, появятся в новой версии Яндекс.Браузера, на поиске, а также в других сервисах компании.

Яндекс еще в конце февраля предупредил пользователей о том, что в дальнейшем компания планирует вводить более явные сигналы о небезопасности HTTP-сайтов для посетителей.

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

Реализацию предупреждений о HTTP можно уже посмотреть в бета-версии Яндекс.Браузера 19.3.1. Нечто подобное в ближайшее время появится и в поисковой системе Яндекс.

Начиная с конца января 2019, в сервисе Яндекс.Вебмастер также стали появляться уведомления о том, что сайт использует протокол HTTP, и давались рекомендации по переходу на HTTPS.

Многие вебмастера считают, что со временем влияние HTTPS на ранжирование страниц в Яндексе будет только расти.

Если вы до сих пор используете протокол HTTP на своих сайтах, мы настоятельно рекомендуем перейти на HTTPS. Это позволит вам избежать утечки пользователей в результате новых уведомлений Яндекса о небезопасности HTTP-сайтов.

Чтобы перейти на HTTPS, вам необходимо приобрести SSL-сертификат. Для бизнеса мы советуем приобретать EV SSL-сертификаты, которые позволяют вывести наименование организации в адресной строке браузера.
www.leaderssl.ru/suppliers/comodo/products/ev

Владельцам обычных информационных сайтов и блогов подойдет самый простой сертификат Positive SSL.
www.leaderssl.ru/suppliers/comodo/products/positivessl

CA/B Forum, регулирующий орган SSL-индустрии, принял Ballot SC7, посвященный обновлению методов IP-валидации.

Ранее был принят Ballot 169, который включал в себя удаление метода 11 («Любой другой метод») из секции 3.2.2.4. Вместо него указывались явные методы валидации.

Новый Ballot SC7 предлагает также удалить пункт 4 («Любой другой метод») в 3.2.2.5 и указать вместо него явный список методов IP-валидации.

Планируется, что со временем методы IP-валидации будут обрабатываться так же, как методы валидации доменов.

Список основных изменений в Ballot SC7
Ключевое изменение в Ballot SC7 – полное обновление секции 3.2.2.5 базовых требований (Baseline Requirements).

В частности, в секции приводятся разрешенные процессы и процедуры для валидации владения или управления IP адресом, указанным в сертификате.

Краткий список изменений:

• Удостоверяющий центр теперь до выпуска сертификата должен убедиться в том, что все IP-адреса, указанные в сертификате, были проверены с использованием одного из допустимых методов, приведенных в подразделах 3.2.2.5.
• С 31 июля 2019 года удостоверяющие центры должны вести учет того, какой именно метод проверки IP-адреса был использован (с добавлением соответствующей версии базовых требований).
• Добавлен пункт 3.2.2.5.1 для подтверждения контроля над IP-адресом через токен или случайное значение в файле веб-страницы сайта (в директории /.well-known/pki-validation или в любой другой, зарегистрированной в IANA).
• Добавлен пункт 3.2.2.5.2 для подтверждения контроля над IP-адресом через email, факс, SMS, бумажное письмо.
• Добавлен пункт 3.2.2.5.3 для обратного просмотра адресов.
• Метод 3.2.2.5.4 («Любой другой метод») с 31 июля 2019 не должен использоваться для выполнения проверок.
• Добавлен метод 3.2.2.5.5 для подтверждения контроля над IP-адресом путем телефонного звонка заявителю (или отправки голосового сообщения).
• Добавлен метод 3.2.2.5.6 для подтверждения контроля над IP-адресом путем выполнения процедуры ACME “http-01”.
• Добавлен метод 3.2.2.5.7 для подтверждения контроля над IP-адресом путем выполнения процедуры ACME “tls-alpn-01”.

Полный список изменений базовых требований вы можете найти на GitHub: github.com/dougbeattie/documents/compare/master...dougbeattie:SC14---Phone-validation-updates

CA/B Forum, регулятор индустрии SSL-сертификатов, принял новые изменения, касающиеся методов телефонной валидации.

Предложение Ballot SC14 устраняет некоторые потенциальные риски безопасности, связанные с методом 3 (3.2.2.4.3) базовых требований (Baseline Requirements). В частности, Ballot SC14 предлагает ужесточить телефонную валидацию, чтобы убедиться, что авторизация или управление доменом осуществляется персоной, уполномоченной это делать.

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

Ballot SC14 основан на предложении Ballot SC13, которое позволяет владельцам доменов публиковать номера телефонов для валидации доменов в TXT-записях DNS. Поскольку эти телефонные номера специально предназначены для валидации доменов, переход на другой номер не допускается.

Изменения, предлагаемые в Ballot SC14
Ballot SC14 вносит следующие изменения в базовые требования (Baseline Requirements) по выпуску публичных сертификатов.

В секцию 1.6.1 вносится следующее дополнение:

«Телефонный номер в DNS TXT-записи: телефонный номер, определенный в секции B.2.2»

В секции 3.2.2.4.3 после второго абзаца добавляется следующий абзац: «удостоверяющий центр не должен выполнять валидацию с помощью данного метода после 31 мая 2019. Уже выполненные валидации с помощью данного метода будут оставаться действительными вплоть до последующего продления сертификата».

Вместо секции 3.2.2.4.3 в документ Baseline Requirements добавляются две новых секции: 3.2.2.4.15 и 3.2.2.4.16.

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

Удостоверяющий центр может оставить случайное значение в голосовом сообщении для проверки заявителя. Это значение должно быть передано удостоверяющему центру для подтверждения запроса. Случайное значение будет оставаться действительным в течение максимум 30 дней с момента его создания. Удостоверяющие центры могут задавать более короткий период валидности для таких случайных значений.

Секция 3.2.2.4.16 устанавливает правила для телефонной связи через DNS TXT-запись. В данном случае контроль владения доменом проверяется путем звонка на номер, указанный в DNS TXT-записи. Как только будет получен подтверждающий ответ, полное доменное имя будет проверено. Правила проверки (по звонкам и голосовым сообщениям) здесь аналогичны секции 3.2.2.4.15.

Также добавляется аппендикс B.2.2. В нем отмечены правила задания DNS TXT-записи:

DNS TXT-запись должна быть размещена на поддомене «_validation-contactphone» того домена, который необходимо проверить. Полное значение RDATA этой TXT-записи должно представлять собой валидный глобальный номер, как определено в секции 5.1.4 RFC 3966. В противном случае его нельзя будет использовать.

A/B Forum, регуляционный орган индустрии SSL-сертификатов, принял большинством голосов новое предложение Ballot SC15, связанное с удалением валидационного метода 3.2.2.4.9.

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

Метод 3.2.2.4.9 будет удален вследствие того, что он является небезопасным – часто бывает ситуация, когда веб-хостинг использует один IP-адрес для нескольких доменных имен.

Этот метод больше не будет использоваться для валидации и выпуска сертификатов.

Разработчики Google Chrome выпустили новую версию 72, основные изменения которой направлены на базовые Web API и протоколы браузера.

Наиболее важным из изменений является полное удаление поддержки HPKP (HTTP-Based Public Key Pinning). Мы уже писали ранее о том, что Google планировал отказаться от HPKP. Впервые стандарт был признан устаревшим в Chrome 65, который вышел в марте 2018.

Владельцам сайтов, использующим HPKP, рекомендовано отказаться от поддержки этого стандарта.

Еще одна важное изменение – Chrome больше не будет обрабатывать ресурсы, загруженные по FTP. Теперь Chrome предложит скачать файл вместо его обработки и запуска.

Третье важное изменение – признание стандартов TLS 1.0 и TLS 1.1 устаревшими. Полный отказ от поддержки этих двух стандартов будет произведен в Chrome 81, выпуск которого запланирован на 2020 год.

Теперь Chrome будет выдавать ошибку в консоли разработчика, когда пользователь запрашивает доступ к HTTPS-сайту с использованием устаревших TLS 1.0/1.1 сертификатов. При этом доступ к сайту пока не будет блокироваться. Блокировка произойдет уже с версии Chrome 81.

Помимо прочего, разработчики также исправили 58 различных ошибок безопасности в Chrome 72.