КриптоОфис

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

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

. Отсутствие

hard fail

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

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

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

Google chrome/cromium

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

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

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

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

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

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

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

Microsoft internet explorer/edge

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

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

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

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

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

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

Mozilla firefox

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Openssl: ручная проверка сертификата по ocsp

$ openssl version
OpenSSL 1.0.1g 7 Apr 2021

openssl s_client -connect wikipedia.org:443 2&t;&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p'

openssl s_client -connect wikipedia.org:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > wikipedia.pem

openssl x509 -noout -ocsp_uri -in wikipedia.pem
http://ocsp.digicert.com

openssl s_client -connect wikipedia.org:443 -showcerts 2>&1 < /dev/null

1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
-----BEGIN CERTIFICATE-----
MIIGWDCCBUCgAwIBAgIQCl8RTQNbF5EX0u/UA4w/OzANBgkqhkiG9w0BAQUFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTA4MDQwMjEyMDAwMFoXDTIyMDQwMzAwMDAwMFowZjEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTElMCMGA1UEAxMcRGlnaUNlcnQgSGlnaCBBc3N1cmFuY2Ug
Q0EtMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL9hCikQH17 NDdR
CPge yLtYb4LDXBMUGMmdRW5QYiXtvCgFbsIYOBC6AUpEIc2iihlqO8xB3RtNpcv
KEZmBMcqeSZ6mdWOw21PoF6tvD2Rwll7XjZswFPPAAgyPhBkWBATaccM7pxCUQD5
BUTuJM56H 2MEb0SqPMV9Bx6MWkBG6fmXcCabH4JnudSREoQOiPkm7YDr6ictFuf
1EutkozOtREqqjcYjbTCuNhcBoz4/yO9NV7UfD5 gw6RlgWYw7If48hl66l7XaAs
zPw82W3tzPpLQ4zJ1LilYRyyQLYoEt 5 F/ 07LJ7z20Hkt8HEyZNp496 ynaF4d
32duXvsCAwEAAaOCAvowggL2MA4GA1UdDwEB/wQEAwIBhjCCAcYGA1UdIASCAb0w
ggG5MIIBtQYLYIZIAYb9bAEDAAIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3
LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH
AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQBy
AHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBj
AGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAg
AEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQ
AGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBt
AGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBj
AG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBl
AHIAZQBuAGMAZQAuMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYIKwYBBQUHAQEEKDAm
MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgY8GA1UdHwSB
hzCBhDBAoD6gPIY6aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0SGln
aEFzc3VyYW5jZUVWUm9vdENBLmNybDBAoD6gPIY6aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0SGlnaEFzc3VyYW5jZUVWUm9vdENBLmNybDAfBgNVHSME
GDAWgBSxPsNpA/i/RwHUmCYaCALvY2QrwzAdBgNVHQ4EFgQUUOpzidsp xCPnuUB
INTeeZlIg/cwDQYJKoZIhvcNAQEFBQADggEBAB7ipUiebNtTOA/vphoqrOIDQ 2a
vD6OdRvw/S4iWawTwGHi5/rpmc2HCXVUKL9GYNy USyS8xuRfDEIcOI3ucFbqL2j
CwD7GhX9A61YasXHJJlIR0YxHpLvtF9ONMeQvzHB LGEhtCcAarfilYGzjrpDq6X
dF3XcZpCdF/ejUN83ulV7WkAywXgemFhM9EZTfkI7qA5xSU1tyvED7Ld8aW3DiTE
JiiNeXf1L/BXunwH1OH8zVowV36GEEfdMR/X/KLCvzB8XSSq6PmuX2p0ws5rs0bY
Ib4p1I5eFdZCSucyb6Sxa1GDWL4/bcf72gMhy2oWGU4K8K2Eyl2Us1p292E=
-----END CERTIFICATE-----

openssl ocsp -issuer chain.pem -cert wikipedia.pem -text -url http://ocsp.digicert.com

OCSP Request Data:                                                   # Данные запроса OCSP
    Version: 1 (0x0)                                                 # Версия: 1 (0x0)
    Requestor List:                                                  # Список просителя
        Certificate ID:                                              # Идентификатор сертификата
          Hash Algorithm: sha1                                       # Алгоритм хэширования: sha1
          Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96 # Хэш имени выпустившего сертификат: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96 
          Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7  # Хэш ключа выпустившего сертификат: 50EA7389DB29FB108F9EE50120D4DE79994883F7
          Serial Number: 0114195F66FAFF8FD66E12496E516F4F            # Серийный номер: 0114195F66FAFF8FD66E12496E516F4F
    Request Extensions:                                              # Расширения запроса
        OCSP Nonce:                                                  # Текущий OCSP
            0410DA634F2ADC31DC48AE89BE64E8252D12
OCSP Response Data:                                                  # Данные ответа OCSP
    OCSP Response Status: successful (0x0)                           # Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                               # Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                                 # Версия: 1 (0x0)
    Responder Id: 50EA7389DB29FB108F9EE50120D4DE79994883F7           # Идентификатор ответчика: 50EA7389DB29FB108F9EE50120D4DE79994883F7
    Produced At: Apr 9 08:45:00 2021 GMT                             # Создано: 9 апреля 2021 года в 08:45:00 по Гринвичу
    Responses:                                                       # Ответы:
    Certificate ID:                                                  # Идентификатор сертификата:
      Hash Algorithm: sha1                                           # Алгоритм хэширования: sha1
      Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96     # Хэш имени эмитента: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
      Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7      # Хэш ключа эмитента: 50EA7389DB29FB108F9EE50120D4DE79994883F7
      Serial Number: 0114195F66FAFF8FD66E12496E516F4F                # Серийный номер: 0114195F66FAFF8FD66E12496E516F4F
    Cert Status: good                                                # Статус сертификата: хороший
    This Update: Apr 9 08:45:00 2021 GMT                             # Это обновление: 9 апреля 2021 года в 08:45:00 по Гринвичу
    Next Update: Apr 16 09:00:00 2021 GMT                            # Следующее обновление: 16 апреля 2021 года в 09:00:00 по Гринвичу

    Signature Algorithm: sha1WithRSAEncryption                       # Алгоритм подписи: sha1WithRSAEncryption
         56:21:4c:dc:84:21:f7:a8:ac:a7:b9:bc:10:19:f8:19:f1:34:
         c1:63:ca:14:7f:8f:5a:85:2a:cc:02:b0:f8:b5:05:4a:0f:28:
         50:2a:4a:4d:04:01:b5:05:ef:a5:88:41:d8:9d:38:00:7d:76:
         1a:aa:ff:21:50:68:90:d2:0c:93:85:49:e7:8e:f1:58:08:77:
         a0:4e:e2:22:98:01:b7:e3:27:75:11:f5:b7:8f:e0:75:7d:19:
         9b:74:cf:05:dc:ae:1c:36:09:95:b6:08:bc:e7:3f:ea:a2:e3:
         ae:d7:8f:c0:9d:8e:c2:37:67:c7:5b:d8:b0:67:23:f1:51:53:
         26:c2:96:b0:1a:df:4e:fb:4e:e3:da:a3:98:26:59:a8:d7:17:
         69:87:a3:68:47:08:92:d0:37:04:6b:49:9a:96:9d:9c:b1:e8:
         cb:dc:68:7b:4a:4d:cb:08:f7:92:67:41:99:b6:54:56:80:0c:
         18:a7:24:53:ac:c6:da:1f:4d:f4:3c:7d:68:44:1d:a4:df:1d:
         48:07:85:52:86:59:46:d1:35:45:1a:c7:6b:6b:92:de:24:ae:
         c0:97:66:54:29:7a:c6:86:a6:da:9f:06:24:dc:ac:80:66:95:
         e0:eb:49:fd:fb:d4:81:6a:2b:81:41:57:24:78:3b:e0:66:70:
         d4:2e:52:92
wikipedia.pem: good                                                  # wikipedia.pem: хороший
    This Update: Apr 9 08:45:00 2021 GMT                             # Это обновление: 9 апреля 2021 года в 08:45:00 по Гринвичу
    Next Update: Apr 16 09:00:00 2021 GMT                            # Следующее обновление: 16 апреля 2021 года в 09:00:00 по Гринвичу

openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp.digicert.com
wikipedia.pem: good                                                              # wikipedia.pem: хороший
    This Update: Apr 9 08:45:00 2021 GMT                                         # Это обновление: 9 апреля 2021 года в 08:45:00 по Гринвичу
    Next Update: Apr 16 09:00:00 2021 GMT                                        # Следующее обновление: 16 апреля 2021 года в 09:00:00 по Гринвичу

Response verify OK                            # Ответ проверки успешен
test-revoked.pem: revoked                     # test-revoked.pem: отозван
    This Update: Apr 9 03:02:45 2021 GMT      # Это обновление: 9 апреля 2021 года в 03:02:45 по Гринвичу
    Next Update: Apr 10 03:02:45 2021 GMT     # Следующее обновление: 10 апреля 2021 года в 03:02:45 по Гринвичу
    Revocation Time: Mar 25 15:45:55 2021 GMT # Время отзыва: 25 марта 2021 года в 14:45:55 по Гринвичу

openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://rapidssl-ocsp.geotrust.com
Responder Error: unauthorized (6)                                                         # Ошибка ответа: не авторизован (6)

OCSP Request Data:                                                   # Данные запроса OCSP
    Version: 1 (0x0)                                                 # Версия: 1 (0x0)
    Requestor List:                                                  # Список просителя:
        Certificate ID:                                              # Идентификатор сертификата
          Hash Algorithm: sha1                                       # Алгоритм хэширования: sha1
          Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96 # Хэш имени выпустившего сертификат: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
          Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7  # Хэш ключа выпустившего сертификат: 50EA7389DB29FB108F9EE50120D4DE79994883F7
          Serial Number: 0114195F66FAFF8FD66E12496E516F4F            # Серийный номер: 0114195F66FAFF8FD66E12496E516F4F
    Request Extensions:                                              # Расширения запроса
        OCSP Nonce:                                                  # Текущий OCSP
            041015BB718C43C46C41122E841DB2282ECE
Responder Error: unauthorized (6)                                    # Ошибка ответа: не авторизован (6)

openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp.digidentity.eu/L4/services/ocsp
Response Verify Failure                                                                                          # Ответ проверки неудачен
140735308649312:error:2706B06F:OCSP routines:OCSP_CHECK_IDS:response contains no revocation data:ocsp_vfy.c:269:
140735308649312:error:2706B06F:OCSP routines:OCSP_CHECK_IDS:response contains no revocation data:ocsp_vfy.c:269:
wikipedia.pem: ERROR: No Status found.                                                                           # wikipedia.pem: ОШИБКА: Статус не найден.

OCSP Response Data:                                                   # Данные ответа OCSP
    OCSP Response Status: successful (0x0)                            # Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                                # Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                                  # Версия: 1 (0x0)
    Responder Id: C = NL, O = Digidentity B.V., CN = Digidentity OCSP # Идентификатор ответчика: C = NL, O = Digidentity B.V., CN = Digidentity OCSP
    Produced At: Apr 9 12:02:00 2021 GMT                              # Сформирован: 9 апреля 2021 года в 12:02:00 по Гринвичу
    Responses:                                                        # Ответы
    Request Extensions:                                               # Расширения запроса
OCSP Nonce:                                                           # Текущий OCSP
    0410EB540472EA2D8246E88F3317B014BEEF
Signature Algorithm: sha256WithRSAEncryption                          # Алгоритм подписи: sha256WithRSAEncryption

openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp.quovadisglobal.com/
Response Verify Failure                                                                            # Ответ проверки неудачен
140735308649312:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:152:
wikipedia.pem: unknown                                                                             # wikipedia.pem: неизвестно
    This Update: Apr 9 12:09:18 2021 GMT                                                           # Это обновление: 9 апреля 2021 года в 12:09:18 по Гринвичу

OCSP Response Data:                                                                                         # Данные ответа OCSP
    OCSP Response Status: successful (0x0)                                                                  # Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                                                                      # Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                                                                        # Версия: 1 (0x0)
    Responder Id: C = CH, O = QuoVadis Limited, OU = OCSP Responder, CN = QuoVadis OCSP Authority Signature # Идентификатор ответчика: C = CH, O = QuoVadis Limited, OU = OCSP Responder, CN = QuoVadis     OCSP Authority Signature
    Produced At: Apr 9 12:09:10 2021 GMT                                                                    # Сформирован: 9 апреля 2021 года в 12:09:10 по Гринвичу
    Responses:                                                                                              # Ответы
    Certificate ID:                                                                                         # Идентификатор сертификата:
      Hash Algorithm: sha1                                                                                  # Алгоритм хэширования: sha1
      Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96                                            # Хэш имени эмитента: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
      Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7                                             # Хэш ключа эмитента: 50EA7389DB29FB108F9EE50120D4DE79994883F7
      Serial Number: 0114195F66FAFF8FD66E12496E516F4F                                                       # Серийный номер: 0114195F66FAFF8FD66E12496E516F4F
    Cert Status: good                                                                                       # Статус сертификата: неизвестно
    This Update: Apr 9 12:09:10 2021 GMT                                                                    # Это обновление: 9 апреля 2021 года в 12:09:10 по Гринвичу

    Response Extensions:                                                                                    # Расширения ответа

Для чего нужны штампы времени

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

Фиксация времени формирования электронной цифровой подписи (электронной подписи) электронного документа. Штамп времени может использоваться в качестве доказательства, определяющего момент подписания электронного документа (1-ФЗ “Об ЭЦП”, Статья 4; 63-ФЗ “Об ЭП”, Статья 11).

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

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

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

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

И такую подпись можно будет успешно проверять в течение срока действия ключа проверки подписи Службы штампов времени. А что делать, когда сертификат Службы штампов времени истечет? Ответ прост: до истечения этого сертификата получить ещё один штамп времени на указанный документ (уже с использованием нового закрытого ключа и сертификата Службы штампов времени): этот новый штамп зафиксирует время, на которое старый сертификат службы штампов времени был действителен, и обеспечит целостность этого электронного документа при дальнейшем хранении в течение срока действия сертификата нового штампа времени.

Добиваемся ocsp stapling = yes для сертификатов от wosign на nginx

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 

#########################################################
#
#
 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;
#
#
#########################################################

        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;";

service nginx restart

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

Как же достичь рейтинга а ?

Как же, в итоге, достичь рейтинга «А »? Нужно выполнить следующую оптимизацию:

1. Отключить уязвимые SSL-протоколы (SSL v1, v2, v3)
2. Актуализировать набор шифров.
3. Сгенерировать надёжный ключ dh_param.
4. Включить механизм HSTS.
5. Ускорить SSL-переговоры с помощью OCSP Stapling.
6. Ускорить SSL-переговоры с помощью SPDY.
7. Включить кэширование.

Вот результат проделанной нами работы:

На что следует обратить внимание?

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

Поэтому, я рекомендую выбрать в Mozilla-конфигураторе уровень шифрования intermediate, а не modern. Это будет достаточно надёжно, но при этом вы получите рейтинг «А». Это не критично, к тому же вы не потеряете потенциальных посетителей вашего сайта.

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

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

hard fail

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

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

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

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

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

О безопасности сервера

Установка SSL-сертификата на сервер ещё не означает, что данные ваших клиентов в полной безопасности. Поэтому хотел бы дать несколько советов.

• Разграничивайте свои сервисы по разным VPS-серверам. Кстати, «1С-Битрикс» как минимум умеет разворачивать веб-кластер из коробки. Пример из технической поддержки: часто клиенты сообщают о проблемах со спамом. Либо их заспамили, либо они получили уязвимость на сайте и им загрузили скрипт, рассылающий спам. В итоге у клиента забиваются либо inode, либо дисковое пространство. Но по сути это проблема не спама, а неработоспособности самого сайта, когда элементарно не могут выполняться операции ввода-вывода. Сайт не работает, база данных не работает.
• Всегда проставляйте корректные права на файлы и директории. На директории — 755 на файлы — 644. К счастью, «1С-Битрикс» это тоже умеет делать по умолчанию. Никогда не оставляйте файлы без пользователей группы, этим тоже могут воспользоваться злоумышленники.
• Не ставьте лёгкие для понимания человека пароли, которые поддаются подбору.
• Ограничивайте доступ к 22 порту, а также к другим портам IPtables, то есть к файрволу сервера.
• Также я бы советовал отключить и не пользоваться FTP, лучше перейти на SFTP.
• Откажитесь от telnet, используйте SSH.

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

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

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

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

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

Подготовка конфигурационных файлов

Необходимо создать конфигурационный файл для OpenSSL. Создадим файл /root/ca/openssl.cnf, скопируем в него следующее содержимое root-config.txt.Раздел [ca] является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела [CA_default]:

[ ca ]
#man ca
default_ca = CA_default

Раздел [CA_default] содержит ряд значений по умолчанию:

[ CA_default ]
# Directory and file locations.
dir               = /root/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.  
 private_key       = $dir/private/ca.key.pem  
 certificate       = $dir/certs/ca.cert.pem

# For certificate revocation lists.  
 crlnumber         = $dir/crlnumber  
 crl               = $dir/crl/ca.crl.pem  
 crl_extensions    = crl_ext  
 default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.  
 default_md        = sha256

name_opt          = ca_default  
 cert_opt          = ca_default  
 default_days      = 375  
 preserve          = no  
 policy            = policy_strict

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

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of man ca.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

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

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Параметры из секции [ req ] применяются когда создаются сертификаты или запросы на подписывание сертификатов.

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.  
default_md          = sha256

# Extension to add when the -x509 option is used.  
x509_extensions     = v3_ca

Секция [ req_distinguished_name ] определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.

Проверка корневого сертификата

# openssl x509 -noout -text -in certs/ca.cert.pem

Вывод показывает:

• Используемый алгоритм Signature Algorithm
• Даты периода действия сертификата Validity
• Длину публичного ключа Public-Key
• Эмитент сертификата Issuer, который является объектом, который подписал сертификат
• Предмет Subject, который относится к самому сертификату.

Эмитент (Issuer) и предмет (Subject) идентичны для самоподписанных сертификатов. Все корневые сертификаты являются самоподписанными.

Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Validity
Not Before: Apr 11 12:22:58 2021 GMT
Not After : Apr  6 12:22:58 2035 GMT
Subject: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)

Вывод также показывает расширения X509v3, т.к. было применено расширение v3_ca, и опции из секции [ v3_ca ] отражены в выводе.

X509v3 extensions:
X509v3 Subject Key Identifier:
38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Authority Key Identifier:
keyid:38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign

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

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

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

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

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

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

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

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

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

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

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

Для создания корневого сертификата (ca.cert.pem) используется корневой ключ (ca.key.pem). Следует указать длинный срок годности сертификата, например, 20 лет. После того, как истечет корневой сертификат, все сертификаты, подписанные центром сертификации становятся недействительными.

# cd /root/ca
# openssl req -config openssl.cnf 
-key private/ca.key.pem 
-new -x509 -days 7300 -sha256 -extensions v3_ca 
-out certs/ca.cert.pem
Enter pass phrase for ca.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Root CA
Email Address []:
# chmod 444 certs/ca.cert.pem

Создание корневой пары ключей

Выступая в качестве центра сертификации (CA) означает иметь дело с криптографическими парами приватных (частных) ключей и публичными сертификатами. Самой первой криптографической парой создадим корневую пару. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует идентичность нашего центра сертификации.

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

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

Создание промежуточного сертификата

Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци (intermediate/openssl.cnf).

# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 
-key intermediate/private/intermediate.key.pem 
-out intermediate/csr/intermediate.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Intermediate CA
Email Address []:

Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением v3_intermediate_ca для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации (/root/ca/openssl.cnf).

# cd /root/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca 
-days 3650 -notext -md sha256 
-in intermediate/csr/intermediate.csr.pem 
-out intermediate/certs/intermediate.cert.pem
Enter pass phrase for ca.key.pem: secretpassword
Sign the certificate? [y/n]: y
# chmod 444 intermediate/certs/intermediate.cert.pem

Для хранения базы данных сертификатов, выданных утилитой ca OpenSSL, используется файл index.txt. Не следует удалять или править вручную этот файл. Сейчас он должен содержать одну строку, которая относится к промежуточному сертификату.

V 250408122707Z 1000 unknown … /CN=Alice Ltd Intermediate CA

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

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

hard fail

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

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

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

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

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

Тестирование сервера

Можем ли мы быть полностью уверены в том, что данные наших пользователей и клиентов сайта находятся в безопасности из-за одного лишь факта установки SSL-сертификата? Для ответа на этот вопрос давайте рассмотрим три аспекта:

Для примера я выбрал сервер, на котором был предустановлен ряд приложений. Front-end —NGINX, back-end — Apache.

Ресурс SSL LABS принадлежит компании QUALYS, которая с 1999 года занимается облачной защитой, так что я считаю, что ему можно доверять. Прямо в панели можно установить SSL-сертификат, без каких-либо вмешательств в настройки сервера. Рейтинг довольно плохой — “С”.

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