НОВОСТИ

20-05-18

Начиная с сентября 2018, в Google Chrome изменятся визуальные индикаторы для HTTPS

Мы уже писали о том, что Google планирует помечать все HTTP-сайты как небезопасные (Not secure). На днях Google сделали еще один шаг в этом направлении – начиная с сентября 2018, в Google Chrome (в версии 69) будет удалено слово «Secure» из адресной строки браузера для всех HTTPS-сайтов.

Наконец, в октябре с выходом Chrome 70 все сайты, не имеющие SSL-сертификатов, будут помечаться красным текстом «Not secure» в адресной строке браузера при пользовательском вводе данных.

Примечание: по умолчанию текст Not Secure для HTTP-страниц имеет серый вид, однако при заполнении любых форм он станет красным.

Почему были введены такие изменения? Как утверждают представители Google, пользователи должны понимать, что Сеть по умолчанию безопасна.

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

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

04-04-18

Протокол шифрования TLS 1.3 был окончательно доработан и утвержден группой IETF

Новый протокол TLS 1.3 был полностью доработан 21 марта 2018 года. До этого протокол обновлялся более 8 лет назад. Среди особенностей TLS 1.3 можно отметить улучшенную безопасность и производительность.

За описание протокола TLS отвечает группа Internet Engineering Task Force (IETF). Прошлая версия TLS, TLS 1.2, была описана в RFC 5246 и использовалась на протяжении 8 лет, имея поддержку в большинстве веб-браузеров. 21 марта 2018 года протокол TLS 1.3 был полностью доработан.

Улучшенная скорость в TLS 1.3

Если говорить о веб-производительности, то TLS и зашифрованные соединения поначалу добавляли дополнительные миллисекунды. С приходом HTTP/2 эта проблема была решена, а TLS 1.3 позволяет еще больше ускорить зашифрованные соединения. В TLS 1.3 появились такие возможности:

  • TLS false start (фальстарт TLS)
  • Zero Round Trip Time (0-RTT) (нулевое время приема-передачи). 

В TLS 1.2 для совершения TLS-рукопожатия (handshake) требовалось выполнить 2 приема-передачи (round-trip), в то время как в TLS 1.3 для этого требуется только 1 прием-передача (TLS False Start). Это позволяет наполовину сократить задержку для процедуры шифрования.

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

Улучшенная безопасность в TLS 1.3

В TLS 1.3 были удалены устаревшие и небезопасные алгоритмы, которые существовали в TLS 1.2: SHA-1, RC4, DES, 3DES, AES-CBC, MD5, CVE-2016-0701 и т.д.

Это позволяет исключить атаки на TLS, которые происходили ранее (достаточно вспомнить Heartbleed или POODLE). 

Соединения будут по-прежнему откатываться к версии протокола TLS 1.2, если какая-либо из сторон не поддерживает TLS 1.3, однако если злоумышленник попытается обманом вызвать такой откат (с помощью атак man-in-the-middle (MITM)), то в TLS 1.3 это будет обнаружено и предотвращено.

Протокол стал более простым, а потому менее вероятно допустить ошибку в его конфигурировании.

Поддержка браузеров:

  • В Chrome 63 поддержка TLS 1.3 включена для исходящих подключений. Поддержка TLS 1.3 появилась в версии Chrome 56.
  • В Firefox 52 протокол TLS 1.3 включен по умолчанию. Также он включен в Quantum.

Остальные браузеры обещают включить протокол в течение нескольких месяцев. 

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

20-02-18

Скорректированы правила проверки доменов для выпуска SSL-сертификатов

На днях CA/B Forum, регулятор индустрии SSL-сертификатов, принял большинством голосов предложение Ballot 218, связанное с удалением нескольких методов проверки (валидации) домена.

Основные изменения коснулись раздела 3.2.2.4 основного документа «Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates". В этом разделе содержатся разрешенные процессы и процедуры проверки прав владения доменом для заявителя.

По мнению Tim Hollebeek из DigiCert, эта секция нуждается в переработке, поскольку она содержит методы, не соответствующие целям раздела 3.2.2.4.

Какие конкретно изменения были внесены в документ

  1. Контактные данные о владельце домена могут быть получены напрямую от регистратора доменных имен, что было прописано в пункте 1.6.1.
  2. С 1 августа 2018 года контактные данные домена не должны использоваться для проверки заявителя, и их успешная проверка не может служить причиной для выпуска сертификатов. Вместо этого пункта вводится новая секция 3.2.2.4.12, разрешающая использовать контактные данные домена для проверки заявителя, но только в том случае, если удостоверяющий центр является регистратором доменных имен либо партнером регистратора базовых доменных имен.
  3. С 1 августа 2018 года документ авторизации домена (Domain Authorization Document) не должен использоваться для проверки заявителя, и успешная проверка этого документа не может служить причиной для выпуска сертификатов.
  4. Убрана секция 3.2.2.4.11, описывающая альтернативные методы проверки домена.

Остальные правила проверки доменов остались без изменений. 

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