«Как это работает»: знакомство с SSL/TLS

    Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.

    Сегодня мы решили затронуть тему безопасности и поговорить об SSL. Всем известно, что сертификаты обеспечивают надежное соединение, а мы разберёмся в том, как именно это происходит, и взглянем на используемые протоколы.

    / Flickr / David Goehring / CC-BY

    SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.

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

    Рукопожатие


    Когда пользователь заходит на веб-сайт, браузер запрашивает информацию о сертификате у сервера, который высылает копию SSL-сертификата с открытым ключом. Далее, браузер проверяет сертификат, название которого должно совпадать с именем веб-сайта.

    Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.



    Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.

    Алгоритмы шифрования


    Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.

    Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.

    Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.

    Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.

    Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.

    DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.

    ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.

    Более короткий ключ также влияет на время обработки данных, которое заметно сокращается. Этот факт и то, что алгоритм эффективно обрабатывает большое количество подключений, сделали его удобным инструментом для работы с мобильной связью. В SSL-сертификатах можно использовать сразу несколько методов шифрования для большей защиты.

    Хеш и MAC


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

    Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.

    В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.

    Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.

    Разговоры об отказе от SHA1 велись достаточно давно, но в конце февраля алгоритм был официально взломан. Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.

    Сертификаты бывают разные


    Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.

    Domain Validation, или сертификаты с проверкой домена, подходят для некоммерческих сайтов, так как они подтверждают только веб-сервер, обслуживающий определенный сайт, на который был осуществлен переход. Этот вид сертификата самый дешевый и популярный, но не может считаться полностью безопасным, так как содержит только информацию о зарегистрированном доменном имени.

    Organization Validation, или сертификаты с проверкой организации, являются более надежными, так как подтверждают еще регистрационные данные компании-владельца. Эту информацию юридическое лицо обязано предоставить при покупке сертификата, а удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат отвечает стандартам RFC и содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются.

    Extended Validation, или сертификат с расширенной проверкой, считается самым надежным. Собственно, зеленый замочек или ярлык в браузере означает как раз то, что у сайта есть именно такой сертификат. О том, как разные браузеры информируют пользователей о наличии сертификата или возникающих ошибках можно почитать тут.

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

    Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.

    Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.

    Получить SSL-сертификат можно и самостоятельно: пара ключей для этого генерируется через любой генератор, например, бесплатный OpenSSL. И такой защищенный канал связи вполне получится использовать для внутренних целей: между устройствами своей сети или приложениями. Но вот для использования на веб-сайте сертификат необходимо приобретать официально, чтобы в цепочке подтверждения сертификатов обязательно имелся корневой сертификат, браузеры не показывали сообщений о небезопасном соединении, а пользователи были спокойны за свои данные.

    P.S. Дополнительно по теме из блога IaaS-провайдера 1cloud:

    1cloud.ru
    270,00
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Поделиться публикацией

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

      +1

      Я не очень понимаю, если можно объясните:


      1. зачем нужны корневые центры сертификации для Domain Validation — которые просто подтверждают что общение идёт с https://домен.рф? чем такой сертификат отличается от самоподписанного? почему продавцы доменых имён не генерируют простые сертификаты Domain Validation при регистрации домена ?
      2. насколько замедляется доступ к сайту пока браузер проверяет его сертификат? Насколько критично если центр сертификации находится в США/КНР, а не в Европе ?
      3. Есть ли российские сертификаты? т.е. центры сертификации в РФ, а не продавцы американских сертификатов
      4. Если компания сделала мне сертификат Domain Validation значит ли это что она технически легко может расшифровать https трафик между сайтом и браузером, если сможет его перехватить ?
        0

        Let's Encript примерно месяц назад стал поддерживать кириллические домены, но его придётся обновлять раз в 3 месяца + ставить доп. ПО. А StartSSL — американские компании задавили.
        Если кому надо вот описание и настройки:
        https://тхаб.рф/wiki/Установка_SSL-сертификата_Let%27s_Encript_для_кириллического_домена_на_Apache

          +1
          1. В конце статьи см. ссылку "цепочки сертификатов"
          2. Зависит от массы факторов.
          3. Да.
          4. Нет. При правильной процедуре выдачи закрытый ключ сертификата не покидает контролируемого вами устройства. А компания выдаёт вам открытый ключ, который вы смело можете показывать всему миру.
            0

            а разве центр сертификации выдаёт мне не 2 ключа ?? открытый и закрытый. Например тот же летс ен крипт, который сейчас вроде как обеспечил бесплатными сертификатами чуть не 30% сайтов в мире ?

            0
            1. Затем, что без какой-то третей стороны которая служит точкой доверия нельзя установить зашифрованное соединение. Если вы будете отсылать самоподписанный сертификат, злоумышленник может перехватить ваш ответ и отправить свой самоподписанный сертификат клиенту. Клиент никак не сможет этого заметить.
            Центры сертификации решают эту проблему так, что они выступают третей стороной, которой доверяет клиент. Злоумышленник не может просто самоподписать и отправить сертификат клиенту, ему нужна будет подпись центра, иначе клиент поднимет тревогу.
              +1
              1. А в Казахстане сейчас именно для этого обязали все сайты получать сертификаты в местном центре? Чтобы КНБ Казахстана мог их подменять при необходимости?
              2. т.е. если США имеют доступ к сертификатам Летс Ен Крипт, то они могут при необходимости подменить сертификат Гмайл на подписанный АНБ сертификат и читать почту, смотреть операции в онлайн банке ?
                0
                2. Да, могут. Хотя честно говоря, мне кажется они и так могут почитать почту, когда захочется, без подмены всяких там сертификатов и перехвата трафика.
                  0
                  Такие CA (удостоверяющие центры) быстро потеряют доверие и будут исключены разработчиками из списков доверенных.
                  Такая же история случилась с казахскими центрами. Кто-то из представителей власти написал в mozilla пост с просьбой о включении казахского УЦ в список доверенных. Однако пользователи быстро описали, что казахские власти хотят сделать, поэтому им было однозначно отказано.
                +1

                Хммм.


                1. Корневые центры сертификации считаютсякем? доверенными лицами в трехсторонней схеме сервер-ЦС-клиент. Сервер доверяет ЦС в том, что его сертификат не будет подменен этим ЦС и в том, что ЦС без ведома сервера (точнее, его админов, кто управляет разворачиванием сертификатов на веб-серверах) не выпустит ещё один сертификат на то же имя, которое использует сервер (hostname). Клиент доверяет ЦС в том, что ЦС выдал сертификат именно тому серверу, на котором находится интересующий клиента ресурс, и в том, что этот сертификат не скомпрометирован третьей стороной. Клиент имеет возможность выбирать, каким корневым ЦС он доверяет, с помощью редактирования своего списка сертификатов доверенных корневых ЦС. Поэтому сертификат ЦС от самоподписанного отличается только тем, что к нему есть доверие не только у сервера, но и у клиента.
                2. Зависит от доступности точки распространения списков отзыва сертификатов, если таковая указана в сертификате, и размера самого списка. Однако такая проверка проводится один раз за сессию связи TLS, которую браузеры и серверы из-за накладных расходов стараются не закрывать.
                3. Есть где-то. Как минимум сертификаты для отправки налоговой или бухгалтерской отчетности выдаются российским ЦС. Насчет сертификатов для веб-серверов — не знаю.
                4. Нет, поскольку закрытый ключ от сертификата ЦС не получает в момент обработки запроса на сертификат. Мало того, из-за технологии Forward Secrecy перехват трафика ничего не даст, даже если впоследствии закрытый ключ сервера достанется атакующему. Вот после того, как закрытый ключ был получен кем-то ещё, тогда получивший закрытый ключ может перехватить и расшифровать трафик в защищенном соединении. Но для этого есть механизм отзыва сертификата, который должна инициировать СБ сервера, после чего запросить новый сертификат, создав новый, недоступный (по возможности СБ) другим закрытый ключ, а открытый от него предоставить ЦС для выпуска нового сертификата.

                Надеюсь, более-менее понятно объяснил.

                  +1

                  ОК. спасибо!

                +3

                У вас на картинке, объясняющей шифрование, фундаментальная ошибка, хотя в тексте описание верное. Передаваемые данные НЕ шифруются публичными ключами — несимметричная криптография крайне затрата с точки зрения вычислительных ресурсов. Несимметричные ключи нужны для того, чтобы обменяться симметричным сессионным ключом, с помощью которого уже и идет шифрование.


                ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи.

                Да? А вот, например, в TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 для обмена ключами что используется? :)

                  0

                  В итоге надежной кажется только схема, когда ключи передаются через флешки или голубиной почтой.

                    0

                    Для личного использования (или небольшой рабочей группы, компании) по моему подойдёт самоподписанный сертификат + браузер FF который позволяет такие сертификаты добавлять в доверенные после чего лишних сообщений не выскакивает. С Гугл Хром и Яндекс.Браузер такие номера не проходят :(

                      0
                      Если main-in-the-middle перехватит соединение и предоставит сертификат на ваш домен, подписанный каким-нибудь подконтрольным ему VeriSign (которому Firefox доверяет), клиент увидит в браузере, что соединение доверенное, но подмену сможет обнаружить, только закопавшись в свойствах сертификата (сверив серийный номер и хеш). Разве нет?
                    0
                    У меня только поверхностные знания в области SSL/TLS, шифровании, сертификатах и т. д. Из любопытства я иногда почитываю разные статьи на эту тему и пытаюсь разобраться как это устроено. У всех этих статей есть один общий недостаток, присущий и этой статье. А именно несоблюдение терминологии. В первом абзаце вводится определение SSL как протокола, а через несколько строк употребляется уже какой-то SSL-сертификат. А что это такое?? Что такое ключ шифрования? Чем он отличается от алгоритма шифрования? И т. д. и т. п.
                    В общем, сначала вводятся одни термины, а потом используются другие.
                      0
                      Ну между ключем шифрования и алгоритмом есть четкая разница. Возьмите шифр Цезаря. Шифр Цезаря — это алгоритм, а размер сдвига — ключ.
                      0
                      >>> Всем известно, что сертификаты обеспечивают надежное соединение

                      Ну вы серьезно?.. сертификаты не обеспечивают надежного соединения… и даже криптография его не обеспечивает… его обеспечивает довольно большой комплекс решений.
                        0
                        Пост называется «как это работает», но я не увидел даже высокоуровнего описания протокола. Нет ни положения в OSI, не написано как происходит согласование криптографических параметров, нет даже малейшего намека на техничность статьи. Ваш вариант с шифрованием секрета на клиенте и передачей на сервер уже давно устарел. HMAC не единственный вариант аутентификации сообщений, есть еще cbc-mac, aes-eax например.
                        Большая часть статьи про сертификаты, которые отношение к TLS хоть и имеют, но не составляют его большую часть. Это относится больше к проблемам обмена ключами в небезопасном канале.
                        Советую почитать статью «Анализируем TLS не выходя из комы», чтобы хоть немного понять как он работает.

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

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