Ocsp stapling что это
Перейти к содержимому

Ocsp stapling что это

  • автор:

Добиваемся OCSP stapling = Yes для сертификатов от WoSign на Nginx

Доброго времени суток, Хабражители.
Прочитав статьи №1 и №2 (про бесплатные SSL сертификаты от китайских друзей WoSign столкнулся с тем, что многие не могут добиться OCSP stapling = Yes для этих сертификатов.
Хочу рассказать как этого добился я.

Мы получили сертификат WoSign, залили на сервер.
И так, приступим.

Во-первых — получаем промежуточные сертификаты. 

cd /path/to/your/ssl/ wget -O - https://www.startssl.com/certs/ca.pem | tee -a ca-certs.pem > /dev/null wget -O - https://www.startssl.com/certs/sub.class1.server.ca.pem | tee -a ca-certs.pem > /dev/null wget -O - http://aia.startssl.com/certs/ca.crt | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null wget -O - http://aia1.wosign.com/ca1g2-server1-free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null wget -O - http://aia6.wosign.com/ca6.server1.free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null

Во-вторых — в коняги Nginx’а добавляем 

######################################################### # # ssl_session_cache shared:SSL:10m; ssl_session_timeout 5m; ssl_prefer_server_ciphers on; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate "/path/to/your/ssl/ca-certs.pem"; resolver 8.8.8.8 8.8.4.4 valid=300s; resolver_timeout 5s; # # #########################################################

В-третьих — в коняги домена прописываем для 443 порта в раздел server следующее: 

 ssl on; ssl_certificate /path/to/your/ssl/ssl.crt; ssl_certificate_key /path/to/your/ssl/ssl.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'HIGH:!aNULL:!MD5:!kEDH'; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

И напоследок — перезапускаем Nginx 

service nginx restart

Теперь при проверке на SSL-тестере мы видим результат А+ и включенный OCSP stapling.
Так же можно проверить это прямо на сервере командой 

openssl s_client -connect YourDomain.com:443 -tls1 -tlsextdebug -status

Если в результате есть следующее,
то значит всё отлично!

OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = CN, O = WoSign CA Limited, CN = WoSign Free SSL OCSP Responder(G2)
Produced At: Mar 27 14:30:05 2015 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: A06661F16CBCC23E98BC71914830B85AAA8D0A6B
Issuer Key Hash: D2A716207CAFD9959EEB430A19F2E0B9740EA8C7
Serial Number: 4C306486969BCBC1AE555A1D8C117B87
Cert Status: good
This Update: Mar 27 14:30:05 2015 GMT
Next Update: Mar 29 14:30:05 2015 GMT

Signature Algorithm: sha1WithRSAEncryption
7c:d8:e8:28:37:a3:2b:44:d2:30:f3:e5:a6:fa:9d:ff:1c:4a:
d9:33:43:a2:75:d6:f5:da:a1:47:f4:46:22:af:a2:54:a8:30:
cb:c8:6a:f9:1f:85:18:ee:c1:70:43:c9:08:61:cb:eb:b1:d6:
42:70:0f:e4:7b:dc:81:fb:f5:47:d1:02:b9:f4:bb:e4:5d:32:
57:75:8e:ca:15:95:4c:50:f3:2b:8f:94:ab:53:2d:a7:0a:b0:
3e:ab:d4:2b:fa:f1:8c:2e:00:46:e5:9b:d3:31:9f:e6:54:9d:
35:eb:20:95:b4:1a:12:7c:58:f2:f3:38:6b:fb:a6:1f:3c:cf:
fa:bc:f2:bb:92:e8:b0:41:37:84:31:ca:8c:44:73:60:8c:2f:
60:1f:7c:97:a8:7f:f0:b2:b3:8f:68:ce:3c:1d:9d:91:c9:88:
a7:bc:6e:91:93:68:de:6b:84:91:3e:34:7c:46:de:eb:71:9a:
76:f7:f8:87:d1:be:12:1b:7a:f0:3c:37:98:41:92:7a:6c:40:
87:3f:a1:f5:ef:d7:a3:1e:d2:34:3b:5d:f5:de:b9:a7:1d:a8:
da:f6:c0:2e:19:6f:e7:9c:96:78:3e:c7:a1:9d:f8:9d:09:81:
f0:5d:16:be:53:0c:cb:82:28:05:08:b2:cd:d6:5d:46:3c:ea:
cd:a1:e7:55

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

  • Информационная безопасность
  • Криптография
  • PHP

dxdt.ru: занимательный интернет-журнал

Ресурсы: техническое описание TLS, LaTeX — в картинки (img)

Техническое: OCSP stapling в Firefox

k11011101

(Продолжаем криптографическую серию заметок.) Оказывается, в Firefox версии 26 включили поддержку OCSP staplig. Что это такое? OCSP (Online Certificate Status Protocol) – это протокол, позволяющий клиенту (браузеру) в режиме онлайн проверить не был ли представленный сервером SSL-сертификат отозван. Напомню, что отзыв сертификата – это специальная процедура, позволяющая исключить из списка доверенных сертификат, срок действия которого ещё не истёк. Это требуется, например, в том случае, если скомпрометирован закрытый ключ, соответствующий сертификату.

Логика OCSP довольно проста: получив сертификат, браузер обращается с запросом, содержащим серийный номер сертификата, по адресу специального ответчика (“респондера”), обычно работающего на серверах удостоверяющего центра (УЦ), и может получить ответ о том, не отозван ли этот сертификат. А может и не получить – дело в том, что ответчики OSCP некоторых УЦ работают не так надёжно, как хотелось бы. У OCSP есть и ещё одна особенность: владельцы ответчика получают информацию о том, какие пользователи ходят на сайты, где установлены соответствующие сертификаты (очевидно, что эту информацию передают браузеры, запрашивающие проверку отзыва сертификата).

OCSP stapling позволяет побороть оба неприятных аспекта, упомянутых в предыдущем абзаце. Ответ OCSP содержит электронную подпись, поэтому браузеру всё равно, по какому каналу этот ответ получен, главное, чтобы там была валидная подпись. Подпись действует некоторое время, соответственно, копию ответа может передавать веб-сервер, в момент установления TLS-соединения. Веб-сервер получает ответ OCSP от удостоверяющего центра, независимо от запросов посетителей веб-сайта. Просто и логично. OCSP имеет особое значение для так называемых сертификатов с расширенной проверкой (сертификаты EV), так что технология, прежде всего, актуальна именно для них, а точнее – для сайтов, их использующих.

Я некоторое время назад наладил демонстрационный сервер под доменом 1d.pw, там поддерживается и OCSP stapling – только сертификат там не EV, а простой. Посмотреть на работу OCSP stapling можно при помощи OpenSSL, вот так:

$ openssl s_client -connect 1d.pw:443 -tlsextdebug -status

В выдаче отыскиваем строки, следующие за “OCSP response”:

OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)

Адрес записки: https://dxdt.ru/2013/12/19/6420/

Похожие записки:

  • Открытые «исходники» и «бинарный» код с точки зрения ИБ
  • DNS-over-HTTPS в браузере Firefox, блокировки и будущее Сети
  • ИИ с превышением
  • Rowhammer-атака и код сравнения с нулём
  • Предсказание погоды от Google AI
  • «Авторизованный трафик» и будущее Интернета
  • Адреса DMARC rua в зоне cloudflare.com
  • Вычисления на различной аппаратуре
  • Экспериментальный сервер TLS 1.3: обновление
  • «Внешний ИИ» масштаба Apple
  • «Блокирующие» источники случайности в операционных системах

Введение в многопроцессорную систему OCSP

OCSP — это протокол, используемый для проверки действительности сертификатов, чтобы убедиться, что они не были отменены. OCSP является альтернативой Certificate Revocation Lists (CRLs) Ответы OCSP это всего нескольких сотен байтов, поэтому OCSP особенно полезен, когда у выдающего ЦС имеется относительно большие CRL, а также когда клиент имеет ограниченную память и вычислительную мощность.

OCSP также может предоставлять гораздо более своевременную информацию, чем CRL, о статусе сертификата, поскольку информация обычно выбирается чаще. Кроме того, OCSP может сообщить, действительно ли CA выдал сертификат. Это невозможно с помощью CRL, поскольку CRL содержит только список отозванных серийных номеров, тогда как ответчикам OCSP предоставляется серийный номер для проверки. Таким образом, можно сразу обнаружить использование определенных видов мошеннических сертификатов.

У OCSP есть несколько недостатков.
Во-первых, веб-браузер должен получать сам ответ, что может привести к задержкам в квитировании TLS с сервером и заставить пользователя ждать для отображаемой веб-страницы. Конкуренция среди браузеров заставила в значительной степени игнорировать отказы от ответа OCSP, создавая уязвимость безопасности.
Во-вторых, поскольку каждый клиент, посещающий веб-сайт, запрашивает ответ OCSP для сервера, который они посещают, количество запросов к респондентам будет зависеть от количества пользователей сайтов. Если крупные сайты пронумерованы среди клиентов ЦС, ЦС должен создать значительную инфраструктуру для обработки всех этих запросов.
Наконец, сбой в этой инфраструктуре может заставить клиента сомневаться в том, что сертификат действителен, если ответ недоступен.

Чтобы преодолеть проблемы с задержкой и производительностью, рабочая группа TLS рабочей группы Internet Engineering определила расширение статуса сертификата для протокола TLS, обычно называемое «Сшивание OCSP» Сшивание OCSP использует сервер TLS в качестве прокси для клиента, выбирая Ответ OCSP на сертификат своего сайта и передачу ответа клиентам, которые запрашивают ответ как часть рукопожатия TLS. Поскольку ответ получен непосредственно с сервера, клиенту не требуется запрашивать информацию у эмитента, что приводит к увеличению производительности сайта. Помимо преимуществ клиента и более быстрой загрузки страниц, сглаживание OCSP смягчает некоторые проблемы конфиденциальности, вызванные тем, что клиент сообщает CA, какие сайты посещают пользователь, а также снижает нагрузку на эмитента, уменьшая требования к инфраструктуре.

Сшивание OCSP в настоящее время поддерживается IIS 7+, Apache 2.4+, Nginx 1.7.3+.

Основным недостатком сшивки OCSP является то, что он немного увеличивает размер трафика веб-сайта — от нескольких сотен байтов до двух КБ за полное рукопожатие, в зависимости от размера ответа OCSP. Тем не менее, это увеличение незначительно по сравнению с количеством зашифрованных данных, отправленных по соединению, особенно если сервер настроен хорошо и использует возобновляемые сеансы SSL / TLS, что ограничит количество необходимых протоколов протокола TLS, что сократит затраты, как дорогостоящие операция закрытого ключа не требуется при возобновлении сеанса.

Другим недостатком является то, что основная сшивка OCSP работает только для сертификатов сайта и не проверяет достоверность промежуточных сертификатов ЦС в цепочке сертификатов, что также является требованием для надлежащей проверки сертификата. Это означает, что клиентам по-прежнему приходится отдельно проверять достоверность сертификата ЦС, загружая CRL или запрашивая ответы OCSP, в зависимости от того, что настроено в сертификате. Одной из возможных причин этого ограничения является то, что в то время, когда было определено расширение TLS сертификата, промежуточные сертификаты CA не включали информацию OCSP. Однако время изменилось, и теперь требуется информация OCSP в промежуточных продуктах.

Многократное скрепление OCSP

ЦС теперь выдают сертификаты, по крайней мере, с одним промежуточным ЦС в цепочке (или, по крайней мере, в большинстве случаев), а в базовых требованиях для CA / Browser Forum теперь требуются указатели OCSP в промежуточных сертификатах CA. При необходимой поддержке клиентов и серверов TLS можно было бы использовать скобки OCSP для промежуточных сертификатов ЦС. Проверка этой информации в связи со сшитым ответом OCSP называется «сшивание с несколькими типами».

Множественное сшивание должно быть таким же простым, как определение нового метода для расширения статуса сертификата и включение этого метода в список методов, поддерживаемых клиентом Расширение статуса сертификата в TLS не позволяло клиентам сигнализировать поддержку для двух методов. Это проблематично, потому что клиентам придется поддерживать как старые, так и новые методы сшивания, пока все клиенты не смогут поддерживать многошиточное сшивание. Новое расширение устраняет несколько проблем, позволяя клиентам использовать несколько методов проверки состояния и позволяя серверам пересылать несколько ответов OCSP клиенту.

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

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

Поддержка браузера для обоих OCSP и CRL смешанна: в настоящее время Firefox не загружает CRL из доверенных ЦС автоматически, поэтому пользователи Firefox должны полагаться только на OCSP; Google использует проприетарный механизм для распространения CRL для пользователей Google Chrome, который объединяет CRL CAC в одном обновлении, которое распространяется с использованием его автоматического канала обновления. Многие браузеры по умолчанию применяют «мягкий отказ», оставляя пользователей уязвимыми для подслушивающих устройств, способных блокировать или подделывать трафик OCSP. До тех пор, пока центры сертификации, отвечающие за ответы OCSP, не имеют надежной записи как для производительности, так и для надежности своих ответчиков OCSP, браузерам будет трудно оправдать переход на синхронное поведение «с жестким отказом»

Конфигурация сервера OCSP

  1. При использовании CRL — Certificate Revocation List — браузер загружает список серийных номеров отозванных сертификатов с сервера СА и проверяет не отозван ли текущий сертификат, что увеличивает время SSL-переговоров. Две основные проблемы CSR – это приватность и большая нагрузка на серверы центров сертификации. Чтобы связаться с CA и подтвердить статус сертификата требуется браузер. это нарушает конфиденциальность, поскольку ЦС знает к какому сайту вы обращаетесь и другу инфу (IP, браузер и др.). При большом количестве посетителей сайта CRL-сервер ЦС приходится обрабатывать все запросы посетителей в отдельности.
  2. OCSP — Online Certificate Status Protocol – это протокол, проверяющий, был ли отозван SSL-сертификат. OCSP stapling – это расширение TLS/SSL, целью которого является повышение производительности SSL-переговоров при сохранении конфиденциальности посетителя. Он был создан в качестве альтернативы CRL, с целью уменьшить время SSL-переговоров и уменьшить нагрузку на CRL сервер СА. Используя OCSP, браузер посылает запрос к вашему серверу (а не к серверу CRL центра сертификации) и получает ответ, содержащий состояние достоверности сертификата. Ваш сервер запрашивает не отозван ли сертификат у OCSP сервера CA и кэширует полученный ответ. Этот ответ «сшивается» (staple) с TLS/SSL рукопожатием. В результате серверы ЦС не перегружаются запросами, а браузеры больше не раскрывают деталий третьим лицам (CA).

Тестирование ответа OCSP при помощи OpenSSL

echo QUIT | openssl s_client -connect domain.com:443 -status 2> /dev/null | grep -A 17 ‘OCSP response:’ | grep -B 17 ‘Next Update’

FAQ по OCSP

Что такое OCSP Stapling
OCSP — Online Certificate Status Protocol — это модель расширения стандартного протокола OCSP, посредством которой веб-сервер получает ответ OCSP от ЦС и отправляет ответ OCSP браузеру в процессе рукопожатия SSL. Это может быть более эффективным, поскольку ответ OCSP действителен в течение нескольких часов или дней, а веб-сайт может кэшировать его и отправлять его всем пользователям в течение этого периода времени. Это повышает скорость и надежность OCSP, что устраняет необходимость того, чтобы клиентский браузер инициировал подключение к CA.

Зачем использовать OCSP Stapling
DigiCert рекомендует устанавливать OCSP нашим партнерам и клиентам, которые хотят воспользоваться этой улучшенной моделью OCSP, чтобы улучшить производительность браузера своих конечных пользователей при доступе к веб-сайту. Сшивание OCSP также затрагивает проблему конфиденциальности, поскольку CA больше не получает запросы проверки отзыва непосредственно от клиента (браузера).

Сертификаты DigiCert и OCSP
Инфраструктура DigiCert полностью поддерживает OCSP Stapling, и клиентам не нужен специальный SSL-сертификат, чтобы воспользоваться им. Фактически, им вообще не нужно участие DigiCert. Все, что им нужно сделать, это убедиться, что они используют одну из OCSP сшитых веб-серверных платформ, таких как Apache, Nginx или Windows Server, и что сшивание OCSP было настроено и включено на веб-сервере локально.

Конфигурирование OCSP stapling в Apache >=2.3.3

Существуют две директивы, которые необходимо добавить в конфигурационный файл apache

SSLUseStapling on
SSLStaplingCache «shmcb:/var/run/ocsp(128000)»

SSLUseStapling включает эту функцию, а SSLStaplingCache указывает, где хранить кеш и как большой он должен быть.

Note:Если вы используете Apache для Windows, убедитесь, что путь для SSLStaplingCache относится к пути к файлу Windows, например, «shmcb:C:/xampp/apache/logs/ocsp(128000)»]

Убедитесь, что SSLStaplingCache находится за пределами виртуального хоста или Apache, скорее всего, не запустится. Мы предлагаем поместить всю настройку за пределы раздела Virtual Host для простоты.
Примечание. При включении и / или настройке OCSP Stapling на ваших серверах имейте в виду, что запрос OCSP с вашего сервера на URL-адрес DigiCert OCSP должен быть разрешен. Если ваш сервер находится за брандмауэром. Вам необходимо создать исключение брандмауэра, чтобы сервер для исходящих подключений соответствовал URL-адресу DigiCert OCSP.

Сохраните файл конфигурации и перезапустите Apache, чтобы изменения вступили в силу

Проверка работы OCSP Stapling

Убедитесь, что вы используете самую последнюю версию openssl (0.9.8k или более поздней) для тестирования.

openssl s_client -connect yourdomain.com:443 -tls1 -tlsextdebug -status

В ответ обратите внимание на следующее:

OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)

Это означает, что сцепление OCSP включено. Если вы получите ответ, как показано ниже, то сшивание OCSP не выполняется:

OCSP response: no response sent

Конфигурация OCSP stapling в Nginx >=1.3.7

  1. В файле конфигурации Nginx необходимо добавить две директивы

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
ssl_trusted_certificate /etc/ssl/CA.crt

Файл CA.crt в приведенном выше примере должен содержать все соответствующие корневые и промежуточные сертификаты ЦС. Ниже приведен пример конфигурации Nginx для сшивания OCSP.

server <
listen 443 ssl;
server_name serverhostname;
ssl_certificate /etc/ssl/SSL_Cert.crt;
ssl_certificate_key /etc/ssl/cert_key.key;
ssl_trusted_certificate /etc/ssl/CA.crt
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
>

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

Проверка работы OCSP Stapling

Убедитесь, что вы используете самую последнюю версию openssl (0.9.8k или более поздней) для тестирования.

openssl s_client -connect yourdomain.com:443 -tls1 -tlsextdebug -status

Обратите внимание на область ответа OCSP:

OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)

Это означает, что сшивание OCSP включено. Если вы получите ответ, как показано ниже, то сшивание OCSP не включено:

OCSP response: no response sent

Конфигурирование OCSP stapling в Windows Server

  • Сшивание OCSP поддерживается и включено по умолчанию в Windows Server 2008 или выше .
  • Для Windows Server 2008 или выше не требуются шаги настройки
  • Версия сервера Windows ниже 2008 г. не поддерживает OCSP Stapling

Для сшивки OCSP для работы на вашем сервере Windows все, что вам нужно сделать, это проверить версию сервера, на котором вы работаете, — 2008 или выше. А также требуется разрешение OCSP с вашего сервера на сервер OCSP DigiCert. Если ваш сервер находится за брандмауэром. Вам необходимо создать исключение брандмауэра, чтобы ваш сервер мог отправлять исходящие соединения на URL OCSP DigiCert.

 DV OV EV WC SAN PRO CodeSign Email PDF Wi-Fi IoT ALL Купить сертификат

NO russia - мы не осблуживаем резидентов из россии

Copyright © 1997-2024 adgrafics

Настройка и оптимизация OCSP

OCSP (Online Certificate Status Protocol) – полезная технология, делающая работу с PKI-системами более быстрой.

Несмотря на то что данная технология древняя, и поддерживается всеми крупными CA более десяти лет, в большинстве применений речь далее чем о “ну, те, у кого мы сертификаты берём, OCSP-сервер подняли и он работает” не идёт.

Однако и у самого OCSP есть настройки, и у связанных с этим протоколом технологий – тоже.

Немного углубимся в тему – от вас потребуется примерное представление о PKI (лучше подробное, но не обязательно) и желание сделать что-то лучше (это уже обязательно).

Настраиваем и оптимизируем OCSP и связанные с ним технологии

  • OCSP и CRL – что, когда, зачем
    • OCSP-сервер – он же responder
    • OCSP-клиент
    • OCSP Stapling в IIS
    • OCSP Stapling в Nginx
    • OCSP Stapling со стороны клиента
    • OCSP Must-Staple для Let’s Encrypt / certbot

    Кратко про OCSP

    У сертификатов x.509, как и у любых сущностей, есть жизненный цикл. Они рождаются, живут, и умирают. Всё, как у людей.

    Помимо фактической смерти сертификата от старости (в фиксированное время) у него бывает преждевременная кончина – она называется “отзывом”. Нужен этот механизм для того, чтобы резко прекратить использовать сертификат – по причине, например, компрометации ключа, либо изменения сущности, которую подтверждает сертификат, или какой-либо ещё неустранимой проблемы, после которой использование сертификата – как связки “криптографический материал плюс информация о связанной с ним сущности” – становится бессмысленным. Сертификат вроде как жив и срок годности ещё не завершился, но использовать его можно разве что в справочных целях вида “вот смотрите, когда-то это было сертификатом”. У людей это реализуется через каминг-аут или фразу “кстати я веган, отлично себя чувствую”.

    Соответственно, возникает задача – как по сертификату определить, что его отозвали. Так как сертификат подписан, то редактировать его нельзя – следовательно, нельзя разместить прямо в нём какую-то информацию об отзыве в момент самого отзыва. Значит надо будет изначально предусмотреть в сертификате справочное поле, говорящее о внешней системе, обладающей информацией об отзыве. CA много, поднять CA может каждый, а значит информация эта будет специфична для каждого конкретного сертификата. Сертификат у нас идентифицируется уникальным id, по сути серийным номером, а раз так, то этой информации – id сертификата плюс данные о конкретном CA – хватит, чтобы проверить информацию об отзыве.

    Как это сделать?

    Первая и самая простая идея – формировать специальный документ в формате x.509v2 – называемый списком отозванных сертификатов (CRL). Это простой файл с линейным перечнем “кого отозвали”. Проблема в том что файл этот, выходит, постоянно растёт, и если у CA много сертификатов, то CRL-файл шустро увеличивается. Кроме того, ведь клиентам его надо обновлять по достаточно плотному расписанию, и чем чаще – тем лучше; нельзя же предположить, что через минуту не отзовут какой-либо сертификат, которым будет подписано пришедшее через пару минут письмо. Следовательно у этого файла появляется и явно прописанный “срок годности” – то время, через которое его точно надо обновить (скажем, неделя), плюс появляется задача “как можно чаще обновлять, чтобы оперативно отреагировать на свежеотозванный сертификат”.

    • Публиковать раздельные CRL по типам сертификатов – скажем, крупный CA может вести один CRL про отозванные сертификаты веб-серверов, а другой – про отозванные сертификаты электронной почты;
    • Публиковать т.н. “дельта-CRL” – файлы, содержащие только сертификаты, отозванные после определённой даты. По задумке создателей механизма, клиентское ПО должно это всё творчески анализировать и, скажем, раз в месяц подкачивать “основной” CRL, а раз в день – “текущую дельту”.

    Можно было также наделать много выдающих CA, чтобы “распределить” по их CDP – CRL Distribution Point’ам отозванных, но это уже совсем хардкор. Сама идея “разделить один огромный файл на части, чтобы перекачивать было проще” – рабочая, тут никто не спорит (впрочим, является явным “костылём”, т.к. не исправляет причину, а лишь временно отодвигает проблему роста CRL).

    По итогам оба этих варианта не сильно исправили ситуацию, ну а с дельта-CRL некоторое клиентское ПО так работать и не научилось.

    Всё скатывалось к тому что, приняв письмо размером в пять килобайт, подписанное цифровой подписью кого-то крупного – типа Verisign – надо подкачать здоровенный основной CRL и пачку дельта-CRL к нему, всё это собрать в единый массив и проверить подпись у письма, чтобы узнать, имеет ли смысл его читать, или нет. И все равно, даже если это старательно делать, то ситуацию “отозвали сертификат пару часов назад” можно упустить и принять поддельное сообщение за корректно подписанное.

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

    Представьте себе архив электронной почты за, скажем, пять лет. Если хранить только информацию об отзыве за последний год, а более старую вычищать из CRL, то анализ архива за прошедшие 2-3 года превратится в сложную задачу. Если среди полученных 2 года назад писем будет подписанное отозванным на момент получения сертификатом, то оно будет ошибочно воспринято как “нормальное”. Ведь информация о том, что на момент получения этого письма его подпись была выполнена уже отозванным сертификатом – отсутствует.

    Что делать? Очевидно – нужен сервис, лишённый всех этих вопросов по части “болезней роста”. Им и стала реализация протокола Online Certificate Status Protocol, или OCSP.

    OCSP реализуется через веб-сервис, умеющий получить запрос “отозван ли вот этот конкретный сертификат” и ответить “да” или “нет”. Особенно полезно, отметим, то, что ответы OCSP представляют из себя отдельные объекты, подписанные сервером и обладающие сроком годности – а значит они могут передаваться между системами, кэшироваться и обновляться, следуя какой-либо нужной в специфичной ситуации логике. Адрес OCSP-сервиса не заменяет собой CRL в сертификате – он является дополнительным методом проверки валидности, указываемым в AIA-расширении.

    Теперь кратко про то, как будут реализованы компоненты OCSP на практике.

    OCSP-сервер

    Поднять свой OCSP-сервер для локальной инфраструктуры PKI нетрудно – он будет встроен в, например, ОС Windows Server начиная с NT 6.0 и будет называться OCSP Responder. Про его настройку и так подробно говорится на курсах, но вкратце там всё очень просто – вы обеспечиваете OCSP Responder’у доступ к свежему CRL-файлу нужного CA (или файлАМ, если их несколько), выдаёте сервису специфичный OCSP-сертификат и сервис функционирует. По сути он получает запрос клиента, ищет id сертификата в локальном CRL-файле и отвечает “да” или “нет”, тривиально снимая с клиента задачу по загрузке полного CRL’а, сбору того из кусочков delta-CRL’ов и всякого подобного.

    Оптимизировать там, опять же, особенно нечего – этот сервис должен быть постоянно доступен и очень быстр, что вообще характерно для современных сервисов, так что перейдём к клиентской стороне.

    OCSP-клиент

    Поддержка анализа и обработки OCSP-записей в поле AIA у x.509v3-сертификатов появляется в Windows Vista; там же появляется и возможность управлять работой OCSP. Сделана она штатно, через механизм объектов групповой политики:

    Настройка проверки сертификатов на отзыв в Windows через механизм Group Policy

    Настройка проверки сертификатов на отзыв в Windows через механизм Group Policy
    (кликните для увеличения до 921 px на 678 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

    Нас будет интересовать блок настроек про выбор между OCSP и CRL (когда для конкретного сертификата доступны оба) и модификацию времени валидности данных об отзыве:

    Настройки OCSP и CRL-проверки сертификатов в Windows

    Настройки OCSP и CRL-проверки сертификатов в Windows
    (кликните для увеличения до 561 px на 563 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

    Шучу, не будет. Тонкая настройка “как именно выбирать между OCSP и CRL” нужна крайне редко – например, в сценарии “в локальной сети высокий уровень безопасности и используется IPsec transport mode для защиты определённых видов трафика” можно будет “заставлять” обращаться к закэшированному CRL (который заранее через ту же Group Policy раздаётся), экономя время на установку SA. Увеличение срока валидности OCSP/CRL сверх указанного также пригодится очень редко – например у мобильного устройства, перемещающегося между имеющими частичный доступ к Интернету региональными объектами одного крупного предприятия.

    Основное у клиента – это “Умеет ли читать OCSP-поле” / “Умеет ли обрабатывать множественный ответ OCSP-responder’а”. Сейчас это, в общем, почти у всех.

    Вроде всё хорошо – задачу с растущими CRL’ами решили. Но технологии не стоят на месте и на базе OCSP развиваются более интересные возможности.

    Первая по важности из них – это OCSP Stapling.

    OCSP Stapling

    Прикрепление OCSP-ответа – технология, развивающая применение OCSP и имеющая очевидные плюсы.

    Ключевой – скорость. Вместо того, чтобы запросить у сервера сертификат, проверить его по всем параметрам (валидный по формату, действительный, обладает всеми нужными полями и использует понятные для хоста криптоалгоритмы), а потом сходить к OCSP responder’у, чтобы узнать про “отозван или нет”, OCSP Stapling предлагает “прикреплять” к ответу TLS-сервера и сертификат и OCSP-ответ от responder’а про этот сертификат. Это экономит время клиента – ему не надо устанавливать сессию до OCSP responder’а, плюс делает систему чуть безопаснее – OCSP responder не может собирать информацию “кто и с каких адресов подключается к серверам, которым мы выдали наши сертификаты” – он видит лишь факт того, что сервер многократно спрашивает про свой собственный сертификат.

    Проблема со скоростью OCSP также завязана на то, что в первой реализации – RFC 6066 – OCSP разрешал в ответе только информацию про один сертификат. То есть клиент, даже получив от сервера полную цепочку сертификатов до какого-то trusted – ну или не от сервера, имея часть из сертификатов из этой цепочки локально – все равно делал несколько (обычно 3-4) запросов про каждый из них отдельно. В обновлённой спецификации, RFC 6961, которая “Multiple Certificate Status Request Extension”, OCSP responder может выдать информацию сразу про несколько сертификатов в одном ответе – но вопрос, насколько широко реализован обновлённый OCSP со стороны различного клиентского ПО (в частности, браузеров). Поэтому OCSP Stapling потенциально может выиграть ещё больше времени, экономя ещё и на количестве запросов.

    В дополнение, OCSP Stapling потенциально делает установку соединения более надёжной – потому что если вы подключились к веб-серверу, и работает OCSP Stapling, то информацию об отзыве вы получите от этого же сервера, а не подключаясь к стороннему сервису (который может не работать). Сервер кэширует валидный OCSP-ответ, поэтому в случае кратковременных перебоев OCSP responder’а, ответственного за сертификат X, обладающий этим сертификатом X сервер будет отправлять клиентам валидный OCSP-ответ, а если бы клиенты обращались напрямую к responder’у, то они бы получали отказ в обслуживании после достаточно длительного тайм-аута.

    OCSP Stapling, кстати, не просто “айтишная мелкая штука, ускоряющая работу”, а вполне серьёзная технология, упоминающаяся как нужная к реализации в разделе 3.4.1.2 стандарта NIST SP 800-52r1.

    Надо использовать. Как?

    OCSP Stapling в IIS

    OCSP Stapling поддерживается начиная с NT 6.0 и детали его реализации в IIS, судя по всему, IIS унесёт с собой в могилу. Известно лишь то, что вопросы о “когда вы доделаете поддержку Multiple Certificate Status Request Extension?” подвисали в воздухе на форумах MSDN ещё в 2017 году. Что, в принципе, можно считать достаточным для принятия решения не особо использовать IIS для таких штук.

    Что интересно, “неуправляемая” реализация OCSP Stapling в Microsoft IIS прошла все нужные сертификации американского Минобороны, о чём сообщается на специальной странице. Текущее состояние этой страницы довершает картину:

    Тут должна быть цитата Лаврова про Д.Б., но останемся в рамках приличий

    Тут должна быть цитата Лаврова про Д.Б., но останемся в рамках приличий
    (кликните для увеличения до 1026 px на 615 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

    OCSP Stapling в nginx

    В варианте с nginx всё куда как лучше.

    Включается OCSP Stapling, выключенный по умолчанию, вот так:

    Чтобы он (механизм OCSP Stapling) работал, нужна информация о “родительском” сертификате и прямое указание на DNS-сервер, через который будут разрешаться FQDN’ы из AIA-расширения.

    Существует также возможность перекрыть адрес OCSP-сервера для конкретного сертификата – в разделе конфигурации про нужный сервер можно задать команду:

    Это позволяет делать схемы вида “ферма nginx-серверов обращается к специальному серверу, кэширующему с запасом по времени OCSP-ответы и очень часто их проверяющему”, делая работу фермы более быстрой, снимая с nginx’ов несвойственные им задачи по сверхбыстрому рефрешу OCSP-ответов и улучшая надёжность всей системы. Грубо говоря, можно поставить специальный узел, который будет раз в 30 секунд бегать за OCSP-ответом про используемый сертификат (или сертификаты), и практически мгновенно реагировать на ситуацию “отозвали”, а также замаскирует реальные адреса серверов, которым нужна эта информация.

    Дополнительной мерой безопасности будет проверка OCSP-ответа:

    Это подстрахует от ситуации “нам отдали некорректно подписанный ответ и мы его, не читая, прикрепили к ответу для клиента, и клиент проверил его и понял, что он сбойный”.

    В случае правильной настройки внешние средства проверки будут определять поддержку OCSP Stapling примерно так:

    Поддержка OCSP Stapling обнаружена у сервера www.atraining.ru

    Поддержка OCSP Stapling обнаружена у сервера www.atraining.ru
    (кликните для увеличения до 1345 px на 997 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

    Что там у клиентской стороны?

    OCSP Stapling со стороны клиентов

    Основная задача для OCSP Stapling – это, конечно, упрощение жизни веб-браузеров. Большинство из них на этот момент (апрель 2018 года) давно уже имеют поддержку OCSP Stapling.

    Проверить свой браузер можно, например, по ссылке на браузерный тест SSLLabs. Браузер с поддержкой OCSP Stapling будет выдавать что-то такое:

    Поддержка OCSP Stapling обнаружена у браузера Opera, которым я пользуюсь

    Поддержка OCSP Stapling обнаружена у браузера Opera, которым я пользуюсь
    (кликните для увеличения до 963 px на 386 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

    В некоторых браузерах можно будет управлять этой возможностью – т.е. говорить явно “если с ответом сервера идёт какая-то доп.инфа, называющаяся OCSP Response, то читай/игнорируй её”. В Firefox, например, так:

    Вообще, как только речь идёт не о связке “веб-сервер – браузер”, лучше всего в явном виде убедиться, что OCSP Stapling поддерживается системой. К примеру, почтовый сервис Postfix не поддерживает OCSP вообще, исходя из логики “клиенту надо, пусть он и проверяет”. В плане почтового edge-сервера это, кстати, даже логично.

    Далее, если перейти от ПО к компонентам ПО, то тоже будут особенности реализации. Например, возможность управления OCSP Stapling будет встроена в Windows’овскую реализацию Kerberos – что удивительно, т.к. в системе глобально этой возможности нет.

    Вы сможете настроить следующее – использовать ли прикреплённый Kerberos-сервером ответ с OCSP-информацией, либо игнорировать и следовать к явно указанному в сертификате OCSP-серверу. Как понятно, всё это возможно только в случае, когда контроллер домена работает на NT 6.0 и выше, и имеет сертификат со специфичным OID’ом про Kerberos.

    В этом ключе будет параметр RequestOCSP , как обычно типа DWORD32, который можно установить в нуль и тогда клиент будет всегда сам лично ходить проверять сертификат DC на отзыв через OCSP responder. Это, по идее, безопаснее – но клиентам сразу же нужен быстрый доступ во внешние сети на моменте инициализации подключения к DC, то есть на фазе загрузки – а это не всегда так просто, особенно если детали доступа во внешние сети как раз и настраиваются через Group Policy, которая загружается уже после того, как тикет от Kerberos получен.

    Так что обычно единица в этом ключе и упрощает настройки, и ускоряет работу Kerberos – но, опять-таки – именно когда у вас “усиленный” вариант, с дополнительной валидацией DC через x.509v3.

    Далее – технология OCSP Must-Staple.

    OCSP Must-Staple

    OCSP Must-Staple (см. RFC 7633) – технология, нужная для дальнейшей оптимизации работы с TLS-серверами. Идея достаточно проста – в сертификат добавляется OID, который указывает на то, что к этому сертификату всегда должен идти “прикреплённый” OCSP-ответ. Браузер, таким образом, запрашивая сертификат сразу же получает сигнал о том, что сервер должен к этому ответу приложить OCSP – или, если не приложит, то это ленивый сервер и с ним надо разорвать связь. То есть клиентский браузер чётко знает – “я сам ходить за OCSP даже пробовать не буду – мне должны прислать валидный OCSP-ответ”. Что, как понятно, упрощает алгоритм подключения и исключает задержку на “решаем, так OCSP-ответ нам пришлют или самим сходить надо будет”.

    Ещё раз – именно должны. Ваш сервер, предъявляя такой сертификат, подписывается под то, что к TLS-ответу будет прикреплён OCSP.

    Добавить OCSP Must-Staple в сертификат несложно – это OID 1.3.6.1.5.5.7.1.24, со значением 5. Сделать это надо на фазе создания CSR, т.е. запроса на сертификат. В случае OpenSSL это будет выглядеть так – в openssl.conf в раздел “параметры запроса” надо будет добавить вот такую строчку:

    (в случае старых версий OpenSSL, до 1.1.0, надо будет явно написать OID, т.к. там название status_request ещё не известно – и строчка будет 1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05).

    Я, чтобы не портить “главный” openssl.conf , обычно делаю специальный вариант файла, используемого именно для определённого типа запросов – вот такой, например, используется для генерации сертификата для www.atraining.ru:

    [ req ] default_bits = 4096 default_keyfile = тут путь до файла с закрытым ключом/private.key distinguished_name = req_distinguished_name encrypt_key = no prompt = no req_extensions = req_v3_web
    [ req_distinguished_name ] countryName = CN stateOrProvinceName = Hong Kong localityName = Hong Kong organizationName = Advanced Training commonName = www.atraining.ru
    [ req_v3_web ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names 1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05
    [ alt_names ] DNS.1 = www.atraining.ru DNS.2 = atraining.ru

    Почему отдельный файл с настройками, а не исправление глобального openssl.conf ? Причина проста – расширение OCSP Must-Staple необязательно нужно для всех сертификатов, создаваемых на этой конкретной системе. К примеру, часть почтовых систем – те же postfix и dovecot – не хотят брать на себя работу по облегчению проверки сертификатов со стороны клиента, и добавление OCSP Must-Staple будет, фактически, нарушением логики их работы – они будут показывать сертификат, где написано “я, сервер, обязан к этому сертификату приложить закэшированный OCSP-ответ”, но прикладывать не будут, т.к. не умеют и не планируют уметь.

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

    В приведённом примере, как видно, я объявляю раздел req_v3_web , куда вписываю “добавлять OID от OCSP Must-Staple” в формате, пригодном для любых версий OpenSSL.

    Использовать этот конфигурационный файл можно примерно так:

    openssl genrsa -out atraining-ru.key 4096 openssl req -new -sha512 -key atraining-ru.key -out atraining-ru.csr -config atraining-ru.conf

    Т.е. первой строчкой создаём ключевую пару RSA на 4096 бит, второй – делаем из открытого ключа запрос на сертификат, учитывая конфигурацию в файле atraining-ru.conf (приведён выше).

    После этот CSR можно использовать для запроса сертификата у любого CA. Варианты запроса через веб, где надо открыть CSR в блокноте и закопипастить в окошко, рассматривать не будем из-за тривиальности – рассмотрим в качестве примера распространённый сервис Let’s Encrypt.

    OCSP Must-Staple для Let’s Encrypt / certbot

    Если пользуетесь для HTTPS-сертификатов бесплатным Let’s Encrypt, то там ситуация будет ещё проще. Вы можете что вручную добавлять в строку запроса сертификата параметр —must-staple , что добавить в файл cli.ini (или в конкретный conf-файл в каталоге /renewal) строчку:

    Разве что учитывайте, что файл cli.ini будет перекрывать собой настройки для конкретных сертификатов – т.е. если на одной системе у вас пачка доменов, и certbot регулярно пробегает и обновляет сертификаты, то заданное в cli.ini будет перекрывать всё остальное. С “айтишной” точки зрения это непривычно – общая настройка “для всей системы” перекрывает более специфичные частные. Однако тут логика чуть другая – файл cli.ini – это “то, что по умолчанию добавлять как будто бы админ это руками к каждому запросу дописывает”. Так что прописывайте OCSP Must-Staple в cli.ini только если это точно надо для всех сертификатов на данной системе, если же нет – то добавьте только в нужные.

    Выглядеть это в результате будет примерно так:

    Поддержка OCSP Must-Staple со стороны сервера

    Поддержка OCSP Must-Staple со стороны сервера
    (кликните для увеличения до 1004 px на 879 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

    Никаких специальных действий именно в настройках сервера – не нужно. Расширение OCSP Must-Staple – это просто атрибут в сертификате, чтобы клиент точно знал, что “я всегда присылаю OCSP вместе с сертификатом” и упрощал логику выбора поведения.

    OCSP Expect-Staple

    Творческий товарищ Scott Helme в 2017 году предложил ввести новый HTTP security header – Expect-Staple . Суть проста – внутри HTTP-информации поместить поле, в котором можно было бы сказать браузеру, куда жаловаться, если наличие OCSP Stapling’а заявлено, но по факту отсутствует.

    Заголовок сделан полностью по аналогии с HSTS, про который подробно есть в статье про настройку TLS. Выглядеть он будет например так:

    max-age=31536000; report-uri=»https://www.atraining.ru/report-uri/expect-staple»; includeSubDomains; preload

    Это, как понятно, само тело заголовка – а его добавление в случае nginx будет выглядеть, например, так:

    add_header Expect-Staple ‘max-age=31536000; report-uri=»https://www.atraining.ru/report-uri/expect-staple»; includeSubDomains; preload’;

    Формат вполне прост – указывается report-uri , куда слать JSON-крики о помощи, preload говорит о том, что “надо бы нас добавить в гуглолист хороших HTTPS-сайтов” (про это также есть в статье про настройку TLS), max-age указывает срок (хотя бы год, чтобы добавили), а includeSubDomains – что мы не будем тратить трафик на указание этого же заголовка в HTTP-ответах всех субдоменов. В моём случае заголовок отдаётся у atraining.ru , но не отдаётся у служебных cdn.atraining.ru и c.atraining.ru .

    В идеальном случае после добавления этого заголовка и повторного обхода hstspreload.org запись про ваш домен будет доступна подключающимся самый первый раз браузерам и они сразу же будут и подключаться по TLS, и ждать OCSP-ответа, и ругаться по указанному в Expect-Staple report-uri про то, что такого ответа нет (про настройку report-uri можно прочитать здесь). Фактически, первичное подключение станет быстрее и безопаснее. Вот здесь можно посмотреть на процесс реализации Expect-Staple в Chromium.

    Выглядит добавленный заголовок Expect-Staple примерно так:

    Поддержка HTTP-заголовка Expect-Staple со стороны сервера

    Поддержка HTTP-заголовка Expect-Staple со стороны сервера
    (кликните для увеличения до 1211 px на 968 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

    Что ж, теперь можно про всякое дополнительное.

    Вспомогательные вопросы при работе с OCSP

    Действия, нужные со стороны сервера и клиентов – примерно понятны. Что пригодится админу?

    Как определить время кэширования OCSP-ответа

    Вы можете вручную посмотреть прикреплённый OCSP-ответ и увидеть срок годности. Например так:

    echo QUIT | openssl s_client -connect www.atraining.ru:443 -tls1_2 -status 2> /dev/null | grep -A 17 ‘OCSP response:’ | grep -B 17 ‘Next Update’

    Параметры команды достаточно тривиальны – посылается запрос на www.atraining.ru:443 , используется TLS 1.2, отправка QUIT в самом начале нужна, чтобы соединение после получения информации сразу же прервалось, а grep ‘ом мы просто выводим только нужный кусок из рулона текста.

    Надо ли предварительно подготавливать OCSP-ответы

    В различных источниках бытует мнение о том, что OCSP – плохая технология, потому что самый первый клиент будет подключаться, а OCSP-ответа нет. Поэтому предлагаются схемы типа “давайте после старта веб-сервиса сами к себе обратимся, сымитировав самого первого клиента, чтобы этот вопрос был снят”.

    Идея неплохая, но есть мнение, что проще ускорить процесс кэширования OCSP-ответа, а также грамотно настроить тайм-ауты. Тайм-ауты OCSP – это время, за которое веб-сервер, получив запрос от клиента на OCSP Stapling, должен сбегать к OCSP responder’у и принести этот ответ. Соответственно, вопросы быстродействия сети, скорости разрешения DNS-имён и поиска рабочего OCSP responder’а из нескольких – весьма актуальны. Не бойтесь выставить тайм-ауты на 10 или даже 15 секунд – это не приведёт к замедлению работы с клиентом, это приведёт к снижению до нуля числа отбоев по причине “извини, братишка, не успел OCSP тебе передать – вот тебе TLS-ответ формата “уж как могу””.

    В nginx существует возможность брать OCSP Stapling из файла – это делается через команду ssl_stapling_file и предполагает некий фоновый скрипт, который регулярно (это несложно, зная срок годности OCSP-ответа) ходит наружу и перезаписывает этот файл в случае получения удачного ответа. Применять ли этот метод – решать вам; в больших развёртываниях зачастую проще сделать отдельные системы, прекэширующие все OCSP-ответы для нужных сертификатов и очень быстро доступные для линейки проксирующих и выполняющих SSL termination серверов.

    Теперь чуток про безопасность OCSP.

    Вопросы безопасности OCSP

    Казалось бы – удивительное дело; речь ведь идёт о технологии, которая в подавляющем большинстве случаев ускоряет проверку отзыва сертификата. Вроде как никаких дополнительных вопросов безопасности здесь быть не должно. Однако они есть, и их надо учитывать.

    Концептуальная проблема зависимости от третьей стороны

    В прекрасно мире высокотехнологичного будущего PKI занимает особое место – помимо ореола чистой науки и математики, PKI базируется на истинной независимости от сторонних участников в вопросе проверки подлинности. В самом деле, вы можете проверить сертификат на валидность лишь обладая нужным ПО, реализующим хорошо известные криптоалгоритмы. Каждая проверка – что повторное вычисление хэша, что проверка цифровой подписи – упрётся в строгую математику, которая скажет, что “если хэши разные – то речь точно о разных входных данных”, или “если то, что обработано открытым ключом, не сходится добитово с тем, что было обработано закрытым – значит, это не пара ключей”.

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

    В случае же OCSP мы получаем посредника, который не показывает нам оригинальный CRL-файл. Он получает от нас запросы и отвечает, подтверждая лишь свою подлинность. Ответ OCSP responder’а не содержит подтверждения подлинности ответа – лишь то, что ответ получен в определённое время и не был прочитан/модифицирован по пути от вас, запрашивающего, до него, отвечающего.

    Проблема разглашения информации при OCSP-запросе

    Вы отчитываетесь “какой я сертификат сейчас обрабатываю”, отправляя его идентификатор на OCSP-сервер. Он ведёт логи и имеет список “в какое время с какого адреса какой сертификат проверяли” – что, при доступности базы CA “какой сертификат с каким id я выдал какому домену”, даёт отличную картинку “вот на какие домены ходят с этого сетевого адреса”. При приближении числа SSL/TLS-сайтов к 100% – картинка становится всё более чёткой. Да, а вкупе с тем, что для внутренних систем предприятия – от электронной почты до RDP-серверов – тоже принято запрашивать “нормальные сертификаты от внешних PKI” – то картинка прекрасно дополняется журналированием “на какие внутренние сервера, опубликованные снаружи, ходит”.

    Да, и чем более подробно информация о сертификатах дробится – например, “а чё мелочиться, на каждый FQDN по сертификату запросим, бесплатные же” – тем картинка ещё детальнее, потому что вообще однозначная связь “сертификат с серийником N = домену www.example.com”.

    Работаете через VPN? Не беда; вы навряд ли пользуетесь PPTP, а значит попадаете на проверку на отзыв сертификата сервера, и делаете это исключительно разово при установке соединения. Ну, а обращаясь к локальным ресурсам уже после того, как VPN заработал – даже если по адресу вида https://192.168.0.1/ – вы все равно, получая сертификат, автоматически проверяете его через соединение, которое используется для работы с Интернет, а значит все равно показываете наружу “какой внутренний сервер я открываю и когда”. Вся информация опять-таки прозрачно сводится воедино, т.е. запросы выходят из-под одного адреса.

    Как понятно, в серьёзных решениях по части безопасности вопрос маскировки OCSP-запросов и связанных с ними DNS-запросов – действительно актуален. И сбрасывать со счетов свою собственную, хорошо работающую PKI-инфраструктуру – рано, несмотря на крики про “да есть бесплатные вроде работающие в принципе нормальные сервисы”. Есть, но вопросы их монетизации – как всегда, под покровом лозунгов про Свободу и Открытость – достаточно очевидны. И “в принципе нормальные” – это не “отличные” и даже не хорошие – а “и так сойдёт”. Что далеко не во всех случаях пригодно для применения.

    Резюме

    Правильная настройка работы OCSP и связанных с этой технологией механизмов может улучшить безопасность и увеличить скорость работы HTTPS-сайтов. Так как сейчас практически весь Интернет состоит именно из них – то не забудьте об этой “мелочи”.

    Похожие публикации:
    1. Isna python что это
    2. Как поставить перевернутый восклицательный знак на клавиатуре
    3. Какие преимущества дает применение практики модульного тестирования
    4. Какой из перечисленных языков программирования является машинно ориентированным

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *