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

Но дальше возникают менее однозначные вопросы, например: поддержка TLS_RSA_EXPORT_WITH_RC4_40_MD5 – это полная «шляпа» или просто недостаток? А если этот шифронабор из 60-х 90-х первым предлагается клиенту для согласования? А если все остальные не сильно лучше? А что такое «сильно лучше»? Скажем, TLS_PSK_DHE_WITH_AES_128_CCM_8 – лучше или нет?

В результате родилась методика составления индекса, позволяющая формально оценивать степень надежности HTTPS-соединения по 31 пункту с разбивкой на 5 групп, от «это вообще не HTTPS» до «так держать!»

Чем точно не является индекс, так это «российским ответом» NIST/HIPAA/PCI DSS и т.п. по двум причинам.

Первая – индекс учитывает только надежность HTTPS-соединения. Производительность веб-сервера (NPN/ALPN/session resumption) и т.п. материи индекс не рассматривает, не для того он придумывался.

Вторая – NIST.SP.800 и прочие стандарты индустрии ориентируются на эллиптические кривые NIST, доверия к которым чуть более, чем никакого, зато есть вопросы с точки зрения ECDLP/ECC (задорную ремарку про шапочку из фольги можно невозбранно оставить в комментах).

Хотя кто знает, может со временем из индекса и вырастет суверенный стандарт с духовностью и скрепами «Кузнечиком» и «Магмой» (но не раньше, чем IETF признает их частью стандартных шифронаборов для TLS).

Основная идея индекса: в 2020 году «настоящим HTTPS» можно считать лишь TLS 1.2 и выше с соответствующим комплектом шифронаборов и эллиптических кривых. Старым шифронаборам, даже если они не имеют известных уязвимостей, пора на свалку истории. Рассуждения про необходимость поддержки legacy-клиетов – в пользу бедных: Windows XP до сих пор популярен, но его пользователи не шастают сегодня по Интернету через Internet Explorer 8 с его доисторическим Schannel, а используют для этих целей браузеры на основе Chromium/Firefox, использующими NSS. То же самое относится к пользователям старых версий Android – они либо поставили альтернативный браузер, не полагающийся на системную криптобиблиотеку, либо не могут пользоваться большинством современных сайтов даже через HTTP (без поддержки CSS3 и прочих современных свистоперделок).

С этих позиций и предлагается покритиковать проект методики. Все ли учли? Не слишком сильно круто закрутили гайки? Не переврали ничего? Ниже идет список критериев, а по ссылке – более развернутый текст, с примечаниями и комментариями.

1. Минимальные критерии

1.1. Поддерживается соединение по протоколу HTTP с шифрованием (HTTPS), обеспечиваемым использованием криптографического протокола TLS. HTTPS-соединение устанавливается с идентификатором протокола (схема URI) https по TCP-порту 443.

1.2. Шифрование соединения подтверждается действительным, не самоподписанным и не пустым TLS-сертификатом сайта стандарта X.509 версии 3, выданным авторитетным центром сертификации (CA).

2. Дополнительные критерии

2.1. Сервер не подвержен известным уязвимостям в реализации поддержки защищенного соединения (BEAST, POODLE, GOLDENDOODLE и т.п.)

2.2. TLS-компрессия не поддерживается.

2.3. Поддерживается только безопасное пересогласование (secure renegotiation) по инициативе сервера; пересогласование по инициативе клиента не поддерживается.

3. Рекомендуемые критерии

3.1. Соединение по протоколу HTTP автоматически (принудительно) переключается на HTTPS.

3.2. Публичный ключ TLS-сертификата сайта имеют длину ≥2048 бит. Сертификат подписан цифровой подписью по алгоритму ≥SHA256 с шифрованием по алгоритму RSA или ECDSA.

3.3. Поддерживается протокол TLS версии 1.2.

3.4. Протоколы SSL и TLS версии ≤1.1 не поддерживаются.

3.5. Поддерживаются стандартные шифронаборы на основе стойких алгоритмов.

3.6. Слабые, неподходящие и уязвимые шифронаборы не поддерживаются.

3.7. Поддерживаются ECDLP/ECC-безопасные эллиптические кривые.

3.8. Задан порядок согласования шифронаборов.

3.9. Используются устойчивые параметры алгоритмов согласования ключей на основе протокола Диффи-Хеллмана (DH).

3.10. Поддерживаются важные расширения TLS.

3.11. Поддерживается Server Name Indication (SNI).

4. Расширенные критерии

4.1. Опубликована полная и не избыточная цепочка TLS-сертификатов с их верной последовательностью в цепочке.

4.2. TLS-сертификат сайта поддерживает Certificate Transparency.

4.3. TLS-сертификат сайта поддерживает Certificate Revocation List (CRL) и Online Certificate Status Protocol (OCSP).

4.4. TLS-сертификаты в альтернативных цепочках соответствуют Критериям 1.2, 4.1.

4.5. ECDLP/ECC-небезопасные эллиптические кривые не поддерживаются.

4.6. Задан порядок согласования эллиптических кривых.

4.7. Заголовки ответа сервера (HTTP response headers) содержат заголовок HTTP Strict Transport Security с директивой includeSubDomains.

5. Бонусные критерии

5.1. TLS-сертификат сайта поддерживает OCSP Stapling.

5.2. TLS-сертификат сайта выдан с использованием процедуры проверки организации (OV) или расширенной проверки (EV).

5.3. Поддерживается протокол TLS версии 1.3.

5.4. Задан порядок согласования устойчивых шифронаборов от более устойчивых к менее устойчивым (по сопоставимым параметрам).

5.5. Ресурсные записи DNS для доменного имени сайта включают запись CAA (Certification Authority Authorization).

5.6. Ресурсные записи DNS для доменного имени сайта включают записи DS и TLSA (поддерживаются DNSSEC и DANE).

5.7. Поддерживается Encrypted Server Name Indication (ESNI).

5.8. Заголовки ответа сервера (HTTP response headers) содержат заголовок Content-Security-Policy с директивой upgrade-insecure-requests.