HTTPS не всегда такой безопасный, как кажется. Уязвимости найдены у 5,5% сайтов HTTPS


    Один из топовых сайтов Alexa (центральный кружок), защищённый HTTPS, с поддоменами (серым) и зависимостями (белым), среди которых есть уязвимые (штриховая заливка)

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

    Но оказывается, что наличие «замочка» в адресной строке не всегда гарантирует защиту. Проверка 10 000 ведущих сайтов из рейтинга Alexa показала: многие из них подвержены критическим уязвимостям протоколов SSL/TLS, обычно через поддомены или зависимости. По словам авторов исследования, сложность современных веб-приложений многократно увеличивает поверхность атаки.

    Результаты исследования


    Исследование провели специалисты из Венецианского университета Ка' Фоскари (Италия) и Венского технического университета. Подробный доклад они представят на 40-м симпозиуме IEEE по безопасности и приватности, который пройдёт 20−22 мая 2019 года в Сан-Франциско.

    Были проверены 10 000 самых популярных сайтов HTTPS из списка Alexa и 90 816 связанных с ними хостов. Уязвимые криптографические конфигурации выявлены на 5574 хостах, то есть примерно на 5,5% от общего количества:

    • 4818 уязвимы для MITM
    • 733 уязвимы для полной дешифровки TLS
    • 912 уязвимы для частичной дешифровки TLS

    898 сайтов полностью открыты для взлома, то есть допускают инъекцию посторонних скриптов, а 977 сайтов загружают контент со слабо защищённых страниц, с которыми может взаимодействовать злоумышленник.

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

    Обнаружены и другие проблемы: у 10% форм для авторизации проблемы с безопасной передачей информации, что грозит утечкой паролей, 412 сайтов допускают перехват кукисов и «угон сессии», а 543 сайта подвержены атакам на cookie integrity (через поддомены).

    Проблема в том, что за последние годы в протоколах SSL/TLS и программном обеспечении выявлен ряд уязвимостей: POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE-2013-3587) и Heartbleed (CVE-2014-0160). Для защиты от них требуется ряд настроек на стороне сервера и клиента, чтобы избежать использования старых уязвимых версий. Но это достаточно нетривиальная процедура, потому что такие настройки предусматривают выбор из обширного набора шифров и протоколов, в которых достаточно сложно разобраться. Не всегда понятно, какие именно наборы шифров и протоколов считать «достаточно безопасными».

    Рекомендуемые настройки


    Не существует одного официально одобренного и согласованного списка рекомендуемых настроек HTTPS. Так, Mozilla SSL Configuration Generator предлагает несколько вариантов конфигурации, в зависимости от требуемого уровня защиты. Например, вот рекомендуемые настройки для сервера nginx 1.14.0:

    Современный режим


    Самые старые поддерживаемые клиенты: Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, and Java 8

    server {
    listen 80 default_server;
    listen [::]:80 default_server;
    
    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://$host$request_uri;
    }
    
    server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    
    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    
    
    # modern configuration. tweak to your needs.
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;
    
    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;
    
    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;
    
    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
    
    resolver <IP DNS resolver>;
    
    ....
    }

    Средняя поддержка


    Самые старые поддерживаемые клиенты: Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7

    server {
    listen 80 default_server;
    listen [::]:80 default_server;
    
    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://$host$request_uri;
    }
    
    server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    
    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    
    # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
    ssl_dhparam /path/to/dhparam.pem;
    
    # intermediate configuration. tweak to your needs.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;
    
    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;
    
    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;
    
    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
    
    resolver <IP DNS resolver>;
    
    ....
    }

    Старая поддержка


    Самые старые поддерживаемые клиенты: Windows XP IE6, Java 6

    server {
    listen 80 default_server;
    listen [::]:80 default_server;
    
    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://$host$request_uri;
    }
    
    server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    
    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    
    # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
    ssl_dhparam /path/to/dhparam.pem;
    
    # old configuration. tweak to your needs.
    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP';
    ssl_prefer_server_ciphers on;
    
    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;
    
    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;
    
    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
    
    resolver <IP DNS resolver>;
    
    ....
    }

    Рекомендуется всегда использовать полный набор шифров и последнюю версию OpenSSL. Набор шифров в настройках сервера указывает приоритет, в котором они будут использоваться, в зависимости от настроек клиента.

    Исследование показывает, что недостаточно просто установить сертификат HTTPS. «Хотя мы не обрабатываем куки как в 2005 году, а „пристойный TLS” стал общим местом, но выясняется, что этих базовых вещей недостаточно для обеспечения безопасности на удивление большого количества очень популярных сайтов», — говорят авторы работы. Для надёжной защиты канала между сервером и клиентом нужно внимательно отслеживать инфраструктуру из собственных поддоменов и сторонних хостов, с которых поставляется контент для сайта. Может быть, имеет смысл заказать аудит у какой-нибудь сторонней компании, которая специализируется на информационной безопасности.



    • +18
    • 7,8k
    • 9
    GlobalSign
    156,00
    Компания
    Поделиться публикацией

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

      0

      Пойду, пожалуй обновлю алгоритмы в конфигах…

        0
        тока широковат там списочек. лучше так:

        ssl_prefer_server_ciphers on;
        ssl_protocols TLSv1.1 TLSv1.2;
        ssl_ciphers 'kEECDH+ECDSA+AES128 kEECDH+ECDSA+AES256 kEECDH+AES128 kEECDH+AES256 +SHA !aNULL !eNULL !LOW !MD5 !EXP !DSS !PSK !SRP !kECDH !CAMELLIA !RC4 !SEED';
          0
          Только добавлять не 1.1, а 1.3.
        0

        А почему https нужно больше настроек, чем ssh'у?
        У меня sshd прекрасно работает на таком конфиге:


        ChallengeResponseAuthentication no
        UsePAM yes
        X11Forwarding yes
        PrintMotd no
        AcceptEnv LANG LC_*
        Subsystem   sftp    /usr/lib/openssh/sftp-server

        И я как-то удачно на дефолтах имею нормальный безопасный ssh. Что-то в SSL сломано, если ему нужно СТОЛЬКО опций.

          0
          Имхо, тут несколько смешано теплое с мягким. Авторы исследования подчеркивают, что основной источник опасности — загрузка скриптов с хостов, которые могут контролировать злоумышленники. В этом случае есть SSL или нет — не слишком существенно.

          Куча опций SSL нужна для отключения уязвимых алгоритмов, которые использует древнее ПО. Используя приведенные опции можно отключить легаси, если доступ из старого ПО не нужен.
          В ssh тоже, к примеру можно выбрать поддержку протоколов v1/v2(уже, похоже, нет), выбрать список поддерживаемых алгоритмов, отключить авторизацию по паролю и т.п.
            +1
            А почему https нужно больше настроек, чем ssh'у?

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

            Сравнительно большее число алгоритмов обусловлено, в том числе, принципиально большим числом пользователей TLS, по сравнению с SSH.

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

            Не стоит забывать и про то, что SSL с 1995 года существует и используется (хоть сейчас и принципиально шире, чем раньше), типов клиентов существует бесчисленное количество. SSH реально начал использоваться в середине 2000-х, а программы-клиенты SSH можно пересчитать по пальцам. Совместимость с клиентами важна для публичных веб-серверов, а для частных SSH-серверов — нет. Даже условно публичных SSH/SFTP серверов, по моему впечатлению — единицы, и у них те же проблемы с совместимостью и поддержкой устаревших алгоритмов, что и у веб-серверов. С SMTP серверами вообще дикая ситуация: их вообще никто десятилетиями не обновляет, а регуляторы требуют отключать старые алгоритмы, что невозможно без нарушения SMTP-связности, потому что старые сервера хотят TLS1.0, и, если его не дают, то отключаются, вместо того, чтобы откатиться к нешифрованному соединению.

            С другой стороны, PFS в SSH от рождения, а в SSL/TLS — нет. В этом смысле в SSL/TLS что-то было «сломано», это правда, и «починка» привела к дополнительной куче алгоритмов в списке. Но, опять же, 1995 есть 1995.

            Вообще говоря, SSL/TLS — это, как мне кажется, двигатель современного шифрования. Новые алгоритмы обкатываются на нём, хэкеры пытаются его взломать, а потом другие технологии, такие как SSH и PGP/GPG не торопясь принимают лучшие, проверенные в «боевых» условиях SSL/TLS решения.
            –1
            Рекомендуется всегда использовать полный набор шифров и последнюю версию OpenSSL.

            Но Firefox, например, не использует OpenSSL. У него и не только NSS. Поэтому правильнее говорить по крайней мере о последних версиях OpenSSL и NSS. Более того кто из них более продвинутый на данный момент — вопрос открытый.
            В наборе шифров отсутствуют российские шифрсьюты. А интересно было бы проверить по этой методике порталы ФНС, Госуслуг и иже с ними.

              0
              Такой вопрос, если есть страница, на ней вводятся какие-то данные, нажимается определенная кнопка и введенные данные отправляются на другую страницу, то есть некая синхронизация данных, так вот можно ли в браузере на первой странице при просмотре кода увидеть ссылку на ту вторую страницу? если да, то где именно это прописывается?
                +2
                Теоретически можно. Форма создаётся тегом form. Вот пример кода простой формы:
                <form method="post" action="/cgi-bin/form.cgi">
                 <label>
                  Как вас зовут?
                  <input type="text" name="name" size="10" maxlength="15">
                 </label>
                 <input type="submit" value="Отправить">
                </form>
                Обратите внимание на открывающий тег form (первая строчка кода). Значение его атрибута action — это адрес серверного скрипта, которому передаются введённые пользователем данные и который генерирует страницу, показываемую пользователю после отправки заполненной формы.

                На практике иногда бывает именно так, а бывает сложнее. Во-первых, форма может быть создана броузерным скриптом, причём это не обязательно простой скрипт, состоящий всего лишь из нескольких document.write(); и вызываемый строчкой вида
                <script type="text/javascript" src="/js/form.js"></script>
                Броузерный скрипт может динамически генерироваться другим броузерным скриптом, и для нахождения интересующего Вас адреса может понадобиться многочасовой труд, даже если код не обфусцирован (обфускация — переделка кода таким образом, что он работает по-прежнему, но прочитать его становится крайне затруднительно).

                Во-вторых, указанный в атрибуте action серверный скрипт может перенаправлять куда-то ещё, причём наличие и адрес перенаправления могут зависеть от введённых пользователем данных, времени суток, температуры воздуха в деревне Тимбукту и чего угодно ещё — от чего именно, зависит исключительно от автора серверного скрипта. Увидеть же код серверного скрипта посторонние не могут.

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

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