Мы выпустили уже несколько обзоров поддержки 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.
Но дальше возникают менее однозначные вопросы, например: поддержка TLS_RSA_EXPORT_WITH_RC4_40_MD5 – это полная «шляпа» или просто недостаток? А если этот шифронабор из
В результате родилась методика составления индекса, позволяющая формально оценивать степень надежности HTTPS-соединения по 31 пункту с разбивкой на 5 групп, от «это вообще не HTTPS» до «так держать!»
Чем точно не является индекс, так это «российским ответом» NIST/HIPAA/PCI DSS и т.п. по двум причинам.
Первая – индекс учитывает только надежность HTTPS-соединения. Производительность веб-сервера (NPN/ALPN/session resumption) и т.п. материи индекс не рассматривает, не для того он придумывался.
Вторая – NIST.SP.800 и прочие стандарты индустрии ориентируются на эллиптические кривые NIST, доверия к которым чуть более, чем никакого, зато есть вопросы с точки зрения ECDLP/ECC (задорную ремарку про шапочку из фольги можно невозбранно оставить в комментах).
Хотя кто знает, может со временем из индекса и вырастет суверенный стандарт с
Основная идея индекса: в 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.
