Рейтинг
0.00

Leaderssl Хостинг

1 читатель, 31 топик

CA/B Forum уточнил использование атрибутов поля Subject в SSL-сертификатах



На днях 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, появятся в новой версии Яндекс.Браузера, на поиске, а также в других сервисах компании.

Яндекс еще в конце февраля предупредил пользователей о том, что в дальнейшем компания планирует вводить более явные сигналы о небезопасности 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 обновил методы IP-валидации



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 обновил методы телефонной валидации



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. В противном случае его нельзя будет использовать.

CA/B Forum проголосовал за удаление валидационного метода с использованием тестового сертификата (3.2.2.4.9)



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

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

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

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

Вышла новая версия Chrome 72: TLS 1.0 и TLS 1.1 признаны устаревшими, поддержка HPKP удалена



Разработчики 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.

В Firefox 65 предупреждения о MitM-атаках будут расширены


Начиная с версии 61, в браузере Firefox появилось новое предупреждение о том, что программа пытается выполнить MitM-атаку (Man-in-the-Middle). В предстоящей версии Firefox 65 это предупреждение будет дополнено информацией, указывающей на то, что причиной ошибки может выступать антивирусная программа.

Ошибка MOZILLA_PKIX_ERROR_MITM_DETECTED могла появляться в Firefox в нескольких ситуациях, которые не имеют отношения к атакам со стороны злоумышленников:
  • при сканировании зашифрованного трафика антивирусом;
  • при анализе HTTPS-трафика различными инструментами отладки.
Чтобы предоставить пользователям максимально развернутую информацию, в Firefox 65 будут расширены уведомления об ошибке MOZILLA_PKIX_ERROR_MITM_DETECTED.

До версии 65 в Firefox уведомления о том, что сертификат может использоваться в MitM-атаке, были слишком неинформативными. Все, что мог видеть пользователь – это краткое предупреждение «Warning: Potential Security Risk Ahead».

В версии Firefox 65 новое предупреждение об ошибке будет включать в себя дополнительное описание с указанием проблемного сертификата, который потенциально может быть задействован в MitM-атаке. Пользователь сможет понять, какая именно программа привела к ошибке – антивирусный софт, веб-отладчик или же вредоносное ПО.

Как устранить ошибку MOZILLA_PKIX_ERROR_MITM_DETECTED
Если сертификат, генерирующий ошибку, является легитимным (к примеру, принадлежит вашей антивирусной программе), вы можете совершить следующие действия, чтобы ошибка MOZILLA_PKIX_ERROR_MITM_DETECTED перестала выдаваться:
  • отключите SSL- или HTTPS-сканирование в вашем антивирусе;
  • включите его снова.
В результате этих манипуляций сертификат антивируса будет добавлен в хранилище сертификатов Firefox, и предупреждение пропадет.

Если же у вас действительно имеется вредоносный или рекламный софт, который инициировал MitM-атаку (попытался внедрить свой сертификат), вам нужно будет просканировать свой компьютер и устранить все опасные программы.

Подписывайтесь на наши обновления, чтобы всегда быть в курсе свежих событий в мире SSL!
www.leaderssl.ru

Подводим итоги 2018 года



Сегодня же мы решили по традиции подвести итоги уходящего 2018 года. Что было нами реализовано, каких успехов мы достигли, чем нам запомнился этот год – давайте вместе пробежимся по этим памятным страницам!

1. Организационный партнер мероприятия ХостОбзор
В 2018 году мы выступили в качестве организационного партнера XIX-го Всероссийского форума провайдеров хостинга и регистраторов ХостОбзор. Это знаковое для нашей страны мероприятие, объединяющее хостинг-компании, телекоммуникационные организации, а также компании, работающие во многих смежных дисциплинах и областях. Благодаря участию в данном форуме мы смогли значительно расширить свою партнерскую сеть, пообщаться с уже устоявшимися партнерами и дружественными компаниями.

2. Перевод сайтов на новую версию движка
Основополагающий принцип работы компании ЛидерТелеком – забота о клиентах. В 2018 году мы усовершенствовали наши сайты, что позволило сделать процесс заказа максимально гладким и понятным для посетителей. Переезд на новую версию движка привел к двукратному увеличению скорости работы наших сайтов.

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

4. Улучшение контрольной панели
Мы кардинально переработали нашу контрольную панель, сделав ее современной, быстрой и удобной в использовании. Большое спасибо всем тем, кто делился с нами своими идеями, отзывами и комментариями – ваша обратная связь помогла нам стать лучше!

5. WHMCS-модуль для партнеров
Не остались без внимания и партнеры. В 2018 году мы оптимизировали взаимодействие с ними, предложив удобный WHMCS-модуль для простого реселлинга SSL-сертификатов и других смежных решений и инструментов. Модуль стал доступен для скачивания с нашего сайта. Также к нему прилагается инструкция по установке и API для удобной интеграции.

Весь год мы знакомили вас с новостями из мира SSL и онлайн-безопасности, старательно отбирая все самое лучшее, значимое и интересное. Если вы все еще не подписались на нашу новостную рассылку, то сейчас самое время это сделать!

Большое спасибо, что остаетесь с нами! С НОВЫМ 2019 ГОДОМ!

Ваш ЛидерТелеком.

Удостоверяющий центр Sectigo анонсировал отказ от корней Comodo CA в пользу корней USERTrust CA



Удостоверяющий центр Sectigo анонсировал отказ от корней Comodo CA. Переход к новым корням USERTrust CA должен произойти 14 января. Это позволит Sectigo исключить любые упоминания бренда Comodo – в частности, убрать его из промежуточных и корневых удостоверяющих центров.

Корни USERTrust CA являются широко доверенными, они существуют с 2000 года. Их обновленные версии были созданы в 2010 году. Переход к корням USERTrust CA позволит Sectigo полностью отмежеваться от использования бренда «Comodo» в своей инфраструктуре.

Все это продолжает намеченный план по отделению Sectigo от Comogo Group, о котором мы уже писали ранее.

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

Новая цепочка промежуточных сертификатов будет применяться ко всем выпускаемым или продлеваемым сертификатам с 14 января 2019 года.

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

CA/B Forum запретил использовать символы подчеркивания в записях dNSName



CA/B Forum, орган регулирования SSL-индустрии, запретил использовать символы подчеркивания («_») в любых записях dNSName. Соответствующее предложение (Ballot SC12) было принято и поддержано большинством голосов.

Похожее заявление уже рассматривалось в 2017 году, однако тогда было отклонено, невзирая на то, что практика использования символа подчеркивания в SAN-полях типа dNSName противоречит требованиям RFC 5280.

Текущее предложение включает в себя формирование короткого переходного периода, в течение которого можно будет либо сменить доменное имя (FQDN), либо развернуть wildcard-сертификат.

Сроки внедрения предложения
Согласно новым правилам, до 1 апреля 2019 выпуск сертификатов, содержащих символы подчеркивания («_») в метках доменов в записях dNSName, разрешен лишь при выполнении следующих требований:
  • Символы подчеркивания не должны находиться на первой позиции слева в доменной метке;
  • Сертификат выпускается только на срок, не превышающий 30 дней;
  • Символы подчеркивания могут использоваться, но их лучше сменить на дефисы, чтобы получить доверенную доменную метку.
  • Все сертификаты, содержащие символ подчеркивания в любой dNSName-записи и имеющие срок действия, превышающий 30 дней, должны быть аннулированы до 15 января 2019 года.

Начиная с 30 апреля 2019 года, символы подчеркивания («_») не должны присутствовать в записях dNSName.

Подпишитесь на наши обновления, чтобы всегда быть в курсе последних событий в области SSL и онлайн-безопасности.

www.leaderssl.ru