Сертификаты безопасности для браузеров: Sorry, this page can’t be found.

27.08.1988 alexxlab

Содержание

Про поддержку сайтов с национальными сертификатами в Яндекс Браузере / Хабр

Очень много вопросов по этой теме. Оно и понятно: информации мало, противоречивых интерпретаций много. Для нас тема защиты соединений с сайтами близка. Мы пишем на Хабре об этом уже лет восемь. Например, в своё время мы первыми поддержали DNSCrypt прямо в браузере, первыми начали предупреждать о неизвестных корневых сертификатах в системе, первыми включили шифрование трафика для незащищенных Wi-Fi-сетей.

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

Коротко о главном

Национальный удостоверяющий центр выдаёт сертификаты на домены только тех организаций, которые явно это запросили. Полный список этих доменов публично доступен по адресу www.gosuslugi.ru/tls.
Яндекс Браузер применяет национальные сертификаты не для всего рунета, а только на тех сайтах, которые есть в списке на www. gosuslugi.ru/tls. Попытка применить сертификат на других доменах приведёт к стандартной ошибке и недоступности сайта для пользователя.
Национальные сертификаты используют общепринятую открытую криптографию и работают по стандартным правилам (это обычный RSA с длинным ключом, ровно такой же, какой выписывают другие центры сертификации).
Мы работаем над поддержкой стандарта Certificate Transparency и планируем создать публичный лог, в который будут вноситься все выпускаемые национальным центром сертификаты. Мы надеемся, что другие представители индустрии поддержат эту инициативу и запустят дополнительные публичные логи. Это позволит добиться прозрачности в работе с национальными сертификатами.

Подробнее о проблеме

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

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

К чему это может привести? Вот несколько вариантов:

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

Потребуется для каждого сайта как-то находить и устанавливать на компьютер его недоверенный корневой сертификат, чтобы браузеры перестали «ругаться» на самоподписанные сертификаты. При этом ни у браузеров, ни у пользователей не будет никакого контроля за их применением. Например, несколько лет назад мы уже рассказывали о злоумышленниках, которые вмешиваются в трафик пользователей, тайно устанавливая корневые сертификаты на компьютер. Так что этот вариант крайне опасен.
Теоретически браузеры могли бы прекратить проверять сертификаты. Но на практике никто на такое не пойдёт, потому что это равноценно переходу на http. Сертификаты без контроля не имеют смысла. Например, по этой причине мы сознательно вырезали из нашего браузера флаг —ignore-certificate-errors, который поддерживается в проекте Chromium. Потому что это опасно.

Ещё есть вариант отказаться от использования интернета для всех сценариев, где есть риск перехвата данных.

Вряд ли можно назвать какой-либо из этих вариантов приемлемым.

Описание текущего решения

Есть альтернативная инициатива — создать национальные удостоверяющие центры (НУЦ) и поддержать их корневые сертификаты в браузерах.

НУЦ смогут выдавать сертификаты тем (и только тем!) сайтам, которые к ним обратятся. Наличие альтернативы позволит не допустить ситуации, при которой пользователи лишатся доступа к онлайн-сервисам.

Первый такой НУЦ уже появился — на базе Госуслуг. Сейчас он работает так:

Юридическое лицо (владелец сайта) отправляет подписанную заявку на Госуслуги.
Госуслуги проверяют принадлежность домена.
В случае успеха помещают домен в публичный список, который доступен всем по адресу www.gosuslugi.ru/tls.
НУЦ выписывает сертификат на сайт. Это обычный RSA с длинным ключом, ровно такой же, какой выписывают другие центры сертификации. Дальше ключи можно использовать как обычные TLS-сертификаты. То есть всё работает согласно общепринятой открытой криптографии и по известным правилам.

Конечно же, это решение не заработало бы без поддержки браузеров. Мы признали неполный авторитет сертификатов НУЦ в Яндекс Браузере в версиях для Windows и Android.

Неполный авторитет — это значит, что сертификаты НУЦ будут признаваться только для тех доменов, которые помещены в публичный список на gosuslugi.ru/tls. Если посещаемого сайта нет в этом списке, то попытка применить новый сертификат приведёт к стандартной ошибке и не даст посетить сайт. И нет, нельзя выпустить сертификат по маске так, чтобы покрыть все домены второго уровня (например, все *.ru) — на стороне Браузера такое просто не заработает. Кроме того, все входящие к нам изменения этого списка будут проходить через контроль явных ошибок. Если очень грубо, то это первый шаг к Certificate Transparency, чтобы обеспечить аудируемость процедуры выдачи сертификатов.

Наши планы

Текущее решение, конечно же, требует развития. Основной способ завоевания доверия к центру сертификации — это открытость. И здесь мы планируем несколько вещей.

Прежде всего, хотим организовать рассылку уведомлений в Яндекс Вебмастере тем владельцам сайтов, для которых зафиксирован выпуск сертификатов.

Наша более глобальная инициатива — поддержать стандарт Certificate Transparency (CT) и поднять публичный лог, в который НУЦ будет записывать выпущенные сертификаты. Если посещаемого пользователем сайта не будет в этом логе, то браузер выдаст ошибку ERR_CERTIFICATE_TRANSPARENCY_REQUIRED и не даст его открыть.

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

Публичные логи позволят владельцам сайтов в любой момент времени проверить, выпускались ли сертификаты для их доменов. Более того, мы надеемся на появление внешнего аудита, который будет мониторить логи на предмет расхождений. Для удобства внешнего аудита мы хотим запустить аналог инструмента developers.facebook.com/tools/ct.

Большая просьба: если вы знаете, как сделать лучше, — приходите, советуйте. Хотите покритиковать решения — критикуйте и предлагайте улучшения.

P. S. Пока оформлял этот пост, прилетела новость: центр сертификации DigiCert, обслуживающий около 50 тыс. российских сайтов, ограничил им выдачу сертификатов.

Update. Опубликовали на Гитхабе исходный код, который позволяет добавить поддержку сайтов с национальными сертификатами в любой браузер на основе Chromium.

защита от недоверенных сертификатов. Справка

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

Зачем нужен сертификат сайта
Чем опасен недоверенный сертификат
Блокировка сайтов с недоверенными сертификатами
Возможные причины блокировки
Если автор сертификата неизвестен
Если сертификат установлен программой
Пожаловаться на фишинговый сайт

Ваши личные или платежные данные при отправке на сайт должны быть защищены. В интернете сайты используют для безопасного соединения протокол HTTPS. Он включает асимметричный алгоритм шифрования, когда данные зашифровываются с помощью открытого ключа и расшифровываются с помощью закрытого ключа. Для каждого сеанса связи Браузер заново генерирует закрытый ключ и передает его на сайт с мерами предосторожности, исключающими кражу.

Однако, если вы попадете на фишинговый сайт, он может получить закрытый ключ и затем расшифровать ваши данные. Для защиты от фишинга сайты используют цифровые сертификаты, выданные специальными удостоверяющими центрами. Сертификат гарантирует, что ключи действительно принадлежат владельцу сайта.

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

Перехватить или подменить ваши личные данные, а также прочитать переписку.
Получить ваши платежные данные (номер карты, имя владельца, срок действия и CVV2) и использовать их для кражи денег с вашего счета.

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

«}}»> появляется значок , а вместо страницы сайта — предупреждение о невозможности установить безопасное соединение. В этом случае вы можете либо отказаться от посещения сайта, либо внести сертификат в список надежных.

Внимание. Делайте это, только если вы полностью уверены в надежности сертификата. Иначе злоумышленники могут получить доступ к вашим личным данным и электронным платежам.

Примечание. Если вы не можете установить безопасное соединение на сервисах Яндекса из-за ошибки ERR_CERT_AUTHORITY_INVALID или ERR_CERT_DATE_INVALID, это означает, что в операционной системе не хватает сертификата. Обновите Windows или импортируйте сертификаты вручную. Подробнее читайте в статьях Ошибка ERR_CERT_AUTHORITY_INVALID и Ошибка ERR_CERT_DATE_INVALID.

Браузер блокирует сайты, у которых есть следующие проблемы с сертификатами:

Автор сертификата неизвестен

Вы увидите сообщение «Невозможно установить безопасное соединение. Злоумышленники могут пытаться похитить ваши данные (например, пароли, сообщения или номер банковской карты)».

Подробнее см. раздел Если автор сертификата неизвестен.

Сертификат установлен специальной программой

Вы увидите сообщение «Вы попытались перейти на сайт example.com, сертификату безопасности которого не следует доверять. Сертификат был выдан неизвестным Яндексу центром сертификации, однако операционная система считает его надёжным…».

Подробнее см. раздел Если сертификат установлен программой.

Неверный адрес сайта

Вы увидите сообщение «Не удалось подтвердить, что это сервер example.com. Его сертификат безопасности относится к example1.com. Возможно, сервер настроен неправильно или кто-то пытается перехватить ваши данные».

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

Самозаверенный сертификат

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

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

Недоверенный корневой сертификат

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

Истек срок действия сертификата

Вы увидите сообщение «Не удалось подтвердить, что это сервер example.com. Срок действия его сертификата безопасности истек <…> дней назад. Возможно, сервер настроен неправильно или кто-то пытается перехватить ваши данные. Обратите внимание, что на компьютере установлено <текущее время>. Если оно неправильное, измените его и обновите страницу».

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

Сертификат отозван

Вы увидите сообщение «Обычно сайт example.com использует шифрование для защиты ваших данных. Однако в этот раз он прислал на запрос Браузера подозрительный ответ. Возможно, другой сайт пытается выдать себя за example.com либо оборвалось подключение к сети Wi-Fi. Ваши данные по-прежнему в безопасности: на всякий случай Браузер разорвал соединение до обмена информацией. Перейти на сайт example.com невозможно, так как его сертификат отозван. Это могло произойти из-за ошибки сети или атаки на сайт. Скорее всего, он заработает через некоторое время».

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

Устаревшее шифрование

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

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

Шифры не поддерживаются

Вы увидите сообщение «Сайт example.com отправил некорректный ответ».

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

Ключ сертификата не совпадает с закрепленным ключом

Вы увидите сообщение «Обычно сайт example.com использует шифрование для защиты ваших данных. Однако в этот раз он прислал на запрос Браузера подозрительный ответ. Возможно, другой сайт пытается выдать себя за example.com либо оборвалось подключение к сети Wi-Fi. Ваши данные по-прежнему в безопасности: на всякий случай Браузер разорвал соединение до обмена информацией. Перейти на сайт example.com невозможно, так как он использует закрепление сертификата. Это могло произойти из-за ошибки сети или атаки на сайт. Скорее всего, он заработает через некоторое время».

Значит, ключ корневого сертификата не совпадает с ключом, закрепленным на сайте. Возможно, злоумышленники пытаются подменить корневой сертификат. В этом случае они могут перехватить ваши данные. Подробнее о закреплении (привязывании) ключа см. статью HTTP Public Key Pinning.

Не удалось включить шифрование при соединении HSTS

Вы увидите сообщение «Обычно сайт example.com использует шифрование для защиты ваших данных. Однако в этот раз он прислал на запрос Браузера подозрительный ответ. Возможно, другой сайт пытается выдать себя за example.com либо оборвалось подключение к сети Wi-Fi. Ваши данные по-прежнему в безопасности: на всякий случай Браузер разорвал соединение до обмена информацией. Перейти на сайт example.com невозможно, так как он использует HSTS-протокол. Это могло произойти из-за ошибки сети или атаки на сайт. Скорее всего, он заработает через некоторое время».

Значит, Браузер не смог включить шифрование и разорвал соединение. Сервер, на котором расположен сайт, обычно использует шифрование, так как на нем включен HSTS-протокол. Отсутствие шифрования может быть признаком хакерской атаки. В этом случае злоумышленники или вредоносное ПО могут перехватить ваши данные.

В этом случае либо администратор сети, либо неизвестное лицо установили сертификат. Вы увидите предупреждение:

Вы можете либо отказаться от посещения сайта, либо внести сертификат в список надежных, нажав в диалоге Подробности, а затем Сделать исключение для этого сайта. В списке надежных сертификат будет находиться в течение 30 дней, после чего вам придется снова сделать для него исключение.

Внимание. Нажимайте кнопку Сделать исключение для этого сайта, только если вы уверены в надежности сертификата. Иначе злоумышленники могут получить доступ к вашим личным данным.

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

Для домашнего компьютера. Обновите антивирус и просканируйте компьютер, чтобы обнаружить вредоносное ПО. Если антивирус найдет и удалит установленный злоумышленником сертификат, предупреждение в Браузере больше появляться не будет. Если антивирус не удалит подозрительный сертификат, вы можете избавиться от него сами.
Внимание. Будьте осторожны — если сертификат был установлен не вредоносным ПО, а полезной программой, его удаление может привести к нарушению работы системы.
Для служебного компьютера. Для удаления подозрительного сертификата обратитесь к системному администратору. Если он не устанавливал этот сертификат, он его удалит. Если сертификат был установлен администратором, можете нажимать Перейти на сайт. Но учтите, что после этого администратор сможет просматривать ваши личные данные и электронные платежи.

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

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

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

Браузер предупреждает о таких проблемах:

Чтобы посетить сайт:

Выясните, какая программа заменила сертификат. Для этого нажмите на странице предупреждения соответствующую ссылку.
Решите, готовы ли вы доверить свои личные данные изготовителю сертификата:
- Если готовы, нажмите Перейти на сайт.
- Если не готовы, отключите в программе проверку соединений HTTPS. Вы можете воспользоваться инструкциями для программ:
  - Антивирус Касперского
  - ESET NOD32
  - Dr.Web
  - AdGuard (помимо программы AdGuard существует одноименное расширение, которое не создает своих сертификатов, поэтому для него проверку отключать не нужно).
  Внимание. Отключив проверку HTTPS, вы не останетесь без защиты. Браузер самостоятельно проверяет безопасность загружаемых файлов, блокирует вредоносные страницы и баннеры, использует дополнительную защиту для страниц банков и платежных систем.
  Если после отключения проверки HTTPS Браузер продолжает предупреждать о подозрительном сертификате, а программа, установившая сертификат, вам не нужна, попробуйте временно закрыть эту программу.

Если вы столкнулись с подозрительным сайтом, напишите нам о нем через форму.

Написать в службу поддержки

Была ли статья полезна?

Браузеры и проверка сертификатов — SSL.com

Введение

HTTPS (через SSL /TLS) использует шифрование с открытым ключом для защиты сообщений браузера от чтения или изменения при передаче через Интернет. Серверы предоставляют посетителям браузера открытый ключ, который используется для установления зашифрованного соединения для всех последующих обменов данными.

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

Браузеры предотвращают это аутентификации HTTPS-серверы, использующие сертификаты, которые являются цифровыми документами, которые связывать открытый ключ к отдельной теме. Привязка подтверждается наличием доверенного Центр сертификации (CA), такие как SSL.com проверять личность потенциальных владельцев сертификатов с помощью автоматических и ручных проверок соответствующих баз данных.

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

Обратите внимание, что процесс проверки сертификата (подробно описан в стандартном документе 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. Браузер проверяет ограничения имени

Частный (но пользующийся всеобщим доверием) промежуточный ЦС с соответствующим ограничения имени может предоставить организации детальный контроль над управлением сертификатами и их выдачей. Сертификаты могут быть ограничены определенным доменом или деревом доменов (т. Е. Включая поддомены) для доменного имени компании или организации. Ограничения имен часто используются для сертификатов промежуточного ЦС, приобретенных у ЦС, пользующегося всеобщим доверием, чтобы помешать промежуточному ЦС выдавать совершенно действительные сертификаты для сторонних доменов (например, google.com).

6. Браузер проверяет ограничения политики

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

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

7. Браузер проверяет основные ограничения (длина пути)

Формат X.509 v3 позволяет издателям определять максимальную длину пути, которую может поддерживать сертификат. Это обеспечивает контроль над тем, как далеко каждый сертификат может быть помещен в путь сертификации. Это действительно важно — браузеры игнорировали длину пути сертификации, пока исследователь не продемонстрировал в 2009 г. презентация, как он использовал листовой сертификат своего веб-сайта, чтобы подделать действительный сертификат для большого веб-сайта электронной коммерции.

8. Браузер проверяет использование ключа

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

9. Браузер продолжает обрабатывать все оставшиеся критические расширения

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

Заключение

Всемирная паутина — это сложная система, состоящая из взаимосвязанных и постоянно развивающихся движущихся частей. Таким образом, безопасность браузера не является решенной проблемой, и мы надеемся, что эта статья дала некоторое представление о сложности даже одного компонента, который мы здесь рассмотрели. Доверие играет важную роль в обеспечении вашей безопасности в Интернете, и по этой причине мы настоятельно рекомендуем вам узнать больше о политике сертификации вашего центра сертификации. (Не стесняйтесь просматривать Политика SSL.com здесь, на самом деле.)

Спасибо за выбор SSL.com, где, как мы полагаем, безопаснее Интернет это better Интернет.