Как проверить сертификат сайта в браузере
Тем не менее, просто получая рабочий один только открытый ключ не гарантирует, что он (и, соответственно, сервер) действительно принадлежит правильному удаленному предмет (т.е. человек, компания или организация). Человек-в-середине злоумышленники могут манипулировать сетями для обслуживания своих собственных ключей, тем самым подвергая риску любую связь
Эти доверительные отношения означают, что безопасность веб-пользователей не является абсолютной; скорее, он требует, чтобы пользователи доверяли браузерам и центрам сертификации для защиты своей безопасности. Поэтому мы считаем, что в интересах каждого пользователя иметь базовое представление о том, как работает проверка сертификатов.
Обратите внимание, что процесс проверки сертификата (подробно описан в стандартном документе RFC 5280) довольно запутанный. В этой статье мы попытаемся провести вас по одному пути (браузер, проверяющий SSL хоста /TLS сертификат) и перемещаться мимо сложных деталей, которые несущественны для большинства пользователей.
Сертификаты и формат X.509
Сертификаты являются цифровыми файлами во всех отношениях, что означает, что они должны следовать формату файла для хранения информации (например, подписи, ключи, эмитенты и т. Д.). Пока приватный PKI конфигурации могут реализовывать любой формат для своих сертификатов, пользующихся всеобщим доверием PKIs (то есть те, которым доверяют браузеры) должны соответствовать RFC 5280, который требует использования Х.509 v3 формат.
X.509 v3 позволяет сертификатам включать дополнительные данные, такие как ограничения использования или информацию о политике, как расширенияс каждым расширением либо критический or не критичный, Браузеры могут игнорировать недопустимые или нераспознанные некритические расширения, но они должны обрабатывать и проверять все критические расширения.
Пути сертификации и обработка пути
Центры сертификации используют закрытый ключ для криптографической подписи всех выданных сертификатов. Такие подписи могут безоговорочно доказать, что сертификат был выдан конкретным центром сертификации и что он не был изменен после его подписания.
Центры сертификации устанавливают права собственности на свой подписывающий ключ, имея сертификат, выданный самостоятельно (называемый корень) для соответствующего открытого ключа. ЦС должны соблюдать строго контролируемые и проверенные процедуры для создания, управления и использования корня, а для минимизации подверженности обычно используют корень для выпуска промежуточный сертификаты. Эти промежуточные звенья могут затем использоваться для выдачи сертификатов их клиентов.Браузеры поставляются со встроенным списком доверенных корней. (Это корни из центров сертификации, которые прошли строгие критерии включения браузера.) Чтобы проверить сертификат, браузер получит последовательность сертификатов, каждый из которых подписал следующий сертификат в последовательности, соединяя корень подписывающего CA с сервером. сертификат.
Эта последовательность сертификатов называется путь сертификации. Корень пути называется доверять якорь а сертификат сервера называется лист or конечный объект сертификат.
Путь Строительство
Часто браузерам приходится рассматривать несколько путей сертификации, пока они не найдут действительный для данного сертификата. Несмотря на то, что путь может содержать сертификаты, которые должным образом «связываются» вместе с известным якорем, сам путь может быть отклонен из-за ограничений на длину пути, имя домена, использование сертификата или политику.
Создание и оценка всех возможных путей - это дорогостоящий процесс, выполняемый для каждого нового сертификата, с которым сталкивается браузер. Браузеры реализовали различные оптимизации, чтобы минимизировать количество отклоненных возможных путей, но углубление в такие детали выходит далеко за рамки этой статьи.
Проверка пути
После создания пути сертификации кандидата браузеры проверяют его, используя информацию, содержащуюся в сертификатах. Путь действителен, если браузеры могут криптографически доказать, что, начиная с сертификата, непосредственно подписанного якорем доверия, соответствующий закрытый ключ каждого сертификата использовался для выдачи следующего в пути, вплоть до конечного сертификата.
Алгоритм валидации пути сертификации
RFC 5280 описывает стандартный алгоритм что браузеры следуют, чтобы проверить путь сертификации сертификатов X.509.
Как правило, браузеры перебирают все сертификаты в пути, начиная с якоря доверия (т. Е. Корневого сертификата), проверяя основную информацию и критические расширения каждого сертификата.
Если процедура завершается с последним сертификатом в пути без ошибок, то путь считается допустимым. Если возникают ошибки, путь помечается как неверный.
Основная обработка сертификата
Независимо от каких-либо расширений, браузеры должны всегда проверять основную информацию о сертификате, такую как подпись или издатель. В следующих разделах показана последовательность проверок, выполняемых браузерами.
1. Браузер проверяет целостность сертификата.
подпись На сертификате можно проверить с помощью обычной криптографии с открытым ключом. Если подпись недействительна, то сертификат считается измененным после его выдачи и поэтому отклоняется.
2. Браузер проверяет действительность сертификата.
Сертификат срок годности это интервал времени, в течение которого подписывающий центр сертификации гарантирует, что он будет хранить информацию о своем статусе. Браузеры отклоняют любые сертификаты с периодом действия, заканчивающимся до или начинающимся после даты и времени проверки.
3. Браузер проверяет статус отзыва сертификата.
Ожидается, что после выдачи сертификата он будет использоваться в течение всего срока его действия. Конечно, различные обстоятельства могут привести к тому, что сертификат станет недействительным до истечения срока его действия.
Такие обстоятельства могут включать изменение имени субъекта или предполагаемую компрометацию его закрытого ключа. В таких случаях ЦС должен отозвать соответствующий сертификат, и пользователи также доверяют ЦС, чтобы уведомить браузеры о статусе отзыва своих сертификатов.
RFC 5280 рекомендует ЦС использовать списки отзыва для этой цели.
Списки отзыва сертификатов (CRL)
Центры сертификации периодически выпускают подписанный список отозванных сертификатов с отметкой времени, который называется список отзыва сертификатов (CRL). CRL распространяются в общедоступных репозиториях, и браузеры могут получать и просматривать последний CRL CA при проверке сертификата.
Одним из недостатков этого метода является то, что детализация отзыва по времени ограничена периодом выдачи CRL. Браузер будет уведомлен об отзыве только после того, как запланировано обновление всех выпущенных в настоящее время CRL. В зависимости от политики подписывающего ЦС это может занять час, день или даже неделю.
Протокол статуса сертификата онлайн (OCSP)
Существуют и другие альтернативные способы получения информации о статусе отзыва, наиболее популярным из которых является Протокол статуса сертификата онлайн (ОМТП).
Описано в стандартном документе RFC6960, OCSP позволяет браузеру запрашивать статус отзыва определенного сертификата с онлайн-сервера OCSP (также называемого отвечать). При правильной настройке OCSP намного быстрее и позволяет избежать проблемы задержки обновления CRL, упомянутой выше. К тому же, OCSP Stapling улучшает производительность и скорость.
4. Браузер проверяет эмитента
Сертификаты обычно связаны с двумя объектами:
- эмитент, который является лицом, владеющим ключом подписи и
- предмет, который ссылается на владельца открытого ключа, который подтверждает подлинность сертификата.
Браузеры проверяют, что сертификат эмитент поле такое же, как предмет поле предыдущего сертификата в пути. Для дополнительной безопасности большинство PKI реализации также проверяют, что ключ издателя совпадает с ключом, подписавшим текущий сертификат. (Обратите внимание, что это неверно для якоря доверия, поскольку корни выдаются самостоятельно, т. Е. Имеют одного и того же эмитента и субъекта.)
Обработка ограничений
Формат X.509 v3 позволяет ЦС определять ограничения или ограничения на проверку каждого сертификата и его использование в качестве критических расширений. Каждый сертификат в пути может налагать дополнительные ограничения, которым должны подчиняться все последующие сертификаты.
Ограничения сертификатов редко влияют на обычного пользователя Интернета, хотя они довольно часто встречаются в корпоративных решениях SSL. Функциональные ограничения могут служить нескольким рабочим целям, но их наиболее важное использование - смягчение известных проблем безопасности.
5. Браузер проверяет ограничения имени
6. Браузер проверяет ограничения политики
Политика сертификатов - это юридический документ, опубликованный центром сертификации, в котором подробно описываются процедуры, которым они следуют при выдаче и управлении своими сертификатами. Центры сертификации могут выдавать сертификат в соответствии с одной или несколькими политиками, и ссылки на них включены в каждый выпущенный сертификат, чтобы проверяющие стороны могли оценить эти политики, прежде чем принять решение о доверии этому сертификату.
По юридическим и эксплуатационным причинам сертификаты могут накладывать ограничения на политику, которой они могут подвергаться. Если сертификат содержит критические ограничения политики, браузеры должны проверить их, прежде чем продолжить. (Однако критические политические ограничения редко встречаются в реальном мире и поэтому будут игнорироваться до конца этой статьи.)
7. Браузер проверяет основные ограничения (длина пути)
Формат X.509 v3 позволяет издателям определять максимальную длину пути, которую может поддерживать сертификат. Это обеспечивает контроль над тем, как далеко каждый сертификат может быть помещен в путь сертификации. Это действительно важно - браузеры игнорировали длину пути сертификации, пока исследователь не продемонстрировал в 2009 г. презентация, как он использовал листовой сертификат своего веб-сайта, чтобы подделать действительный сертификат для большого веб-сайта электронной коммерции.
8. Браузер проверяет использование ключа
Расширение «использование ключа» указывает назначение ключа, содержащегося в сертификате. Примеры таких целей включают шифрование, подписи, подписание сертификата и так далее. Браузеры отклоняют сертификаты, нарушая ограничения их использования ключа, например обнаруживая сертификат сервера с ключом, предназначенным только для подписи CRL.
9. Браузер продолжает обрабатывать все оставшиеся критические расширения
После обработки упомянутых выше расширений браузеры приступают к проверке всех оставшихся расширений, которые текущий сертификат определяет как критические, прежде чем перейти к следующему. Если браузер достигает конечного сертификата пути без ошибок, то путь считается действительным. Если возникают какие-либо ошибки, путь помечается как недопустимый и безопасное соединение не устанавливается.
Заключение
Проверяйте SSL, TLS и шифрование
Проверка SSL необходима для обеспечения правильного отображения параметров сертификата. Существует множество способов проверки SSL-сертификатов. Проверка с помощью инструментов в сети позволяет получить полезную информацию, находящуюся ниже. Она также поможет вам выявить угрозы на ранних стадиях, а не после получения жалобы клиента.
Я получил ряд вопросов после своей последней публикации «Усиление защиты Apache. Гид по безопасности» о проверке TLS и SSL. В этой статье я расскажу вам о некоторых полезных инструментах для проверки SSL-сертификатов в сети.
Symantec SSL Toolbox
Проверка CSR — очень важно проверить CSR перед отправкой для подписи запроса. Вы сможете удостовериться в том, что CSR содержит все требуемые параметры, например, CN, DN, O, OU, алгоритм и др.
Проверка установки сертификата — после установки всегда полезно удостовериться в том, что сертификат действителен и содержит необходимую информацию. Этот онлайн инструмент позволит вам проверить CN, SAN, название организации, OU, город, серийный номер, тип применяемого алгоритма, длину ключа и подробности о цепочке сертификата.
Wormly Web Server Tester
Тестирование web сервера от Wormly позволяет получить подробный обзор параметров ссылки. Обзор включает в себя данные о сертификате (CN, срок действия, цепочка сертификата), шифровании, длине открытого ключа, безопасности повторного согласования, протоколах типа SSLv3/v2, TLSv1/1.2.
DigiCert SSL Certificate Checker
Инструмент для проверки установки SSL сертификатов от DigiCert — еще один прекрасный инструмент, который позволит вам преобразовать DNS в IP адрес, узнать кто выдал сертификат, его серийный номер, длину ключа, алгоритм подписи, SSL-шифрование, поддерживаемое сервером и срок действия сертификата.
SSL Shopper
Проверка SSL от SSL Shopper — подойдет для быстрой проверки типа сервера, срока действия, SAN и цепочки доверия. Вы сможете оперативно найти ошибку в цепочке сертификата или узнать, что он не работает должным образом. Инструмент отлично подходит для устранения неполадок в работе.
GlobalSign SSL Check
Проверка конфигурации SSL от GlobalSign предоставляет очень подробную информацию о веб-сервере и SSL. Инструмент ставит баллы в зависимости от данных сертификата, поддержки протоколов, обмена ключами и надёжности шифра. Это незаменимый инструмент при настройке нового безопасного URL или проведении аудита. Обязательно попробуйте!
Qualys SSL Labs
Позволяет оценить ваш сайт в отношении безопасности SSL-сертификата. Предоставляет очень подробную техническую информацию. Советую системным администраторам, аудиторам, инженерам по интернет-безопасности для выявления и наладки “слабых” параметров.
Free SSL Server Test
- Совместимость PCI DSS
- Соответствие принципам NIST
- Размер DH
- Поддержка протоколов
- Поддержка шифров
- Откат TLS соединения
- Поддержка повторного согласования
- Основные наборы шифров
- Контент третьих лиц
COMODO SSL Analyzer
- Серийный номер
- Отпечаток
- Действительность SSL-сертификата
- Эмитент
- Поддержка протокола (SSL/TLS)
- Защита от атак Downgrade
- Безопасность повторного согласования (по инициативе сервиса или клиента)
- Сжатие
- Session tickets
- Активные наборы шифрования
SSL Checker
Что действительно хорошо в SSL Checker, так это то, что инструмент позволяет настроить напоминание (за 30 дней) об истечении срока действия сертификата. Это отлично, мне кажется, что бесплатно эту услугу больше нигде получить нельзя. Кроме того, инструмент позволяет выполнить базовую проверку таких параметров, как:
- Цепочка сертификата
- Корневой сертификат
- Алгоритм подписи
- Отпечаток
- Элементы цепочки
- SAN
HowsMySSL
Этот инструмент отличается от остальных. Он позволяет проверить клиента (браузер) и получить оценку состояния по следующим параметрам:
- Поддерживаемая версия протокола
- Сжатие
- Поддержка session ticket
- Поддерживаемое шифрование
Другие инструменты онлайн-проверки
Проверка уязвимости POODLE:
Проверка уязвимости LogJam:
Проверка уязвимости SHA-1:
Я считаю, что перечислил все бесплатные онлайн-инструменты для проверки параметров SSL-сертификата и получения достоверной технической информации для проведения аудита и обеспечения безопасности веб-приложений. Если вам понравилось, поделитесь с друзьями.
P. S. Приглашаем в наше Хостинг Кафе. Работают и активно развиваются 6 сайтов для поиска хостинговых услуг:
В нашей предыдущей статье были описаны основные механизмы проверки статуса сертификатов (проверки, является ли сертификат отозванным). В этой статье мы ответим на следующие вопросы:
1. Как механизмы проверки статуса сертификатов реализованы в современных Веб-браузерах?
2. Кто виноват? Почему они реализованы именно так?
3. Что делать? Какие есть перспективы?
Эта статья будет полезна тем, кому интересно разобраться в применяющихся на практике механизмах проверки статуса сертификатов.
Проверки статуса сертификатов, реализованные в Веб-браузерах
Механизмы проверки статуса сертификатов, реализованные в современных Веб браузерах, представляют собой комбинацию описанных ранее базовых механизмов (CRL, OCSP, OCSP stapling) и их модификаций. Комбинирование базовых механизмов осуществляется с целью обеспечения резервирования: если один из источников информации о статусе сертификата становится недоступным, то используется резервный. Например, в качестве основного механизма проверки статуса сертификатов может использоваться протокол OCSP, однако в случае недоступности или отказа OCSP-сервера будет выполнена более трудоёмкая для клиента загрузка CRL.
Для понимания основной проблемы проверок статуса сертификатов, реализованных в современных браузерах, достаточно рассмотреть следующий сценарий атаки «человек посередине».
Закрытый ключ сервера был скомпрометирован. Владелец сервера отозвал сертификат скомпрометированного ключа, сгенерировал новую пару ключей и получил новый сертификат.
Нарушитель завладел отозванным закрытым ключом и сертификатом сервера. В данном сценарии мы намеренно не говорим, каким образом он это осуществил: в результате компрометации самого сервера или в результате компрометации удостоверяющего центра (УЦ). Это сделано для того, чтобы продемонстрировать, как браузеры поведут себя в обеих ситуациях.
Нарушитель, «человек посередине», контролирует весь трафик, идущий от клиента. Он может перехватывать или блокировать этот трафик, может пытаться отвечать клиенту от имени других сетевых сервисов.
Веб-браузер клиента при попытке установки TLS-соединения с сервером подключается к «человеку посередине». «Человек посередине» представляется сервером, используя отозванный сертификат без прикреплённого OCSP-ответа (a.k.a. OCSP stapling). Нарушитель блокирует запросы, идущие от клиента ко всем OCSP-серверам и точкам распространения CRL (a.k.a. CDP). Также нарушитель блокирует попытки клиента обновить Веб-браузер или его компоненты (например, чёрные списки «CRLSets» или «OneCRL», речь о которых пойдёт позже).
Блокирование «человеком посередине» запросов ко всем OCSP-серверам и точкам распространения CRL, во-первых, поддерживает начальное условие, согласно которому нарушитель мог скомпрометировать, как сервер, так и УЦ, и, во-вторых, наиболее полно демонстрирует проверки статуса сертификатов, выполняемые современными браузерами.
Ниже приводится описание проверок статуса сертификатов, выполняемых различными Веб-браузерами под Windows. Для других платформ детали проверок могут незначительно отличаться.
Mozilla Firefox
Поведение браузера Mozilla Firefox версии 54 (наиболее актуальной на момент написания статьи) при такой атаке отличается в зависимости от типа сертификата сервера: DV или EV. Выпуская DV-сертификат (domain validated), УЦ лишь подтверждает, что владелец ключа, указанного в сертификате, контролирует указанный в сертификате домен. Большинство сертификатов являются DV. EV-сертификат (extended validation) подтверждает не только владение доменом, но и личность владельца домена. Такие сертификаты требуют дополнительных проверок со стороны УЦ, потому они значительно дороже и встречаются реже.
Проверка статуса DV-сертификатов, выполняемая Firefox, описывается следующей диаграммой:
Итак, браузер проверяет статус цепочки сертификатов сервера (сертификатов промежуточных УЦ и сертификата самого сервера). Для проверки статуса сертификатов промежуточных УЦ используется хранящуюся локально на клиенте черный список «OneCRL», содержащий информацию об отозванных сертификатах, собранную из различных точек распространения CRL. Актуальность состояния чёрного списка поддерживается с помощью агрегатора CRL, отдельного удалённого сервиса, работающего следующим образом:
1. Агрегатор периодически опрашивает некоторый набор точек распространения CRL.
2. Из полученных CRL выбирает наиболее критичную информацию об отозванных сертификатах (например, сертификаты, отозванные из-за компрометации закрытого ключа).
3. Обновляет на основе этой информации в чёрные списки в браузерах.
Агрегатор CRL и, как следствие, содержимое чёрного списка «OneCRL» контролируется Mozilla. «OneCRL» не покрывает все отозванные сертификаты, а лишь сертификаты некоторых промежуточных УЦ и небольшое количество сертификатов серверов. Это делается с целью сокращения размера чёрного списка. Текущий список «OneCRL» можно посмотреть тут.
Важно, что если ни один из источников информации о статусе сертификата не доступен, то сертификат не считается отозванным. Иначе говоря, проверка осуществляется в режиме 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-ответа может быть достаточно велик. Нередко он бывает равен неделе.
Microsoft Internet Explorer/Edge
Браузеры Microsoft Internet Explorer версии 11 и Microsoft Edge версии 40 ведут себя одинаково для DV- и EV-сертификатов:
Проверка также выполняется в режиме soft fail. Таким образом, атака «человек посередине» также проходит успешно и также не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.
Изменить поведение Internet Explorer возможно, например, установив значение ключа реестра «HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Internet Explorer \ Main \ FeatureControl \ FEATURE_WARN_ON_SEC_CERT_REV_FAILED \ iexplore.exe» равным 1. Тогда при отсутствии информации о статусе сертификата соединение всё равно будет разрешено, однако в адресной строке будет появляться небольшое предупреждение:
Для Edge подобных настроек не нашли.
Google Chrome/Cromium
Браузеры Google Chrome и Chromium версии 59 при проверке DV-сертификатов ведут себя следующим образом:
Проверки, выполняемые Chrome похожи, на те, что выполняет Firefox, с тем исключением, что в Chrome вообще отказались от выполнения OCSP-запросов при проверке DV-сертификатов. «CRLSets» в Chrome является аналогом «OneCRL» в Firefox (строго говоря, механизм «CRLSets» появился даже раньше) и обладает теми же проблемами неполноты и неподконтрольности конечному пользователю.
OCSP-запросы используются при проверке EV-сертификатов (тут картина становится практически идентичной той, что мы наблюдали для Firefox):
Изменить поведение Chrome и Chromium возможно внесением изменений в групповую политику (инструкция здесь) и включением следующих опций:
Эквивалентная настройка возможна и под Linux (здесь).
Прочие браузеры и платформы
Для других популярных браузеров и платформ ситуация такая же: везде проверки статуса сертификатов выполняются в режиме soft fail, либо не выполняются вовсе. Подробнее можно почитать тут или тут.
Почему сейчас всё работает именно так?
Об этом хорошо написано в блоге Адама Лэнгли. Отсутствие hard fail и отказ от явного выполнения OCSP-запросов на стороне клиента обусловлены следующими факторами:
Какие есть перспективы?
Очевидный вывод из всего сказанного ранее: проверки статуса сертификатов в браузерах не работают, и это не новость. При этом просто взять и перейти на hard fail нельзя по объективным причинам.
Есть ли применимое на практике решение данной проблемы? Проанализировав и собрав воедино множество уже предложенных частичных решений данной проблемы (в частности расширение сертификатов «TLS feature», сертификаты с коротким сроком действия, агрегаторы CRL и др., о чём подробно будет рассказано ниже), предлагаем вашему вниманию наше представление о том, как проверка статуса сертификатов должна происходить на практике.
В основе лежит утверждение о том, что не для всех сервисов требуется онлайн-проверки статуса сертификатов. Для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски, связанные с атакой «человек посередине» с использованием отозванных сертификатов. Иначе говоря, с точки зрения проверки статуса сертификатов, сервисы делятся на два типа:
1. Меньшинство, для которого будут проводиться строгие онлайн-проверки статуса сертификатов в режиме hard fail.
2. Большинство, для которого онлайн-проверки статуса сертификатов не будут выполняться вовсе (будут предприниматься другие меры по защите).
Браузеры могут различать такие сервисы по наличию специального расширения в сертификате сервера. В зависимости от типа сервиса клиент либо будет выполнять «параноидальную» проверку статуса сертификатов, либо не будет выполнять её вовсе. Теперь подробнее о каждой из этих двух схем.
Параноидальная схема проверки статуса сертификатов для меньшинства
В 2015 году вышла спецификация нового расширения сертификатов стандарта X.509, называемого «TLS feature» (на ранних этапах разработки стандарта также известное, как «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-ответы и для сертификатов промежуточных УЦ.
Поскольку мы строим «параноидальную» схему проверки статуса сертификатов, то в дополнение к использованию сертификатов с расширением «TLS Feature», следует также отметить следующее:
1. Прикреплённые OCSP-ответы должны быть защищены от атаки повторного воспроизведения (должны использоваться случайные одноразовые коды). Даже при использовании сертификатов с таким расширением у нарушителя остаётся окно для атаки, определяемое сроком действия OCSP-ответа: всё ещё возможно провести атаку повторного воспроизведения и прислать клиенту старый OCSP-ответ, полученный ещё до того как сертификат был отозван.
2. Должна использоваться опция «Status Request (Version 2)». Эта опция позволяет прикреплять OCSP-ответы для всех сертификатов в цепочке, а не только для сертификата сервера. Это позволяет вовсе отказаться от явного выполнения OCSP-запросов на стороне клиента и всех присущих ему и описанных ранее недостатков.
Итак, в сухом остатке, «параноидальная» схема проверки статуса сертификатов основана на следующем:
- TLS-сервер использует сертификат с расширением «TLS Feature», обязывающем сервер поддерживать опции протокола TLS «Status Request (Version 1)» и «Status Request (Version 2)»;
- TLS-клиент и TLS-сервер должны использовать прикреплённые OCSP-ответы, защищённые случайными одноразовыми кодами от атаки повторного воспроизведения;
- если TLS-клиент поддерживает опцию «Status Request (Version 1)», но не поддерживает опцию «Status Request (Version 2)», то получив от сервера сертификат с расширением «TLS Feature», он должен явно выполнить OCSP-запросы (с использованием случайных одноразовых кодов) для сертификатов промежуточных УЦ в режиме hard fail.
- увеличение нагрузки на OCSP-серверы УЦ;
- уязвимость к DDoS атакам на серверы УЦ.
В качестве решения второй проблемы на сервере можно попеременно использовать несколько сертификатов, выпущенных независимыми УЦ. В таком случае пока OCSP-серверы одного УЦ будут «лежать» из-за DDoS, TLS-сервер будет использовать альтернативный сертификат, выпущенный другим УЦ, не находящимся под атакой. Использование нескольких сертификатов также позволит балансировать нагрузку между УЦ.
Для того, чтобы оценить, насколько клиентская сторона (под Windows) готова к переходу в светлое будущее, можно взглянуть на следующую таблицу:
Схема для большинства
Как было сказано ранее, для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски связанные с атакой «человек посередине» с использованием отозванных сертификатов. В таком случае лучше не защищаться от данной атаки, а максимально сократить временной промежуток, в течение которого проведение данной атаки будет возможным. Для этого используются сертификаты с коротким сроком действия (например, 1-2 дня).
Таким образом, большинство сервисов будет использовать сертификаты без расширения «TLS Feature», но с коротким сроком действия. Для таких сертификатов онлайн-проверки статуса сертификатов не будут выполняться вовсе. Вместо этого будет проводиться частое обновление быстро устаревающих сертификатов.
Добавим, что использование сертификатов с коротким сроком действия эквивалентно использованию сертификатов с расширением «TLS Feature», обязывающим использовать прикреплённые OCSP-ответы, вместе с прикреплёнными OCSP-ответами, не защищёнными от атаки повторного воспроизведения (т.е. OCSP-ответами, кэшируемыми на стороне TLS-сервера). При этом сертификаты с коротким сроком действия чуть более эффективны с точки зрения экономии трафика и количества операций, необходимых для проверки сертификата.
Подход с использованием сертификатов с коротким сроком действия обладает целым рядом достоинств, однако малопригоден для сертификатов УЦ. Для проверки статуса таких сертификатов можно использовать периодически обновляемые чёрные списки аналогичные «CRLSets» и «OneCRL», но предоставляющие пользователям больший контроль на агрегаторами CRL. Пользователи, например, должны иметь возможность добавлять новые опрашиваемые точки распространения CRL. Это важно, поскольку некоторые организации разворачивают собственные не публичные УЦ для внутреннего использования. Решением может стать возможность использования приватных агрегаторов CRL. При этом понадобится разработать открытый протокол взаимодействия клиента и агрегатора CRL, обеспечивающий совместимость клиентов и агрегаторов различных вендоров.
Итог
Что ж, пока что всё не очень хорошо: проверки статуса сертификатов в современных браузерах действительно не работают.
Однако свет в конце тоннеля всё же есть, и ситуация постепенно, хотя и медленно, движется к лучшему.
Когда мы используем интернет для поиска информации, покупки вещей или бронирования билетов на самолет, мы никогда не задумываемся о безопасности сайта и защите своих данных. Да и зачем это, если перед глазами популярный сервис, который давно себя зарекомендовал.
Другое дело, когда спустя сотню запросов мы находим нужную вещь для покупки, но она расположена на сомнительном ресурсе. И тут уже возникает вопрос: «А не будет ли мне это стоить всего моего состояния?». Давайте разберемся, как уберечь себя от потери личных данных и проверить сайт на наличие SSL и TLS сертификатов.
Сертификаты SSL и TLS: зачем они нужны
Продолжим разбор ситуации с покупкой чего-либо через интернет: представим себе, что мы собрались полететь на солнечное Бали из Москвы. Мы нашли сайт, который не представляет собой ничего подозрительного, и поэтому спокойно вводим на нем все необходимые данные и бронируем билеты на самолет.
В то время, когда на сайте совершается оплата за выбранные билеты, начинают срабатывать сертификаты защиты. Их еще называют SSL и TLS, но они представляют собой развитие одной технологии.
SSL расшифровывается как Secure Socket Layer, что означает «уровень защищенных сокетов». TLS же обозначается как Transport Layer Security, «безопасность транспортного уровня». По своей сути обе технологии занимаются одним делом – защитой пользовательской информации от злоумышленников.
Их отличие состоит лишь только в том, что TLS основан на уже действующей спецификации SSL 3.0. А сам SSL уже давно устарел, разработчики редко его используют как единственную защиту. Чаще всего можно увидеть связку двух сертификатов SSL/TLS. Такая поддержка обеспечивает работу как с новыми, так и со старыми устройствами.
Специфика работы сертификатов SSL/TLS
Вернемся к ситуации с покупкой билетов на сайте. Как мы выяснили, при отправке личных данных начинают действовать сертификаты. Но что происходит, если защита не производится должным путем?
SSL/TLS используют ассиметричное шифрование для аутентификации пользователя и симметричное для сохранения целостности личной информации.
Как проверить сертификаты SSL/TLS
Мы рассмотрим 5 наиболее популярных онлайн-инструментов для обнаружения слабых мест веб-сайта. Что ж, давайте приступим.
SeoLik
Начнем с отечественного онлайн-сервиса, который позиционирует себя как инструмент для проверки надежности сайта. Помимо основной задачи здесь также можно выполнить сканирование портов, узнать свой IP-адрес и произвести другие действия с сайтом.
- Открываем в браузере сервис Seolik и вводим ссылку на необходимый сайт, затем кликаем по кнопке «Анализ».
- В результате анализа рассматриваемого ресурса, перед нами отобразится вся необходимая информация: название сертификата, срок действия, серийный номер и другие атрибуты, которые могут быть полезны для разработчиков.
Использование данного сервиса поможет проверить сайт всего за несколько минут и уберечь от потери личной информации. В данном случае мы можем быть спокойны, сертификат действителен еще 322 дня.
SSL Shopper
По сравнению с предыдущим сервисом, данный инструмент не столь функционален и поддерживает только англоязычную версию. Давайте посмотрим, как он работает:
Wormly Web Server Tester
Один из самых популярных инструментов для проверки сайтов, который помогает не только узнать о наличии SSL/TLS, но и дает возможность просмотреть данные о шифровании, различные протоколы и многое другое. Работает это следующим образом:
- Открываем сайт и вводим в запрос «Web Server URL» нужную ссылку, затем кликаем по красной кнопке.
- Далее будет запущен глубокий анализ, который можно пропустить. Уже на первых этапах тестирования будет сообщено о безопасности ресурса в строке «Expires».
Данный сервис позволяет просматривать шифры сертификатов, что может быть полезно для веб-разработчиков.
Immuni Web
Это многофункциональный гигант, который анализирует поддержку протоколов, проверяет на совместимость PCI DSS и делает много всего, что недоступно в предыдущих инструментах. Конечно, здесь можно проверить и сайт на безопасность.
- Переходим по ссылке и в строку запроса «Enter your website or mail server address here» вписываем адрес для проверки. Далее кликаем по кнопке запуска справа от строки.
- Как только появятся результаты, перед нами отобразится новая страница. Пролистываем немного вниз и находим две строчки «Valid From» и «Valid To». Первая информирует о том, когда был выдан сертификат, вторая указывает на окончание срока действия.
При необходимости можно сохранить все результаты в формате PDF. Для этого следует кликнуть по кнопке «Download report».
SSL Checker
Незаменимый инструмент для разработчиков. Особенностью данного сервиса является то, что в нем можно активировать уведомления, которые будут оповещать об истечении срока действия сертификата.
- Переходим по ссылке и вводим адрес. Справа от строки запроса кликаем по кнопке «Check».
- Перед нами отобразится вся нужная информация. Для того чтобы напомнить об истечении срока действия сертификата, достаточно кликнуть по кнопке «Remind me SSL is about to expire» и указать свою почту.
На этом моя статья подходит к концу. Теперь вы знаете, как можно проверить SSL и TLS сертификаты на сайте. Спасибо за внимание!
Что такое SSL
Текущие тенденции сайтостроения предполагают высокую безопасность соединения пользователя с веб-ресурсом. Это необходимо для защиты персональных данных, секретных номеров банковских карт и информации о проводимых сделках. Организуется безопасность подключением протокола шифрования Secure Sockets Layer (сокращенно SSL).
- Сертификат выпускается доверенным центром Certification Authority (CA).
- После выдачи он подключается к домену средствами провайдера хостинга.
- Срок его действия ограничен 1 годом, после чего требуется продление.
При появлении любых сомнений в исправности защиты регистрироваться на сайте или вводить ранее выданные логин и пароль не рекомендуется. Тем более не стоит осуществлять онлайн-оплату с банковских карт или электронных кошельков, ведь не исключено, что проблема возникла из-за взлома ресурса злоумышленниками.
Причины появления ошибок SSL
Существует всего две причины, почему браузер отображает ошибку сертификата SSL со стороны сервера. Первая заключается в окончании срока активации, вторая – это покупка сертификата у поставщика без достаточных полномочий для выдачи «полноценной защиты». Например, виной может быть выбор самоподписанного сертификата, лишь эмулирующего работу реального протокола.
Остальные проблемы обычно скрываются на локальном компьютере:
- Произошел сброс системного времени.
- Неправильно настроена антивирусная программа.
- Сбоит браузер или установленное расширение.
- Срабатывает вредоносный скрипт.
Чтобы выяснить настоящую причину, пользователю браузера рекомендуется проверить все перечисленные факторы. При том же заражении компьютерными вирусами возможно проявление сразу нескольких симптомов – от изменения текущего времени и блокировки антивирусом до подключения перенаправления страниц в браузере и других неприятностей.
Изредка встречаются ситуации, когда проблема возникла со стороны администратора, если он ошибся при подключении нового сертификата или забыл продлить его действие. Обычно такие неполадки устраняются быстро, потому что после активации сайт проверяется и, в случае неработоспособности сертификата, проводится повторное подключение вплоть до получения положительного результата.
Время и дата
Сертификат SSL имеет четко обозначенный срок действия с датой активации и деактивации. Такой подход отчасти дает дополнительную защиту, потому что в случае технического сбоя в системных часах компьютера сайты перестают открываться. Сброс времени обычно происходит «назад», на дату изготовления материнской платы, на что и реагирует система.
Варианты исправления ситуации:
- Вручную внести корректную дату и время, после чего обновить страницу в браузере.
- Воспользоваться функцией синхронизации через интернет, встроенной в Windows.
- Заменить батарейку на памяти BIOS. При первом запуске ПК нужно внести корректные данные.
Каждый раз после изменения времени рекомендуется ручное обновление страницы или перезапуск браузера. Такой шаг активирует повторное соединение с сервером и позволяет зайти на сайт «с нуля», но уже с правильным временем, соответствующим сроку действия сертификата SSL (после активации и до ее завершения).
Настройки антивируса и брандмауэра
Варианты исправления ситуации:
Функция временного отключения имеется в любой защитной программе, даже интегрированной в операционную систему Windows. Но это не гарантирует полную деактивацию приложения. В этом случае разобраться в ситуации поможет открытие сайта на другом компьютере или запуск безопасного режима (актуально для проводного подключения к интернету).
Браузер и операционная система
Наличие проблемы с браузером проще всего определить открытием сайта на другом устройстве или в другой программе. Иногда решение заключается в банальном обновлении версии приложения до актуальной. То же относится к операционной системе, если используется интегрированный браузер вроде Edge. Пакеты обновлений для того и выпускаются, чтобы устранять неполадки в ПО.
Варианты исправления ситуации:
- Полностью очистить историю браузера вместе с кэшем и другими данными.
- Временно отключить все ранее установленные и активные расширения.
- Переустановить программу после ее полной деинсталляции.
Остается еще один вариант – сбросить настройки браузера до состояния «по умолчанию». Способ аналогичен переустановке, но экономит время. Правда, он неэффективен, если проблема возникла из-за сбоя в одном из служебных файлов программы. Отдельное внимание стоит уделить расширению, выполняющему функции антивирусной защиты, ведь оно часто блокирует даже безопасное соединение.
Заражение компьютерными вирусами
Выдачей ошибки SSL браузер, вероятно, предупреждает о попытке его подмены, переадресации на сайт-клон или иной угрозе. В это случае рекомендуется провести полную проверку компьютера на наличие вирусов. Если присутствуют другие признаки заражения, стоит скачать парочку программ со свежими антивирусными базами (например, CureIt).
Варианты исправления ситуации:
- Временно отключить все программы из автозагрузки.
- Провести очистку диска от временных файлов.
- Перезагрузить компьютер после предыдущих шагов.
Выполняются перечисленные действия программами типа CCleaner. Они дают прямой доступ как к автозагрузке операционной системе, так и к списку расширений установленных браузеров. Также в таких программах обычно есть функция удаления ненужных системных файлов, в которых запросто может быть тело компьютерного вируса.
Если предложенные способы устранения ошибки SSL не помогли, остается ждать, пока проблему устранит администратор, или воспользоваться любым другим тематическим сайтом с аналогичным контентом.
Читайте также: