[Информационная безопасность] Приглашение к обсуждению методики составления индекса HTTPS-защищенности сайтов
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Мы выпустили уже несколько обзоров поддержки 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.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка веб-сайтов, Python, Открытые данные] Разработка онлайн-сервиса для инвесторов на pythonanywhere.com с использованием данных Yahoo Finance
- [Игры и игровые приставки, Информационная безопасность] PlayStation 5 разрешит записывать голосовые чаты и «стучать» на игроков
- [Adobe Flash, Информационная безопасность] Adobe исправила критическую уязвимость во Flash перед прекращением поддержки
- [Информационная безопасность] Фантазия на тему NTA: что должна делать идеальная система?
- [Информационная безопасность, Системное администрирование, Сетевые технологии, Сетевое оборудование] FortiMail — конфигурация для быстрого запуска
- [Разработка веб-сайтов, JavaScript, VueJS] Отдаем корректный код 404 в связке VUE SPA + SSR
- [Разработка веб-сайтов, CSS, HTML] 10 современных раскладок в одну строку CSS-кода (перевод)
- [Информационная безопасность, Носимая электроника] В китайских часах для детей Xplora 4 обнаружили бэкдор для получения фотографий и записи звука
- [Спам и антиспам, Информационная безопасность, Законодательство в IT] Microsoft применила закон США о товарных знаках, чтобы остановить сеть ботнетов Trickbot
- [Информационная безопасность, Open source, GitHub, Законодательство в IT] Microsoft понадобилось 10 дней, чтобы удалить исходники Windows XP с принадлежащего им GitHub
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_https, #_ssl, #_sajt (сайт), #_metodika (методика), #_kraudsorsing (краудсорсинг), #_obsuzhdenie_metodologii (обсуждение методологии), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:15
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Мы выпустили уже несколько обзоров поддержки 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. =========== Источник: habr.com =========== Похожие новости:
Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:15
Часовой пояс: UTC + 5