Отзыв сертификатов является важным компонентом обеспечения того, чтобы SSL выполнял свою работу и защищал пользователей Интернета
от кражи информации во время атаки «человек в середине». В настоящее время существуют два основных метода, с помощью которых это происходит:
репозитории списков отзыва сертификатов (CRL) и ответчиков протокола сетевого сертификата (OCSP). Органы сертификации (ЦС) публикуют
CRL и подписывают ответы OCSP на регулярной основе, причем CRL обычно является еженедельным списком сертификатов, отозванных в
течение предыдущих семи дней, и OCSP подписывается и отправляется в виде ответа в течение нескольких часов после отзыва сертификата.
Когда пользователь пытается получить доступ к веб-серверу, сервер проверяет последний CRL, связанный с выдающим ЦС, а также отправляет
запрос OCSP для информации о статусе сертификата. Сервер отправляет ответ «хороший», «отозванный» или «неизвестный».
Браузер пользователя затем либо сделает безопасное соединение для пользователя, либо, если установлено, что сертификат «отменен»,
предупреждает пользователя о потенциальный риск продолжения работы с незашифрованным сеансом.
Отзыв сертификатов защищает веб-пользователей от скомпрометированных сертификатов, которые, если их не отменять, в противном случае
можно было бы использовать для подмены сайта, который фактически намеревался посетить, чтобы украсть личную информацию у пользователя.
Отзыв также защищает владельцев веб-сайтов и веб-серверов, определяя мошеннические сертификаты и смягчая атаки «человек-в-середине»,
которые могут возникнуть, если хакер может захватить домен. Он также защищает владельцев веб-сайтов от нарушений доверия, которые
могут повредить отношения с клиентами.
Одним из преимуществ наличия нескольких сертификационных центров (CA), из которых можно выбрать сертификат SSL, является то,
что клиенты имеют гибкость в выборе центра сертификации, который отвечает их конкретным потребностям, или даже используют
несколько ЦС для избыточности или для доступа к более широкому набор инструментов. Однако недостатком конечных пользователей
является то, что они часто могут не знать, разрешено ли конкретному ЦС выдавать сертификат, и может быть вероятность,
что сертификат был получен с помощью мошенничества.
Эксперты по безопасности представили предложения разрешить владельцам доменов разрешать CA (авторизация центра сертификации),
разрешить веб-серверу указывать, какой открытый ключ доверен (публичный ключ), или разрешить владельцу веб-сайта контролировать сертификаты,
которые были выпущенные для их домена (прозрачность сертификата).
Microsoft предлагает решение для повышения надежности сертификатов: репутация сертификата. В Internet Explorer (IE) 11 Microsoft расширит
телеметрию, собранную с помощью фильтра SmartScreen, чтобы включить анализ сертификатов SSL, представленных веб-сайтами. Microsoft создает
инструменты для создания информации обо всех сертификатах, выпущенных каждым доверенным корневым центром сертификации.
Одна из целей этих усилий будет заключаться в том, чтобы отмечать потенциальные атаки «человек-в-середине» (MITM), когда сайт
использует общедоступные сертификаты из общедоступных центров сертификации. Примеры предупреждающих флагов могут включать:
Веб-сайту был выпущен подчиненный сертификат ЦС, способный выдавать другие SSL-сертификаты
Веб-сайт представляет другой сертификат только в определенных регионах
Значительное изменение в полях сертификата, который обычно выдает ЦС, например, местоположение ответчика OCSP
В настоящее время Google и Microsoft каждый продвигают свои собственные бесконфликтные решения для доверия сертификатов.
Google продвигает прозрачность сертификатов (CT) в качестве решения - ищет, чтобы CAs поддерживали сертификаты CC для EV SSL .
Этот двойной подход этих двух компаний может быть полезен для общественности с точки зрения защиты. Для сравнения,
Certificate Reputation поддерживает следующее:
Конфиденциальность. Когда подписчик сертификата приобретает сертификат для своего внутреннего имени домена,
это доменное имя не будет доступно публично. Данные также будут отправляться в зашифрованном виде в Microsoft, и никакая
личная информация не будет сохранена.
Монитор сертификатов. Владельцы доменов могут быть уведомлены по электронной почте, когда новые сертификаты выдаются
с их доменными именами.
Масштабируемость - решение о репутации сертификата уже внедряется и масштабируется без каких-либо усилий или сотрудничества
со стороны третьих сторон, таких как веб-сайты или центры сертификации. Microsoft может повысить функциональность своей системы по мере необходимости.
Развертывание. Точно так же репутация сертификата должна быть легко развертываться, так как потребуются только усилия Microsoft.
Решение не будет полагаться на изменения, выполняемые третьими лицами, такими как CA, подписчики, разработчики веб-серверов или разработчики OCSP.
Эксперты по безопасности также говорят, что есть некоторые недостатки:
Нет публичного журнала. Microsoft будет владеть базой данных, и она не станет общедоступной и недоступной для аудита.
Чувствительность. Атаки, которые могут быть сильно нацелены, могут быть трудно обнаружить.
Все сертификаты не покрыты. Решение будет полагаться на телеметрию, собранную с использованием IE 11 (и более поздних версий).
Это означает, что он нацелен на сертификаты, с которыми сталкиваются браузеры Microsoft, а не другие приложения или браузеры.
Существует также проблема отказа, когда организация может не предоставлять данные Microsoft; в этом случае решение будет устаревать для этих сайтов.
Совет безопасности ЦС («CASC») рекомендует соблюдать следующие меры предосторожности:
Конфигурация и развертывание SSL / TLS
Сайтам следует развернуть цифровые сертификаты, в которых используется алгоритм хеширования SHA2 и 2048-бит или более высокий размер ключа.
Операторы сервера должны также требовать TLS 1.1 или 1.2, безопасные куки-файлы и безопасные комплекты шифрования (не RC4).
Администраторы должны периодически проверять и анализировать сети своих организаций, чтобы идентифицировать выявление слабых, мошеннических
или устаревших сертификатов и обновлять их по мере необходимости. Большинство центров сертификации предлагают инструменты своим клиентам,
предназначенным для обнаружения проблем и оценки их развертывания SSL / TLS. Администраторы должны связаться со своим представителем CA, чтобы узнать больше.
Защита ключа
Операторы веб-сайтов должны проявлять большую осторожность в защите своих личных ключей. Плохие игроки в значительной степени полагаются
на плохую конфигурацию, небезопасные серверы и другие обходные пути для компрометации информации и зашифрованной информации.
Улучшенная защита секретных ключей с помощью защищенного хранилища ключей или устройств значительно затрудняет компрометацию этих данных.
Always-On SSL
- это подход к обеспечению безопасности конечного пользователя во время посещения всего веб-сайта. Always-On SSL смягчает захват сеансов и
атаки «человек-в-середине», поддерживает сквозное шифрование и предоставляет пользователям идентификацию владельца веб-сайта.
Совершенная передовая секретность
Некоторые развертывания SSL / TLS позволяют злоумышленнику захватить зашифрованный трафик, а затем расшифровать эти данные,
как только частный ключ будет получен через вызов вызова или ключевой компромисс. Прекрасная прямая секретность предотвращает это
будущее дешифрование хранимых данных, создавая по-настоящему эфемерные ключи сеанса. Операторы веб-сайтов должны обеспечить
прекрасную секретность и обеспечить набор ECDHE и DHE в верхней части списка их шифрованных наборов.
Подпись кода
Пользователи, которые создают приложения для своей компании, должны подписать свой код с использованием общедоступного сертификата.
Перед подписанием, сканируйте код для вредоносного ПО и потенциальных задних дверей. Закрытие секретных ключей для кодов должно храниться безопасно,
предпочтительно на аппаратном токене. Подписанный код должен быть отмечен по времени, если сертификат будет отозван позже.
Современные системы . Пользователи всегда должны гарантировать, что у них есть современные браузеры, серверы, брандмауэры,
маршрутизаторы и программное обеспечение с исправлениями для защиты своей системы от уязвимостей. Операторы сервера должны оценивать патчи,
чтобы обеспечить их полную защиту от рисков безопасности.
Важность проверки отзыва сертификата
Сертификаты обычно действительны в течение одного-трех лет, и в течение этого времени возможно, что владелец
веб-сайта или ЦС понимает, что конечные пользователи не должны доверять сертификату. Существует несколько
случаев, когда это может произойти, в том числе:
Владелец веб-сайта перестает вести дела, больше не владеет доменным именем, используемым в сертификате,
не изменил название своей организации или не хочет закрыть веб-сервер.
Абонент узнает, что неавторизованная сторона получила доступ к закрытому ключу, связанному с открытым ключом в сертификате.
CA узнает, что ошибки были сделаны при аутентификации, абонент исказил некоторую информацию о материалах, используемую в
процессе аутентификации, или абонент нарушил условия своего соглашения с ЦС.
Когда абонент или ЦС принимает решение об отзыве сертификата, это решение должно быть передано конечным пользователям,
которые сталкиваются с используемым сертификатом. Для этого существуют два разных метода:
CRL (Список отзыва сертификатов) - файл с цифровой подписью, содержащий список сертификатов, которые были отозваны
и еще не истекли. Несмотря на то, что для каждого сертификата ЦС имеется отдельный CRL, CRL может быть довольно большим.
Это делает их неэффективными для использования в устройствах с ограниченной памятью, таких как смартфоны. Однако, если вы посещаете
несколько сайтов с сертификатами, подписанными одним и тем же ЦС выдачи, получение CRL и кэширование может быть
очень эффективным способом проверки статуса всех этих сертификатов.
OCSP (Online Status Status Protocol) - протокол, в котором клиент запрашивает статус для определенного сертификата,
подписанного определенным эмитентом, и получает ответ с цифровой подписью, содержащий его статус. Как правило, ответ OCSP
содержит одно из трех значений: хорошее, отозванное или неизвестное. Ответы OCSP очень малы по сравнению со многими отзывами
CRL и поэтому эффективны для устройств с ограниченной памятью.
Сертификаты должны содержать один или несколько URL-адресов, из которых конечный пользователь может получить ответ
CRL или OCSP. Если оба метода поддерживаются, программное обеспечение конечного пользователя (браузер) будет поддерживать
одно за другим, но может вернуться к второму методу, если первый из них не удался.
Как правило, CRL и ответы OCSP извлекаются из веб-сайтов, которыми управляет сам СА. Однако новый способ доставки статуса
сертификата становится популярным - OCSP Stapling. С помощью Stapling веб-сайт предварительно выбирает свой собственный ответ
OCSP от CA, а затем доставляет его конечным пользователям во время установления связи SSL. Этот метод эффективен, потому что
конечный пользователь не должен делать отдельное подключение к ЦС, и он безопасен, потому что ответ OCSP имеет цифровую подпись,
поэтому он не может быть изменен без обнаружения.
Браузеры и другие приложения обычно предупреждают пользователя об отзыве сертификата и не допускают его продолжения.
Если конечному пользователю разрешено посещать сайт с отозванным сертификатом, возможно, что он или она не будут общаться с
предполагаемым сайтом, а вместо этого со злым человеком в середине (MITM). Или конечный пользователь может обмениваться данными
с предполагаемым сайтом, но ЦС определил, что сайту больше не нужно доверять. Переход на сайт может привести к тому, что конечный
пользователь столкнется с рядом рисков, в том числе:
Потеря личной информации. Злоумышленник может просматривать конфиденциальную конфиденциальную информацию, которую
пользователь отправляет на веб-сайт. Некоторые веб-сайты собирают информацию, такую как номера социального страхования, информацию
о банковском счете, номера кредитных карт, даты рождения и т. Д. Если конечный пользователь отправляет эту информацию на веб-сайт
с отозванным сертификатом, все они могут быть захвачены злоумышленником.
Кража личных данных - злоумышленник может улавливать идентификационную информацию (имя пользователя и пароль), которые
пользователь отправляет на веб-сайт. Знание этой информации позволяет злоумышленнику олицетворять пользователя на законном веб-сайте.
Злоумышленник также может изменить пароль пользователя, чтобы захватить учетную запись пользователя.
Финансовые потери. После кражи личности пользователя могут быть украдены и онлайн-ресурсы, такие как деньги на банковском счете.
Установка вредоносного ПО на свой компьютер. Во многих случаях злоумышленники заинтересованы в установке вредоносного ПО
на компьютер пользователя. Запуск такой вредоносной программы может позволить злоумышленнику украсть у пользователя более личную
информацию, посмотреть, какие типы пользователей и какие веб-сайты посетили, или взять на себя компьютер пользователя для использования
в более крупной атаке. Вредоносное ПО можно распространять дальше, обращаясь к адресной книге пользователя и отправляя электронное
письмо каждому контакту в нем.
Java поддерживает использование сертификатов подписи кода, выданных органами сертификации. Когда Java-код подписан одним из этих
сертификатов, он включает в себя идентификационную информацию об издателе кода и называется подписанным приложением.
Поскольку подписанные приложения считаются более безопасными, Java обычно позволяет запускать их без предупреждения, описанного выше.
К сожалению, бывают случаи, когда необходимо подписать сертификат подписи кода. Типичным примером является то, что кто-то с доступом
к закрытому ключу сертификата покидает компанию и больше не может подписывать код, используя личность компании.
Когда сертификат подписи кода отменяется, любое приложение, подписанное после даты отзыва, не должно доверять.
Подобно SSL, эта информация об отзыве публикуется центрами сертификации в виде списков отзыва сертификатов (CRL) или предоставляется
через службу сетевого протокола протокола (OCSP).
По умолчанию Java не проверяет, был ли отозван сертификат.Сертификат, использованный в атаке на прошлой неделе, действительно был отменен,
но без проверки отзыва это не имело значения - атака может быть выполнена без предупреждения для пользователя, в результате чего на их компьютере
устанавливаются вредоносные программы. Если это не хороший пример важности проверки отзыва, тогда ничего нет!
С помощью всего лишь немного усилий Java позволяет пользователям включать проверку аннулирования и снизить этот риск.
Выберите вкладку «Дополнительно» панели управления Java (доступную с панели управления в Windows) и прокрутите страницу до раздела «Безопасность».
Там вы найдете две настройки, которые вы должны включить:
Проверка сертификатов для отзыва с использованием списков отзыва сертификатов (CRL)
Включить проверку проверки онлайн-сертификата который позволяет проводить проверку отзыва через OCSP
В качестве дополнительного уровня защиты многие из самых популярных браузеров позволяют увеличить объем проверки отзыва, который они выполняют по умолчанию:
Internet Explorer - выберите «Свойства обозревателя», перейдите на вкладку «Дополнительно» и прокрутите страницу до раздела «Безопасность».
Убедитесь, что выбрана опция «Проверить наличие сертификата сервера».
Firefox - выберите «Параметры», выберите вкладку «Дополнительно», выберите вкладку «Шифрование» и нажмите кнопку «Проверить».
Убедитесь, что «Использовать протокол проверки состояния протокола (OCSP) для подтверждения текущей действительности сертификатов»).
Для дополнительной защиты выберите «Когда соединение с сервером OCSP завершается неудачно, считайте сертификат недействительным».
Chrome - выберите «Настройки», нажмите «Показать дополнительные настройки ...» и прокрутите страницу вниз до раздела «HTTPS / SSL».
Выберите «Проверка отзыва сертификата сервера».
Safari в Mac OS X - откройте утилиту Keychain Access. Выберите пункт меню «Keychain Access» -> «Preferences», затем выберите «Сертификаты».
Установите для обоих опций OCSP и CRL значение «Требовать, указывает ли сертификат». Обратите внимание, что при нажатии на
раскрывающийся список вам может потребоваться удерживать клавишу Option на клавиатуре. Установите приоритет в «OCSP».
Существует две основные технологии, позволяющие браузерам проверять статус отзыва конкретного сертификата: с использованием протокола
сетевого сертификата (OCSP) или поиска сертификата в списке отзыва сертификатов (CRL). OCSP предоставляет информацию об отзыве отдельного
сертификата от выдающего ЦС, тогда как CRL предоставляют список отозванных сертификатов и могут быть получены клиентами менее часто.
Поддержка браузера для двух форм аннулирования варьируется от отсутствия проверки на использование обоих методов, если это необходимо.
Вот пример из жизни:
30 апреля 2013 года RSA был отозван промежуточный сертификат, выданный Network Associates - который является частью цепочки из
отдельного сертификата обратно в доверенный корень. Промежуточный сертификат использовался для подписи нескольких сертификатов SSL McAfee,
в том числе для веб-сайта загруженной электронной коммерции, www.mcafeestore.com . Его отзыв должен был предотвратить доступ ко всем
веб-сайтам с использованием промежуточного продукта, включая интернет-магазин. Однако более недели спустя никто не заметил: никаких твитов
или новостных статей не появилось, и сертификат все еще был на месте.
После публикации CRL браузеры должны отображать сообщение об ошибке и запрещать доступ к веб-сайту. Однако реальность несколько отличается.
Firefox не загружает CRL для сайтов, которые используют самые популярные типы SSL-сертификатов (все типы сертификатов, кроме EV,
который обычно отображается с зеленой полосой). Без загрузки CRL Firefox с удовольствием продолжит работу, как обычно; позволяя людям
посещать веб-сайт и передавать конфиденциальную личную информацию, полагаясь на сертификат, который больше не действителен.
В любом случае, даже если бы OCSP был доступен, по умолчанию Firefox будет проверять действительность сертификата сервера и не пытаться
проверять всю цепочку сертификатов (опять же, за исключением сертификатов EV).
Никаких предупреждений для мобильных пользователей ни на Android, ни на iOS !
Мобильный просмотр теперь составляет значительную долю использования Интернета. Ни Google Chrome на Android, ни Safari на iOS
не вызывают предупреждения пользователю даже после сброса. Safari в iOS не проводит проверку отзыва вообще, кроме сертификатов
расширенной проверки, и не делает запросы для CRL, которые вызвали бы сообщение об отзыве.
Google Chrome: настройки по умолчанию, проверки отзыва включены в Windows, а проверки отзыва включены в Linux
Google Chrome по умолчанию не выполняет стандартные проверки отзыва сертификатов, отличных от EV. Google объединяет ограниченное
количество списков отзыва сертификатов и распространяет его через механизм обновления, но, по крайней мере, в настоящее время он не перечисляет
соответствующий сертификат или даже какие-либо другие сертификаты, отозванные в том же CRL. Для большинства пользователей Chrome с
настройками по умолчанию, как и в Firefox, ничто не будет казаться неуместным.
Для безопасности, у Google Chrome есть возможность включить правильные проверки отзыва, но в этом случае конечный результат зависит от
платформы. В Windows Google Chrome может использовать CryptoAPI Microsoft для извлечения CRL, и он правильно предотвращает доступ к сайту.
Тем не менее, CRL RSA не поставляется обычным способом: вместо предоставления CRL в двоичном формате он кодируется в текстовый формат,
который не является принятым стандартом . Mozilla NSS, который используется Firefox на всех платформах и Google Chrome для Linux , не поддерживает формат .
В Linux Google Chrome делает запрос для CRL, но не может обработать ответ и вместо этого работает как обычно.
Веб-браузер Microsoft, Internet Explorer - один из самых безопасных браузеров в этом контексте. Он извлекает информацию об отзыве
(с предпочтением OCSP, но возвращается к CRL) для сертификата сервера и остальной части цепочки сертификатов и, как следствие проверки отзыва,
не позволяет пользователю совершать покупки
Наряду с Internet Explorer Opera по умолчанию защищена: она запрещает доступ к веб-странице. Opera проверяет всю цепочку сертификатов,
используя OCSP или CRL, где это необходимо.
OV 
Купить сертификат
