Рейтинг
0.00

Leaderssl Хостинг

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

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

Компания Comodo CA провела ребрендинг: теперь она называется Sectigo



Comodo CA, популярный удостоверяющий центр, а также крупный поставщик решений в области онлайн-безопасности, анонсировал свой ребрендинг – компания решила сменить свое название в пользу Sectigo. Примерно год назад компания была выкуплена Francisco Partners.

Главная цель ребрендинга, по словам генерального директора Sectigo Билла Хольца (Bill Holtz), заключалась в том, чтобы ликвидировать существующую рыночную путаницу и выйти на более широкий рынок решений для онлайн-безопасности. Путаница образовалась в связи с отделением Comodo CA от Comodo Group — обе компании работают на тех же самых рынках, но при этом в юридическом плане являются разными организациями.

Что изменилось в связи с ребрендингом?
Новые логотипы и новая цветовая гамма – то, что изменилось в связи с ребрендингом Comodo CA. Печать доверия сайта теперь носит название Sectigo. Также поменялись и наименования некоторых продуктов. Устоявшиеся названия, такие как PositiveSSL и InstantSSL, теперь подписываются как «powered by Sectigo».

Конечным пользователям не придется ни о чем волноваться. Все корни Comodo CA останутся прежними. Если до этого вы использовали печать доверия Comodo, то теперь ее можно будет сменить на печать доверия Sectigo.

Вы всегда можете приобрести SSL/TLS-сертификаты Sectigo (бывшие Comodo) в магазине LeaderSSL по самым выгодным ценам.

Google Chrome, Mozilla Firefox и другие браузеры перейдут к 2020 году на TLS 1.2



Представители Google, Microsoft, Mozilla и Apple объявили о том, что к 2020 году в их браузерах будет отключена поддержка Transport Layer Security (TLS) 1.0 и 1.1. Новой версией по умолчанию станет TLS 1.2.

Браузеры Chrome, Edge, Internet Explorer, Firefox и Safari в данный момент имеют поддержку TLS 1.2. При этом в Chrome и Firefox уже имеется поддержка TLS 1.3 – стандарта, который недавно был утвержден в своем финальном виде. Microsoft и Apple пока только планируют включить поддержку TLS 1.3 в будущих версиях своих браузеров.

Как показывает статистика SSL Labs, сегодня 94% всех сайтов в сети используют TLS 1.2.

Ключевые особенности анонсов производителей браузеров:
  • TLS 1.0 и 1.1 будут полностью отключены в версии Chrome 81, которая запланирована к выпуску в январе 2020.
  • Edge и Internet Explorer 11 отключат TLS 1.0 и 1.1 в первой половине 2020 года.
  • В Firefox поддержка TLS 1.0 и 1.1 будет отключена в марте 2020.
  • В Safari поддержка TLS 1.0 и 1.1 будет убрана в марте 2020 вместе с обновлениями Apple iOS и macOS.
Подписывайтесь на нашу рассылку, чтобы всегда быть в курсе последних событий в сфере SSL и онлайн-безопасности!

www.leaderssl.ru

Что произойдет, если SSL-сертификат истечет



Что будет, если вовремя не обновить SSL-сертификат? Этот вопрос нам часто задают клиенты. Сразу скажем: последствия самые серьезные. Если вы являетесь клиентом LeaderSSL, то вы сможете минимизировать риски подобной ситуации. Как именно? Читайте далее!

Сертификат истек: чем это грозит на практике?
Как вы знаете, срок действия SSL-сертификатов является ограниченным. Это требование CA/B Forum, регулирующего органа индустрии SSL-сертификации. Несколько лет назад вполне легально можно было заказать трехлетние, четырехлетние или даже пятилетние SSL-сертификаты. Сегодня SSL-сертификаты могут иметь срок действия до 27 месяцев (2 года + 3 месяца, которые даются на продление срока действия прошлого сертификата). Индустрия с целью безопасности ограничивает максимальные сроки действия SSL-сертификатов.

Это ведет к тому, что SSL-сертификат нужно обновлять или заменять – либо каждый год, либо раз в 2 года.

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


Естественно, все это чревато следующими негативными последствиями:
  • Трафик вашего сайта кардинально упадет. Как показывают исследования, пользователи, столкнувшиеся с подобным уведомлением, тут же закрывают сайт. Лишь малая часть всех посетителей принимает истекший сертификат.
  • Продажи сильно снизятся. Поскольку сайт выдает предупреждение, пользователи могут посчитать, что ресурс является небезопасным, а потому не станут совершать покупки, даже если делали их на этом же сайте ранее.
  • Показатели ранжирования сайта сильно упадут. В ближайшей перспективе ваш сайт будет постепенно сваливаться вниз в поисковой выдаче, так как поисковые роботы учитывают многие факторы, в том числе и поведение посетителей.
Истечение сертификата грозит катастрофическими последствиями для любого бизнеса. Если вы являетесь клиентом LeaderSSL, то вы можете обезопасить себя от подобных чрезвычайных ситуаций.

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

Чтобы облегчить этот процесс, мы предлагаем следующие инструменты и механизмы:
  • Почтовые уведомления. Вы получите уведомления на почту о том, что ваш SSL-сертификат истекает. Первое письмо мы отправляем за 90 дней до окончания срока действия SSL-сертификата. Остальные письма рассылаются нами с заранее установленной периодичностью.
  • Платформа для централизованного управления сертификатами. Сервис MPKI помогает отслеживать полный жизненный цикл всех имеющихся SSL-сертификатов, при необходимости продлевая, перевыпуская или аннулируя их в удобном режиме. Вы можете заказать MPKI от ЛидерТелеком по следующей ссылке.
  • Новостные рассылки и публикации в наших группах в социальных сетях. Мы регулярно следим за ситуацией, связанной с SSL-сертификатами, имея свое членство в CA/B Forum. По этой причине любые изменения, касающиеся срока действия сертификатов, не пройдут мимо вас. Просто подпишитесь на нашу новостную рассылку или на нашу группу в предпочтительной социальной сети, чтобы держать руку на пульсе событий.
Истекшие SSL-сертификаты – причина многочисленных проблем и неприятностей для бизнеса. Чтобы предлагать своим клиентам лучший опыт взаимодействия, обязательно вовремя продлевайте свои сертификаты в LeaderSSL.

Даже если раньше вы заказывали SSL-сертификат в другом магазине, вы можете продлить свой сертификат у нас. Сделайте шаг к стабильному будущему вместе с LeaderSSL!
www.leaderssl.ru/mpki

Лондонский протокол: новая инициатива по борьбе с фишингом



Совет безопасности центров сертификации (The Certificate Authority Security Council (CASC)) на мероприятии CA/Browser Forum в Лондоне объявил о запуске новой инициативы, которая получила название Лондонского протокола. Данная инициатива преследует следующие цели:
  • более надежное подтверждение идентифицирующих сведений;
  • минимизация фишинга для сайтов с OV и EV-сертификатами.
Учитывая недавний рост фишинговых атак, Лондонский протокол предлагает усилить различие между сайтами с DV-сертификатами и сайтами с OV- и EV-сертификатами.

Реализация инициативы будет осуществляться на добровольных началах с привлечением удостоверяющих центров, которые будут выполнять следующие задачи:
  • Активно отслеживать фишинговые отчеты для сайтов с OV- и EV-сертификатами, выпущенными этим удостоверяющим центром.
  • Уведомлять пострадавшего владельца сайта о том, что был обнаружен фишинговый контент, и предлагать инструкции по устранению проблемы наряду с мерами защиты.
  • Пополнять общую базу данных для сокращения объемов фишингового контента. Эти данные будут доступны другим удостоверяющим центрам, чтобы все они могли провести дополнительное исследование перед выпуском OV- и EV-сертификатов.
  • Разрабатывать систему коллизий имен, чтобы предотвратить вектор угроз Stripe.
Для выпуска DV-сертификатов удостоверяющим центрам не требуется проверять данные организации.

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

Для выпуска OV-и EV-сертификатов удостоверяющие центры должны проверить информацию по организации, что производится разными способами. Чтобы улучшить безопасность в интернете и осведомленность о OV- и EV-сертификатах, удостоверяющие центры в рамках Лондонского протокола будут взаимодействовать между собой для обеспечения безопасности подтверждения идентифицирующих данных и минимизации фишинга для сайтов с OV- и EV-сертификатами.

Реализация Лондонского протокола будет происходить поэтапно:
  • Июнь-август 2018. Удостоверяющие центры прорабатывают инициативу и начинают исполнять некоторые базовые процедуры.
  • Сентябрь-ноябрь 2018. Удостоверяющие центры применяют концепции протокола к сайтам клиентов с OV- и EV-сертификатами, опираясь на свои собственные политики и процедуры, обмениваются обратной связью с другими удостоверяющими центрами, уточняют протокол на базе полученного опыта.
  • Декабрь 2018 – февраль 2019. Удостоверяющие центры обновляют политики и процедуры протокола, утверждают план по унификации политик и процедур, которые должны применяться удостоверяющими центрами на добровольной основе.
  • Март 2019. Удостоверяющие центры готовят отчет и свои рекомендации для CA/Browser Forum по возможным изменениям в Baseline Requirements (базовые требования).

Лондонский протокол – это попытка вернуться к тому, ради чего создавались EV- и OV-сертификаты – для обеспечения доверия пользователей и безопасности передаваемых данных.

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

Apple приняли новую политику прозрачности SSL-сертификатов



На конференции Apple Worldwide Developers Conference (WWDC) 2018 компания сделала важное заявление: начиная с 15 октября, все SSL/TLS-сертификаты должны быть внесены в публичные логи прозрачности, иначе Safari и различные платформы Apple не будут им доверять.

Это утверждение соответствует требованиям прозрачности, которые были установлены Google и Mozilla ранее. Требование внесения сертификатов в лог прозрачности совпадает с выходом свежего релиза Safari.

До недавнего момента требование внесения сертификатов в журнал прозрачности распространялось только на EV SSL-сертификаты.

Доля Safari составляет приблизительно 3% от всего объема десктопных браузеров, однако в случае с мобильным сегментом она кардинально увеличивается – почти 27%. Новая политика прозрачности будет распространяться как на десктопный браузер Safari, так и на его мобильную версию.

Требуются ли какие-либо действия от пользователей?
Любой сертификат, выпущенный после 15 октября, будет подпадать под новые требования Apple. Важно отметить, что прозрачность сертификатов – задача, возложенная на удостоверяющие центры. От конечных пользователей никаких действий не требуется.

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

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

Мы пристально следим за всеми изменениями со стороны индустрии SSL. Заказывайте сертификаты у нас в LeaderSSL по самым доступным ценам!

www.leaderssl.ru/products

Как отключить устаревшие версии SSL/TLS в Apache



Начиная с 30 июня 2018, для совместимости с PCI владельцы сайтов должны отказаться от поддержки TLS 1.0. Протоколы TLS 1.0/1.1 и SSL 2.0/3.0 являются устаревшими. Они не дают должной защиты при передаче данных. В частности, TLS 1.0 содержит уязвимости для некоторых атак. Представленные выше версии протоколов должны быть удалены в средах, требующих высокого уровня безопасности.

Практически все современные браузеры поддерживают TLS 1.2. Ниже мы рассмотрим, как отключить версии TLS 1.0/1.1 и SSL 2.0/3.0 в Apache.

1.Используем vi (или vim) для редактирования ssl.conf (обычно находится в папке /etc/httpd/conf.d).

2.Ищем раздел SSL Protocol Support. Он имеет вид:
#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3

3.Комментируем строку SSLProtocol all -SSLv2 -SSLv3, добавив перед ней символ решетки.

4.Добавляем под ней строку:
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

5.Мы отключили TLS 1.0/1.1 и SSL 2.0/3.0. Далее ищем секцию SSL Cipher Suite.
#   SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA

6.Комментируем строку SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA и добавляем под ней следующее:
SSLCipherSuite HIGH:!aNULL:!MD5:!3DES

Этот параметр гарантирует использование SSL-шифров только с высокой степенью защиты.

Также добавьте под SSLCipherSuite HIGH:!aNULL:!MD5:!3DES строку:
SSLHonorCipherOrder on

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

Сохраняем файл и перезапускаем Apache.
service httpd restart

Далее тестируем все приложения, которые взаимодействуют с вашим сервером. Если у вас возникнут какие-либо проблемы, вы можете снять комментарии и вернуться к прошлой версии файла.

Следуйте за лучшими практиками в области SSL вместе с ЛидерТелеком!

Домены .app от Google, доступные только по HTTPS, открылись для регистрации



8 мая Google открыл регистрацию доменов .app для широкой публики. Как и следует из названия, эти домены предназначены для разработчиков приложений, однако зарегистрировать домен можно и для любых других целей.

Отличительной особенностью доменов .app является то, что они требуют от владельцев сайта установки SSL-сертификата и передачи контента по HTTPS.

Компания Google купила права на доменную зону .app в феврале 2015 года за гигантскую сумму, равную $25,001,000. Этот шаг позволил Google установить свои правила для доменов .app – разрешить только HTTPS-соединения.

Формально открытие регистрации .app доменов произошло еще 1 мая в рамках программы раннего доступа, когда за дополнительную плату пользователи могли «забронировать» для себя интересный домен.

По программе раннего доступа пользователи зарегистрировали свыше 100 000 доменов. Не так давно компания Google открыла регистрацию доменов .app для широкой общественности.

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

Начиная с сентября 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-сертификат, мы рекомендуем незамедлительно это сделать, чтобы не столкнуться с оттоком посетителей.

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

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


Новый протокол 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!