Приглашение к обсуждению методики составления индекса HTTPS-защищенности сайтов

    Мы выпустили уже несколько обзоров поддержки 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.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 14

      0
      … и вот таким вот нехитрым образом мы изобрели аналог критериев github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide или любого другого подобного теста с щепоткой вкусовщины.
        0
        Да, ничего принципиально нового мы не изобрели и не пытались. Конкретно с методикой Qualys мы расходимся в первую очередь в том, что к какой группе относить. Например, мы смешиваем в одну кучу все не-AEAD шифронаборы, не деля их на слабые/небезопасные. По их методике многие протестированные нами сервера попали в группы А и А+, по нашей — никто не попал даже в А и всего один сервер в группу Б ;) Кроме того, они делят лишь на группы, мы же хотим добавить еще и числовое значение индекса, чтобы внутри группы сервера можно было хоть как-то сравнить.
        0

        А чем не подходит:


        https://www.immuniweb.com/ssl/?id=mr7ExbBc


        Меня устраивает мой результат вполне :)


        DNSSEC и TLSA этим тестом не проверяется, но у меня это тоже есть.

          0
          Крутой результат ;) Вполне подходит как один из тестовых инструментов.
            0
            1. А в вашем тесте мой сайт сколько набирает если не секрет ?


            2. По п. 5.8 — имхо если уж проверять то HSTS а не upgrade-insecure-requests так как:



            "The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header, which should still be set with an appropriate max-age to ensure that users are not subject to SSL stripping attacks."

              0
              1. В цифрах не скажу, т.к. пока методика не окончательная и процесс не автоматизирован, нужно считать руками, но точно не выше группы Б, ибо TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 и нистовские курвы ;) Кстати, а из каких соображений CBC поддерживаете?

              2. 5.х — это бонусные критерии, которые добавляют баллы, но не влияют на попадание в ту или иную группу. Т.е. подход такой: есть — хорошо, нет — не смертельно. Конкретно по 5.8: upgrade-insecure-requests — пока не стандартизированная директива и требовать ее наличия нельзя. Напротив, обе проверяемые директивы HSTS (4.7) стандартизированы и не вчера. Вот preload — это уже vendor-specific и может негативно повлиять на доступность сайта вообще, если админу зачем-то потребуется отключить HSTS, поэтому ее в критерии не включили до стандартизации. При этом 4.7 и 5.8 не взаимозаменяемы, как, скажем, варианты 4.3: можно поддерживать только CRL или только OCSP и не вылетить из группы.
                0
                1. Кстати, а из каких соображений CBC поддерживаете?


                Исключительно из-за того чтобы не потерять часть посетителей с apple устройств старых и IE 11 под WIN7/8 (писать мне стали что не открывается сайт) — через годик отключу.


                2.
                Ну как-то зря HSTS без preload — имхо надуманная ситуация про админа решившего отключить.


                3.
                За TLS 1.3 0-RTT (Early_Data) снижать баллы будете? (Я считаю что не надо снижать — ну не влияет повторное согласование на безопасность).

                  0
                  1. Хм, вот мой IE 11 под Win7:
                  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Forward Secrecy 256
                  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Forward Secrecy 128

                  2. Основная «претензия» к preload, что она vendor-specific и ЕМНИП не стандартизирована.

                  3. Нет, поддержка TLS 1.3 вообще рассматривается как бонус, а не must have.
                    0

                    1.
                    По сообщениям не попавшим на сайт пользователей (возможно без обновлений ОС и браузера). Да и не так это принципиально — через год CBC отключу !

                      0
                      А, вот в чем дело-то у Вас: семерка не умеет конкретно в сочетание TLS_ECDHE_RSA_WITH_AES_*_GCM хотя умеет в более крутое TLS_ECDHE_ECDSA_WITH_AES_*_GCM docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-7

                      Кстати, рекомендуется еще добавить что-нибудь на основе TLS_CHACHA20_POLY1305_* в TLS 1.2 — пользователи устройств без аппаратного AES скажут спасибо.
                        0
                        1. Да, так и есть — спасибо!


                        2. Я уже думаю через год не только CBC отключить а вообще tls 1.2 :)


                          0
                          2. Жестко, он все-таки сервер больше нагружает. Хотя кто знает, что будет через год: то ли хостинг дармовой, то ли в TLS 1.2 дыру найдут… ;)
                            0
                            1. Ну у меня выделенный сервер и LA = 0 даже в пиковой (для моего сайта) нагрузке :)


                            2. А может Минкомсвязи не сможет esni отдельно побороть и запретит весь tls 1.3 тогда мой план рухнет :)


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

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое