Что такое HTTPS и SSL – Кому и для чего нужно переходить на HTTPS протокол?

Почему сейчас всё работает именно так?

Об этом хорошо написано

. Отсутствие

hard fail

и отказ от явного выполнения OCSP-запросов на стороне клиента обусловлены следующими факторами:

• инфраструктура УЦ станет единой точкой отказа. Недоступность OCSP-сервера может стать причиной отказа в обслуживании целого сегмента Интернета. Инфраструктура УЦ становится новой целью для DDoS;
• увеличение затрат УЦ на поддержку инфраструктуры. УЦ требуется покупать каналы с большей пропускной способностью и обеспечивать защиту от DDoS;
• снижение надёжности TLS-соединений в нестабильных или зашумлённых сетях (например, мобильных сетях);
• увеличивается объём пересылаемого трафика и требуется большая полоса пропускания, что критично, опять же, для мобильных клиентов;
• проблемы использования OCSP вместе captive portal. Пароли, как правило, передаются поверх TLS, однако установить TLS-соединение и аутентифицироваться не получится, пока не были получены ответы от OCSP-серверов. Отправить же OCSP-запросы нельзя, поскольку OCSP-серверы (как минимум для сертификатов промежуточных УЦ), как правило, находятся в Интернете, и на этом этапе доступа к ним нет. Эта проблема может быть решена с помощью прикреплённых OCSP-ответов, однако проверка статуса промежуточных сертификатов на текущий момент всё равно требует отправки OCSP запросов, поскольку ни один браузер не поддерживает прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961).

При этом полного отказа от явного выполнения OCSP-запросов на стороне клиента не происходит, поскольку он всё ещё может защитить от «человека посередине» в случаях, когда он находится «близко» к серверу «далеко» от клиента, т.е., имеет доступ к TLS-трафику, но не может блокировать OCSP:

Что за печать доверия?

Печать доверия — это особый знак, позволяющий посетителям видеть, что соединение с вашим сайтом и все передаваемые данные надёжно защищены.

Существует два вида печатей: 

1. Статическая — изображение формата PNG, которое прилагается к сертификатам с проверкой домена. При клике по картинке пользователь попадает на страницу с информацией о сертификате.
2. Динамическая — такое же изображение, но без ссылки. При наведении курсора открывается встроенное окно с подробной информацией о компании и сертификате, защищающем сайт.

Когда посетитель видит печать SSL на сайте, он ещё раз убеждается, что соединение с ним надёжно защищено. Можно совершать покупки, денежные переводы и не беспокоиться, что данные перехватят мошенники. И раз доверие пользователей к сайту растёт, значит и конверсия повышается.

Что это за сертификат такой?

SSL-сертификат — это цифровая подпись сайта, которая нужна для работы протокола защищённой передачи данных в интернете. Аббревиатура SSL означает Secure Sockets Layer – протокол безопасности, создающий зашифрованное соединение между веб-сервером и веб-браузером.

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

Что за закон такой?

Это закон «О персональных данных». Если сайт собирает хотя бы минимальную информацию о пользователях, например ФИО или email, то он становится оператором персональных данных. Согласно закону такие сайты должны соблюдать множество правил по защите данных своих клиентов, и установка SSL-сертификата — одна из них.

Ок, понятно, что сертификат нужен. он один такой?

Нет, есть несколько видов SSL-сертификатов. 

Google chrome/cromium

Браузеры Google Chrome и Chromium версии 59 при проверке DV-сертификатов ведут себя следующим образом:

Проверки, выполняемые Chrome похожи, на те, что выполняет Firefox, с тем исключением, что в Chrome вообще отказались от выполнения OCSP-запросов при проверке DV-сертификатов. «CRLSets» в Chrome является аналогом «OneCRL» в Firefox (строго говоря, механизм «CRLSets» появился даже раньше) и обладает теми же проблемами неполноты и неподконтрольности конечному пользователю.

OCSP-запросы используются при проверке EV-сертификатов (тут картина становится практически идентичной той, что мы наблюдали для Firefox):

Как и другие браузеры, Chrome и Chromium работают в режиме soft fail. Прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961) и защита OCSP-ответов от атак повторного воспроизведения не поддерживаются.

Изменить поведение Chrome и Chromium возможно внесением изменений в групповую политику (инструкция здесь) и включением следующих опций:

Эквивалентная настройка возможна и под Linux (здесь).

После внесения этих изменений Chrome и Chromium будут выполнять проверки, аналогичные тем, что делает Internet Explorer (при отсутствии прикреплённых OCSP-ответов начнут выполнять OCSP-запросы с откатом на загрузку CRL для всей цепочки сертификатов), но в режиме hard ail, т.е., при недоступности OCSP-серверов и точек распространения CRL подключение будет запрещено:

Microsoft internet explorer/edge

Браузеры Microsoft Internet Explorer версии 11 и Microsoft Edge версии 40 ведут себя одинаково для DV- и EV-сертификатов:

В схеме, как и ранее, для простоты не показано взаимодействие с кэшем полученных ранее OCSP-ответов и CRL, хотя этому можно посвятить отдельную статью.

Для каждого проверяемого сертификата в цепочке при отсутствии прикреплённых OCSP-ответов выполняется OCSP-запрос. При этом Internet Explorer и Edge не поддерживают прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961) и не обеспечивают защиту OCSP-ответов от атак повторного воспроизведения. Если OCSP-сервер недоступен, то выполняется попытка загрузки CRL.

Проверка также выполняется в режиме soft fail. Таким образом, атака «человек посередине» также проходит успешно и также не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.

Изменить поведение Internet Explorer возможно, например, установив значение ключа реестра «HKEY_LOCAL_MACHINE SOFTWARE Microsoft Internet Explorer Main FeatureControl FEATURE_WARN_ON_SEC_CERT_REV_FAILED iexplore.exe» равным 1.

Для Edge подобных настроек не нашли.

Mozilla firefox

Поведение браузера Mozilla Firefox версии 54 (наиболее актуальной на момент написания статьи) при такой атаке отличается в зависимости от типа сертификата сервера: DV или EV. Выпуская DV-сертификат (domain validated), УЦ лишь подтверждает, что владелец ключа, указанного в сертификате, контролирует указанный в сертификате домен.

Большинство сертификатов являются DV. EV-сертификат (extended validation) подтверждает не только владение доменом, но и личность владельца домена. Такие сертификаты требуют дополнительных проверок со стороны УЦ, потому они значительно дороже и встречаются реже.

Проверка статуса DV-сертификатов, выполняемая Firefox, описывается следующей диаграммой:

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

Итак, браузер проверяет статус цепочки сертификатов сервера (сертификатов промежуточных УЦ и сертификата самого сервера). Для проверки статуса сертификатов промежуточных УЦ используется хранящуюся локально на клиенте черный список «OneCRL», содержащий информацию об отозванных сертификатах, собранную из различных точек распространения CRL.

1. Агрегатор периодически опрашивает некоторый набор точек распространения CRL.2. Из полученных CRL выбирает наиболее критичную информацию об отозванных сертификатах (например, сертификаты, отозванные из-за компрометации закрытого ключа).3. Обновляет на основе этой информации в чёрные списки в браузерах.

Агрегатор CRL и, как следствие, содержимое чёрного списка «OneCRL» контролируется Mozilla. «OneCRL» не покрывает все отозванные сертификаты, а лишь сертификаты некоторых промежуточных УЦ и небольшое количество сертификатов серверов. Это делается с целью сокращения размера чёрного списка. Текущий список «OneCRL» можно посмотреть тут.

Для проверки статуса сертификата сервера используется информация, полученная из «OneCRL», прикреплённых OCSP-ответов или ответов, полученных в результате выполнения OCSP-запроса. На диаграмме указана проверка наличия прикреплённого OCSP-ответа только для сертификата сервера, поскольку Firefox не поддерживает прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961).

Важно, что если ни один из источников информации о статусе сертификата не доступен, то сертификат не считается отозванным. Иначе говоря, проверка осуществляется в режиме soft fail. Таким образом, атака «человек посередине» проходит успешно. При этом не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.

В дополнение стоит отметить, что клиентская часть протокола OCSP, реализованная в Firefox, не поддерживает одноразовые случайные коды (nonce) и, следовательно, OCSP-ответы не защищены от атак повторного воспроизведения.

Аналогичная ситуация возникает и при проверке EV-сертификатов. Разница заключается лишь в том, что браузер дополнительно выполняет OCSP-запросы и для сертификатов промежуточных УЦ:

Изменить поведение браузера и включить режим hard fail (т.е., запрет установки TLS-соединения в случаях, когда информация о статусе сертификата недоступна) можно, установив в настройках браузера («about:config») параметр «security.OCSP.require» в значение «true»:

Следует отметить, что данная настройка не активирует использование протокола OCSP для сертификатов промежуточных УЦ в случаях, когда сервер предъявляет DV-сертификат.

Для конечного пользователя hard fail в Firefox выглядит так:

Отметим, что атака «человек посередине» всё ещё возможна!.. Нарушителю требуется провести атаку повторного воспроизведения OCSP-ответа, переслав «старый» OCSP-ответ, сгенерированный ещё до того, как сертификат был отозван. Однако проводить эту атаку можно только до тех пор, пока срок действия «старого» OCSP-ответа не истечёт. При этом срок действия OCSP-ответа может быть достаточно велик. Нередко он бывает равен неделе.

Ru-center – часто задаваемые вопросы о ssl-сертификатах

А зачем мне платить, если есть бесплатные сертификаты, которые выдают просто так?

Существует несколько видов бесплатных сертификатов. Есть такие проекты, как CloudFlare или LetsEncrypt, где можно получить сертификат бесплатно и самостоятельно. Такие сертификаты выпускаются всего на 3 месяца и далее требуют продления (иногда платного).

Но в их установке и использовании есть ряд минусов. Например, эти сертификаты не предусматривает печати доверия. Также сертификат Cloudflare  и выдаётся на 50 сайтов сразу, что несёт за собой риски безопасности. Если говорить о LetsEncrypt учтите, что сертификат поддерживается далеко не во всех браузерах.

Также просим вас сохранять бдительность. Если вы видите, что перед вами «крупный» сайт с бесплатным сертификатом — задумайтесь, довольно часто их выбирают мошенники, чтобы вызвать доверие пользователей. Мошенники вряд ли будут связываться с авторитетным УЦ да ещё и платить за то, что можно получить бесплатно.

А какие ещё есть плюсы от ssl для владельца сайта?

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

Например, большинство браузеров и поисковиков активно борются с незащищёнными сайтами. Например, компания Google понижает их в поисковой выдаче и отправляют специальные страницы-предупреждения на экран пользователя. 

Алгоритм выбора ssl-сертификата для сайта

Шаг 1. Определите особенности сайта

Шаг 2. Домен оформлен на физическое или юридическое лицо?

Шаг 3. Насколько крупный сайт?

Зачем тогда вообще нужны бесплатные ssl?

Эти сертификаты могут стать отличным решением в качестве тест-драйва с возможностью сэкономить на первый год. Например, на нашем сайте вы можете приобрести бесплатный SSL‑сертификат от GlobalSign вместе с доменом или хостингом на год — этого времени должно хватить для старта интернет-проекта, а по мере его роста можно перейти на платный тариф.

Как выдаётся сертификат

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

При получении сертификатов типа OV или EV, кроме указанных действий, потребуется пройти ряд дополнительных организационных процедур. О них подробно рассказано в нашей статье «Получение OV- и EV-сертификата — Что нужно знать?».

Самыми недорогими являются сертификаты типа DV. Они существенно дешевле сертификатов типа OV и, тем более, EV.

Как отсутствие ssl-сертификата повлияет на сайт?

Очень негативно. Фактически, сертификат сайта — его «паспорт» в интернете. Может ли гражданин полноценно существовать без паспорта?

Как работает ssl-сертификат

Данные между браузером посетителя и веб-сайтом проходят множество серверов и каналов связи. Чтобы эти данные не попали в чужие руки, они шифруются. Для этого каждой стороной применяется по паре цифровых ключей — длинных последовательностей символов. Один из них является открытым (публичным), а другой — секретным (частным).

Чтобы безопасно переслать данные веб-серверу, браузер шифрует их с помощью открытого ключа этого сервера. После получения зашифрованных данных сервер расшифровывает их своим секретным ключом.

При отправке данных браузеру всё происходит в зеркальном порядке. Сервер шифрует данные открытым ключом браузера, а после доставки данных они расшифровываются секретным ключом браузера.

Как установить ssl и сколько это стоит

Чтобы получить SSL — сертификат, нужно обратиться к хостинг — провайдеру. Этот протокол чаще всего заказывают из личного кабинета и стоит он от 2500 до 3000 тысяч. Можно найти как дешевле, так и дороже, в зависимости от тарифов хостинга и компаний, которые предоставляют услуги сертификации.

Позже мы расскажем вам, как получить и установить SSL-сертификат бесплатно. Установить его можно по инструкции, которую вы получаете при заказе. Часто все настройки проделываются через панели управления хостингом, такими как CPanel и ISPmanager. После того как вы проделаете последовательность установки, вам останется настроить сайт.

Как это работает?

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

Существует три типа сертификатов: «начальный», «бизнес» и «расширенного уровня». Какие они?

Какие есть перспективы?

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

hard fail

нельзя по объективным причинам.

Есть ли применимое на практике решение данной проблемы? Проанализировав и собрав воедино множество уже предложенных частичных решений данной проблемы (в частности расширение сертификатов «TLS feature», сертификаты с коротким сроком действия, агрегаторы CRL и др., о чём подробно будет рассказано ниже), предлагаем вашему вниманию наше представление о том, как проверка статуса сертификатов должна происходить на практике.

В основе лежит утверждение о том, что не для всех сервисов требуется онлайн-проверки статуса сертификатов. Для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски, связанные с атакой «человек посередине» с использованием отозванных сертификатов. Иначе говоря, с точки зрения проверки статуса сертификатов, сервисы делятся на два типа:

1. Меньшинство, для которого будут проводиться строгие онлайн-проверки статуса сертификатов в режиме hard fail.2. Большинство, для которого онлайн-проверки статуса сертификатов не будут выполняться вовсе (будут предприниматься другие меры по защите).

Браузеры могут различать такие сервисы по наличию специального расширения в сертификате сервера. В зависимости от типа сервиса клиент либо будет выполнять «параноидальную» проверку статуса сертификатов, либо не будет выполнять её вовсе. Теперь подробнее о каждой из этих двух схем.

Параноидальная схема проверки статуса сертификатов для меньшинства

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

(на ранних этапах разработки стандарта также известное, как «OCSP must staple»). Это расширение сертификата позволяет зафиксировать в сертификате те опции протокола TLS, которые TLS-сервер, предъявляющий данный сертификат, обязуется поддерживать. Такой опцией протокола TLS в частности являются прикреплённые OCSP-ответы. Пример сертификата с таким расширением схематически изображён ниже:

В сертификате присутствует расширение «TLS Feature» (выделено красным), сообщающее о том, что TLS-сервер обязан поддерживать прикреплённые OCSP-ответы, специфицированные в RFC 6066 («Status Request (Version 1)»), и более новую версию данной опции («Status Request (Version 2)»), специфицированную в RFC 6961 — множественные прикреплённые OCSP-ответы. Новая версия данной опции протокола TLS позволяет прикреплять OCSP-ответы и для сертификатов промежуточных УЦ.

Проверки статуса сертификатов, реализованные в веб-браузерах

Механизмы проверки статуса сертификатов, реализованные в современных Веб браузерах, представляют собой комбинацию описанных

базовых механизмов (CRL, OCSP, OCSP stapling) и их модификаций. Комбинирование базовых механизмов осуществляется с целью обеспечения резервирования: если один из источников информации о статусе сертификата становится недоступным, то используется резервный.

Для понимания основной проблемы проверок статуса сертификатов, реализованных в современных браузерах, достаточно рассмотреть следующий сценарий атаки «человек посередине».

Закрытый ключ сервера был скомпрометирован. Владелец сервера отозвал сертификат скомпрометированного ключа, сгенерировал новую пару ключей и получил новый сертификат.Нарушитель завладел отозванным закрытым ключом и сертификатом сервера. В данном сценарии мы намеренно не говорим, каким образом он это осуществил: в результате компрометации самого сервера или в результате компрометации удостоверяющего центра (УЦ). Это сделано для того, чтобы продемонстрировать, как браузеры поведут себя в обеих ситуациях.

Нарушитель, «человек посередине», контролирует весь трафик, идущий от клиента. Он может перехватывать или блокировать этот трафик, может пытаться отвечать клиенту от имени других сетевых сервисов.

Веб-браузер клиента при попытке установки TLS-соединения с сервером подключается к «человеку посередине». «Человек посередине» представляется сервером, используя отозванный сертификат без прикреплённого OCSP-ответа (a.k.a. OCSP stapling).

Нарушитель блокирует запросы, идущие от клиента ко всем OCSP-серверам и точкам распространения CRL (a.k.a. CDP). Также нарушитель блокирует попытки клиента обновить Веб-браузер или его компоненты (например, чёрные списки «CRLSets» или «OneCRL», речь о которых пойдёт позже).

Блокирование «человеком посередине» запросов ко всем OCSP-серверам и точкам распространения CRL, во-первых, поддерживает начальное условие, согласно которому нарушитель мог скомпрометировать, как сервер, так и УЦ, и, во-вторых, наиболее полно демонстрирует проверки статуса сертификатов, выполняемые современными браузерами.

Ниже приводится описание проверок статуса сертификатов, выполняемых различными Веб-браузерами под Windows. Для других платформ детали проверок могут незначительно отличаться.

Прочие браузеры и платформы

Для других популярных браузеров и платформ ситуация такая же: везде проверки статуса сертификатов выполняются в режиме

soft fail

, либо не выполняются вовсе. Подробнее можно почитать

или

Схема для большинства

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

hard fail

, не окупают риски связанные с атакой «человек посередине» с использованием отозванных сертификатов. В таком случае лучше не защищаться от данной атаки, а максимально сократить временной промежуток, в течение которого проведение данной атаки будет возможным. Для этого используются сертификаты с коротким сроком действия (например, 1-2 дня).

Таким образом, большинство сервисов будет использовать сертификаты без расширения «TLS Feature», но с коротким сроком действия. Для таких сертификатов онлайн-проверки статуса сертификатов не будут выполняться вовсе. Вместо этого будет проводиться частое обновление быстро устаревающих сертификатов.

Добавим, что использование сертификатов с коротким сроком действия эквивалентно использованию сертификатов с расширением «TLS Feature», обязывающим использовать прикреплённые OCSP-ответы, вместе с прикреплёнными OCSP-ответами, не защищёнными от атаки повторного воспроизведения (т.е.

Подход с использованием сертификатов с коротким сроком действия обладает целым рядом достоинств, однако малопригоден для сертификатов УЦ. Для проверки статуса таких сертификатов можно использовать периодически обновляемые чёрные списки аналогичные «CRLSets» и «OneCRL», но предоставляющие пользователям больший контроль на агрегаторами CRL.

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

Так, а где можно получить ssl-сертификат?

Здесь тоже всё просто — в специальных удостоверяющих центрах. Эти центры подтверждают подлинность ключей шифрования с помощью сертификатов электронной подписи. Возможно вы уже встречали такие названия таких УЦ, как: GlobalSign, Symantec, Comodo, Thawte, GeoTrust, DigiCert.

Типы сертификатов.

Допустим, руководствуясь соображениями из 1 части статьи вы решили купить подписанный сертификат. Каково же будет ваше удивление, когда на сайте ЦС вы узнаеете, что они бывают разные 🙂

Типы сертификатов:

Esential SSL — самый не дорогой и быстро оформляемый сертификат. Доступен как для юридических, так и для физических лиц. Проверяется только право владения доменным именем, личные данные или регистрация компании не проверяются. Выдается на 1 домен.

Instant SSL — доступен и для физ. лиц, и для юр. лиц. Проверяется право владения доменом, регистрационные данные компании либо личность физ. лица. Выдается на 1 домен.

SGC SSL-сертификат. — Аналогично Instant SSL, но с поддержкой 40-битных расширений (актуально для старых ОС и браузеров). Выдается на 1 домен, либо wildcard (см. ниже).

То есть такие защищённые сайты не могут взломать хакеры?

SSL защищают сайт от перехвата информации, которой пользователь обменивается с сайтом. А ещё некоторые SSL-сертификаты подтверждают (OV и ЕV), что посетитель веб-ресурса имеет дело с авторизованным сайтом, который принадлежит определённому владельцу.

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

• доменное имя, на которое оформлен SSL-сертификат;
• юридическое лицо, которое владеет сертификатом.

Заключение

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

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