Tls что это такое простыми словами
Что такое TLS: история версий, преимущества и отличия от SSL
В середине 90-х компания Netscape выпустила протокол, который повышал безопасность электронных платежей. Протокол получил название SSL и являлся предшественником протокола TLS. Версия 1.0 так и не пошла «в народ», будучи отбракованной на этапе тестирования. Версия 2.0 вышла в свет, но имела дыры в защите.
В 1996 году недостатки v. 2.0 были устранены, и мир увидел уже вполне рабочую версию программы — SSL 3.0. Реализация протокола происходила на уровне application, над TCP. Это позволило протоколам высокого уровня, вроде http, функционировать в штатном режиме.
Если в настройке SSL не наблюдается погрешностей, сторонний наблюдатель не получит доступа к пакетным данным, в том числе не сможет их прочесть или подменить. Вся информация, которая окажется ему доступной – общая, не выходящая за рамки приватности: тип шифрования, примерный объем данных и частота пересылки.
Параметры безопасности
Протокол обеспечивает безопасность работающих над ним приложений. Гарантия имеет три направления: сохранение конфиденциальности, аутентификацию и контроль целостности данных.
При использовании протокола веб-браузером поддерживаются параметры, способные обеспечить высшую степень безопасности. Статистика протокола TLS дает следующие данные:
TLS-рукопожатие
Процедура стартует с согласования параметров соединения между сервером и клиентом: определяется тип протокола и метод шифрования протокола TLS. Проверяются сертификаты, высчитывается общий ключ сессии. После этого клиент и сервер, не согласовываясь друг с другом, высчитывают хэш-функцию всех сообщений и сверяют между собой несколько раз. Если значения совпадают, на основе общего вычисленного ключа устанавливается защищенное соединение. Процедура занимает огромное количество вычислительных ресурсов, и чтобы избежать ее при каждом возобновлении прерванной сессии – была создана TLS False Start.
TLS False Start
Если клиент и сервер ранее устанавливали связь, функция позволит пропустить процедуру генерации ключей. Для установления безопасного канала связи будут использованы ключи, которые были вычислены ранее. Однако сессии имеют ограниченное время жизни, и если период сессии истек – придется повторно проводить процедуру TLS-рукопожатия.
TLS Chain of trust
Процедура строится на сертификатах подлинности и обеспечивает аутентификацию между сервером и клиентом. Сертификаты выдаются Центрами сертификации, которые периодически проверяют подлинность и могут отозвать сертификат, если он скомпрометирован. Именно эта процедура обеспечивает проверку подлинности передаваемых данных.
Что такое TLS
Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.
Общие сведения о TLS
Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.
Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:
После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.
Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.
Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
Шифрование, аутентификация и целостность
Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, который предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).
Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.
Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.
TLS Handshake
Перед тем, как начать обмен данными через TLS, клиент и сервер должны согласовать параметры соединения, а именно: версия используемого протокола, способ шифрования данных, а также проверить сертификаты, если это необходимо. Схема начала соединения называется TLS Handshake и показана на рисунке:
Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.
Обмен ключами в протоколе TLS
По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.
На текущий момент, все браузеры при установке соединения TLS отдают предпочтение именно сочетанию алгоритма Диффи-Хеллмана и использованию временных ключей для повышения безопасности соединения.
Следует ещё раз отметить, что шифрование с открытым ключом используется только в процедуре TLS Handshake во время первоначальной настройки соединения. После настройки туннеля в дело вступает симметричная криптография, и общение в пределах текущей сессии зашифровано именно установленными симметричными ключами. Это необходимо для увеличения быстродействия, так как криптография с открытым ключом требует значительно больше вычислительной мощности.
Возобновление сессии TLS
Как уже отмечалось ранее, полная процедура TLS Handshake является довольно длительной и дорогой с точки зрения вычислительных затрат. Поэтому была разработана процедура, которая позволяет возобновить ранее прерванное соединение на основе уже сконфигурированных данных.
Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.
Процедура возобновления сессии позволяет пропустить этап генерации симметричного ключа, что существенно повышает время установки соединения, но не влияет на его безопасность, так как используются ранее нескомпрометированные данные предыдущей сессии.
Однако здесь имеется практическое ограничение: так как сервер должен хранить данные обо всех открытых сессиях, это приводит к проблеме с популярными ресурсами, которые одновременно запрашиваются тысячами и миллионами клиентов.
Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.
TLS False Start
Технология возобновления сессии бесспорно повышает производительность протокола и снижает вычислительные затраты, однако она не применима в первоначальном соединении с сервером, или в случае, когда предыдущая сессия уже истекла.
Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:
Важно отметить, что TLS False Start никак не изменяет процедуру TLS Handshake. Он основан на предположении, что в тот момент, когда клиент и сервер уже знают о параметрах соединения и симметричных ключах, данные приложений уже могут быть отправлены, а все необходимые проверки можно провести параллельно. В результате соединение готово к использованию на одну итерацию обмена сообщениями раньше.
TLS Chain of trust
Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:
Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.
Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:
Естественно, возникают случаи, когда уже выданный сертификат необходимо отозвать или аннулировать (например, был скомпрометирован закрытый ключ сертификата, или была скомпрометирована вся процедура сертификации). Для этого сертификаты подлинности содержат специальные инструкции о проверке их актуальности. Следовательно, при построении цепочки доверия, необходимо проверять актуальность каждого доверительного узла.
Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.
Таким образом, в данной статье рассмотрены все ключевые средства, предоставляемые протоколом TLS для защиты информации. За некоторую отсебятину в статье прошу прощения, это издержки изначальной цели выполнения перевода.
«Как это работает»: знакомство с SSL/TLS
Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.
Сегодня мы решили затронуть тему безопасности и поговорить об SSL. Всем известно, что сертификаты обеспечивают надежное соединение, а мы разберёмся в том, как именно это происходит, и взглянем на используемые протоколы.
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. И такой защищенный канал связи вполне получится использовать для внутренних целей: между устройствами своей сети или приложениями. Но вот для использования на веб-сайте сертификат необходимо приобретать официально, чтобы в цепочке подтверждения сертификатов обязательно имелся корневой сертификат, браузеры не показывали сообщений о небезопасном соединении, а пользователи были спокойны за свои данные.
Введение в TLS для п̶р̶а̶к̶т̶и̶к̶о̶в̶ Патриков (часть 1)
Как вы, возможно, уже знаете, это Патрик. Он морская звезда, а значит, можно, не оскорбляя его, сказать, что руки у него растут из одного места. Еще Патрик очень практичный и сразу забывает всё, что ему не нужно – но если что-то ему нужно, он хочет это знать (потому что ему это нужно!). Спойлер: здесь Патрик пытается сделать TLS Handshake.
Эта статья написана для Патрика и таких, как он. Она родилась из презентации, впервые показанной на нашем внутреннем образовательном Plesk TechTalk, где сотрудники в доступной форме делятся друг с другом информацией об интересных технологиях, процессах и решениях. Поэтому картинки в этой статье будут похожи на слайды 🙂 Автор оригинального текста доклада — program manager Plesk Руслан Косолапов.
Обычно все материалы по TLS охватывают какой-то маленький аспект, но не общую картину. Это не очень практично и у Патрика от такого болит голова. Здесь всё будет по-другому: коротко, применимо «в быту» и по возможности исчерпывающе.
Что такое TLS и зачем он Патрику
TLS (Transport Layer Security) – это протокол защиты транспортного уровня. Он нужен для того, чтобы никто не мог вас «прослушать» и узнать какую-то важную информацию (чаще всего пароли, если говорить о работе в сети). А еще для того, чтобы защититься от подделывания и модификации трафика в процессе передачи. Именно в этих двух вещах состоит назначение TLS.
Для наглядности давайте рассматривать TLS handshake как звонок Патрика Губке Бобу. Во время звонка кто-то может подслушать разговор (стоя рядом с Патриком либо включившись в середине линии), и вообще на другом конце может быть не Губка Боб – все эти проблемы актуальны. И чтобы их порешать, Патрик хочет использовать TLS.
Вкратце, верхнеуровневый handshake выглядит так:
Патрик: Хочу использововать TLS, шифры-версии такие-то.
Губка Боб: Ок, давай использовать шифры-версии такие-то.
После этого Губка Боб отсылает сертификат, Патрик его проверяет, говорит что все отлично, делается сессионный ключ (на самом деле их два, но это неважно). Почему используется сессионный ключ, а не ассиметричное шифрование — потому что это быстрее. После этого они начинают говорить на непонятном для расшифровки языке. Таким образом, всё защищено.
Кажется, что всё просто. Как работает на железе – нам не так важно. Но если начать задумываться – а Патрик начинает задумываться! – то возникает вопрос, как вообще договориться, что мы будем использовать TLS? Ведь когда-то TLS не было, а были только обычные протоколы – SMTP, HTTP. Как сказать, что надо по TLS? И здесь у нас в индустрии всё как обычно – есть много путей!
Сначала хотели использовать определенный порт, который будет подразумевать использование на нем TLS. Какие у этого минусы? И почему потом появился эксплицитный (явный) метод начала TLS-сессии? Причин несколько:
Остановимся немного подробнее на разных видах соединений и на том, как для них обстоят дела с TLS.
Connect: HTTP
Всё было бы легко, если бы, как всегда, не было нюансов. В случае с HTTP растущие требования к безопасности обеспечивают постоянную эволюцию процесса работы с TLS. Сначала был редирект на HTTPS, и это делалось просто в заголовке. Это оставляло лазейку для уязвимостей, поэтому товарищи из Google придумали HSTS (HTTP Strict Transport Security). Это такой заголовок в HTTP-ответе, который говорит браузеру: «запомни, пожалуйста, что когда ты приходишь на этот домен, иди сразу на HTTPS, даже если человек сказал идти на HTTP». Таким образом, нет никакого редиректа и всё происходит гораздо безопаснее. Кроме этого, у Google есть еще одна инициатива – можно оставить заявку, чтобы твой сайт добавили в список для Google Chrome «всегда ходить по HTTPS», вне зависимости от всяких заголовков.
Кратко: HSTS решает проблему уязвимостей при редиректе с HTTP на HTTPS, поэтому почти все браузеры поддерживают HSTS, что хорошо.
Connect: экзотика (новые версии HTTP и не только)
В HTTP/2 дела с TLS обстоят хорошо: он используется всегда (так сейчас сделаны браузеры). Кроме того, TLS в HTTP/2 должен быть свежим — то есть иметь версию 1.2+.
Скорее всего, уже очень скоро Google продавит повсеместное использование HTTP/3, уже сейчас он принят стандартом IANA. История его появления и развития довольно запутанная; главное, что стоит запомнить Патрику:
Кратко: года через 2 везде будет использоваться QUIC (то есть HTTP/3), а сейчас везде уже должен быть HTTP/2, но в действительности он еще не везде.
Connect: Mail
Многие клиенты считают, что на 587-м порту должен быть TLS, но здесь тоже есть нюансы: кто-то ожидает TLS по умолчанию, а кто-то ждет явного запроса STARTTLS от клиента. Из-за этого в разных сочетаниях mail-сервера и mail-клиента иногда возникают нежелательные эффекты. Например, клиент заходит на 587 порт, ожидая, что там будет TLS, в то же время сервер ждет, что клиент сам явно запросит STARTTLS. Ничего не получив, клиент откатывается на 25-й порт. В итоге – молчаливое переключение на небезопасное соединение по SMTP. При тестировании и разработке стоит помнить о таких эффектах сочетаний клиента и сервера. В Autodiscover есть разные возможности указать про TLS: как оно должно быть, что ожидается и что делать. Многие mail-клиенты понимают эти вещи.
Кратко: с поддержкой TLS в mail-серверах и mail-клиентах все в общем и целом нормально, но в частных случаях могут быть проблемы и расширения TLS поддерживаются не очень хорошо.
Connect: FTP
Здесь мало что можно сказать. Основная проблема – SNI (это когда на одном IP разные домены). На уровне FTP имя домена не передается. В эксплицитном варианте работать не может, потому что некуда его писать. Существует несколько вариантов решения — одни предлагают так, другие так, общее решение пока не принято, стандарта нет.
Кратко: поддержка TLS для FTP в каком-то виде есть (FTPS, SFTP — аналог FTP, реализованный через SSH), но некоторые аспекты не охвачены в силу технических ограничений самого FTP.
TLS Handshake
Итак, теперь мы знаем, как инициировать общение с использованием TLS в разных соединениях и Патрик смог сообщить о своем желании Губке Бобу. Как только они договорились, что будут использовать TLS, производится TLS Handshake. Его результатом должна стать договорённость клиента и сервера о том, как они всё это шифруют. Кроме этого, клиент должен убедиться, что сервер именно тот, какой надо. Иногда сервер также проверяет клиента (но значительно реже).
Шифры и версии
Как уже говорилось, на первом этапе выбирается, какая версия TLS и какие шифры будут использоваться для шифрования. Обычно шифр выглядит так:
Набор шифров есть в реестре IANA, а в протоколе TLS в бинарном виде лежит только его ID. Как видно на рисунке, здесь не просто (и не только) шифр, а еще режим его работы и другие детали, необходимые для TLS-handshake. Углубляться в подробности Патрику не нужно. Всё, что важно на данном этапе, это запомнить, что эти буквочки — это хорошо (а остальные — нехорошо):
Если запоминать тяжело, есть хорошие сервисы, которые могут вам про это рассказать, например, сервис от Mozilla ssl-config.mozilla.org.
Тут же можно посмотреть, что где и как поддерживается – за этим ребята из Mozilla пытаются следить.
Интересная деталь: клиент передает шифры в порядке приоритета согласно своим предпочтениям, но решение остается за сервером – он выбирает шифр, который ему кажется наилучшим из списка поддерживаемых клиентом.
Также обе стороны указывают максимальную поддерживаемую версию протокола – в данном случае Патрик более продвинутый, чем Губка Боб.
Собственно сертификат
Вместе с ответом «Давай делать вот так» сервер посылает свой сертификат или сертификаты – их может быть много.
Что представляет собой сертификат? Это связь информации (subject) – чаще всего это имя домена или организации, — и публичного ключа (public key). То есть, сертификат говорит: «Чувак, мой public key вот такой. Сейчас мы с его помощью договоримся о сессионных ключах». Также с его помощью можно проверять подписи сертификатов или еще чего-либо. То есть в принципе можно было бы использовать не сертификаты, а реестры, где эта связь указана. И на самом деле шаги в этом направлении продолжаются, потому что механизм Certificate Authority считается не очень хорошим, просто ничего другого нет.
Таким образом, сертификат – это структура ‘Subject: Public key’ плюс подпись того ишьюера (issuer в транслитерации на русский выглядит ужасно, но самый близкий синоним здесь — не очень близкий по контексту «эмитент»), который этот сертификат выписал. У ишьюера тоже есть сертификат и связь кого-то с чем-то. Проверить сертификат на правильность можно, взяв публичный ключ ишьюера и проверив подпись. Подделать в итоге здесь ничего нельзя.
Давайте пробежимся по сертификату и посмотрим, какие с ним могут быть проблемы.
Во-первых, serial Number подразумевает уникальность только в пределах ишьюера, хотя некоторый софт считает, что он уникален во всей вселенной. К счастью, чаще всего он действительно полностью уникален.
Также в сертификате указывается, какие алгоритмы используются для шифрования и подписи: RSA или ECDSA — то есть, какую криптографию использовать для работы с этим публичным ключом. Основная разница между RSA и ECDSA в том, что математический принцип работы ECDSA основан на эллиптических кривых, а RSA — просто на натуральных числах, поэтому он медленнее и для того, чтобы его нельзя было взломать, используются огромные биты ключей (3-4 тысячи). А для ECDSA достаточно ключа длиной в 300 бит и работает он быстрее. Поэтому многие переходят на ECDSA – handshake сам по себе тяжелый и хочется его сократить. ECDSA можно попросить при выписке сертификата, и если ишьюер его поддерживает, он вам сделает. А вот подпись сертификата зависит от того, какой приватный ключ есть в данный момент у ишьюера, а не от того, попросили вы ECDSA или RSA. Поэтому браузеры могут показывать, что в подписи одно, а в публичном ключе другое и не надо бояться, если в подписи не ECDSA.
Как же получить сертификат?
Вкратце – вот так:
Патрик говорит центру сертификации (Certificate Authority): мне нужен сертификат. Этот человек (или организация) проверяет, действительно ли это Патрик. Проверки могут быть самыми разными. Конечно, Патрик как клиент может и не иметь сертификата, а вот если сертификата нет у сервера, то никакого TLS не будет. Проверяется, всё ли правильно указано в заявке сертификата, действительно ли Патрик владеет этим субъектом (subject), на который просит сертификат. Этим занимаются вышестоящие удостоверяющие центры (Certificate Authority centres) – условные люди, которым все верят. Чтобы выписать сертификат, нужно составить CSR (Certificate signing request, запрос на выдачу сертификата).
Это тоже структура, работать с которой довольно сложно, потому что сервисов, позволяющих всё задать, указать, проверить и посмотреть, мало.
Итого, мы генерируем пару публичный ключ: приватный ключ, но отдаем только публичный, а приватный прячем. Затем формируем Certificate Signing Request и подписываем своим приватным ключом. Отправляем всё это центру сертификации, и тот начинает проверку. Она может быть разной, для особо крутых сертификатов есть специальные хитрые процедуры, но мы остановимся на общем случае.
CAA RR
Есть такая проблема, что люди, которым все верят, иногда не очень хорошие. Одна из причин того, что Symantec стал частью DigiCert, состоит в том, что он (Symantec) выписывал сертификаты без запроса от владельцев домена. Так делать нельзя, обидно было всем, но больше всех самому Symantec, потому что пришлось продать свой бизнес. Для того, чтобы сервер меньше зависел от таких недобросовестных товарищей, есть такая штука как CAA RR – запись в DNS, где написано, кому владелец разрешает выписывать сертификаты для своего домена. Эта функция есть и в Plesk, она пока используется мало, примерно как DNSSec, – но тем не менее. Все центры сертификации договорились проверять эту запись и если в ней указано, что этому центру сертификации выписывать сертификат нельзя, он скажет: «ты не прошел валидацию, у тебя в САА RR написано, что я тебе не могу сертификат выписывать» — и не выпишет. Если записи нет – то можно. Сейчас Google толкает инициативу, чтобы клиенты проверяли пришедший сертификат на соответствие CAA RR записям. Споры пока продолжаются.
Также CAA RR с того момента, как мы делали их поддержку в Plesk, расширились указанием методов валидации (то есть, можно также указать здесь, каким методом ты валидируешь, что этот домен твой) и Account URI (Uniform Resource Identifier). Популярный среди пользователей Plesk Let’s Encrypt уже всё это поддерживает (молодец!).
Всё это работает для любого типа сертификатов, а так как дальше речь пойдет про различия, пора рассказать про типы подробнее.
Типы сертификатов
Domain validation
Субъектом является домен, то есть здесь мы проверяем только его. Раньше, когда не было автоматических валидаторов, валидация происходила в основном по e-mail через сервис Whois. Это считалось достаточным основанием для того, чтобы считать, что ты владелец этого домена. Потом придумали проверять через DNS – на e-mail тебе писали: «а добавь-ка в DNS такую-то запись». Еще попозже появились автоматические методы (про ACME поговорим чуть дальше).
Organization validation
В поле «subject», кроме доменного имени, указывается еще и имя организации. Проверка состоит в валидации, принадлежит ли домен данной организации и работает ли там тот, кто пришел за сертификатом. Как это делается: по реестрам организации ищут, звонят, просят что-то сделать (телефон оказался верным, правильный человек ответил – значит, скорее всего всё хорошо).
Extended validation
То же, что и OV, только круче. Тут всё очень регламентированно – документ на 40 страниц в духе «в пункте 5.6.8 должно быть следующее: …» и т.д. Проверяется много всего – страна, департамент (если указан в заявке), а иногда даже выезжает специальный человек, чтобы посмотреть глазами. В чем практическая разница? Практически все браузеры перестали различать OV и DV, и это плохо, потому что в таком случае не показывается название организации. В результате никто не мешает создать домен aliepxress.ru, нарисовать такую же страницу и воровать кредитные карточки. И будет абсолютно легитимно создать любой подобный домен и получить на него DV сертификат.
Пример с EV – здесь видно название организации, так что если кто что и украдет, пользователь будет знать, что это была корпорация Valve Corp, а зарегистрировать корпорацию несколько сложнее, чем домен (больше проверок).
Однако всё идет к тому, что и EV перестанут отличаться, на мобильных устройствах уже не видно и надо нажимать отдельную кнопочку, и в Safari тоже. Google Chrome пока держится (UPD — уже нет! пришлось делать скрин из IE). Аргументация тех, кто не показывает: «если волнуетесь, нажмите и посмотрите», но никто, естественно, не нажимает.
Получение сертификата: автоматизация
Теперь поговорим об автоматизированном получении DV сертификатов. Для наглядности посмотрим, как это делает наш любимый Let’s Encrypt. У него вообще хорошая документация, если кому интересно, и даже на русском.
ACME (Automatic Certificate Management Environment) — это протокол, созданный для автоматизации и стандартизации процесса получения сертификата.
Как в случае с ACME доказывается, что ты владелец домена? Ты говоришь: хочу сертификат и указываешь вид автоматической валидации – например, ACME HTTP-01. Let’s Encrypt просит тебя положить данные в файл, и если ты смог положить файлы на свой домен (а Let’s Encrypt смог их оттуда забрать по HTTP), наверное, ты и правда его хозяин. Сейчас такой подход подвергается критике, в том числе от Google, за то, что не защищает от фишинга. То есть, при ручной валидации домен aliepxress.ru скорее всего вызовет подозрения, а вот Let’s Encrypt самостоятельно так пока не умеет (или умеет, но плохо).
DNS-challenge
Кроме ACME, есть еще DNS-challenge. Например, тебе говорят: заведи в своей DNS-зоне txt-запись, положи в нее данные. Есть и другие способы, но мало распространённые, а один вообще отменили, потому что он оказался уязвимым. Что у нас в Plesk: wildcard-сертификаты (которые могут быть выписаны только по DNS-challenge) у многих людей не работают, потому что очень часто Plesk не управляет DNS-зонами домена и экстеншн Let’s Encrypt не может автоматизировать создание записи в DNS-зоне.
Еще два слова о Let’s Encrypt
Важный аспект в работе с сертификатами Let’s Encrypt – лимиты. В случае сомнений (или подозрений, что они достигнуты) лучше всего пройти по ссылочке: letsencrypt.org/docs/rate-limits
Иногда их обновляют. Есть неочевидные лимиты, про которые люди забывают: чаще всего, судя по обращениям в поддержку, они сталкиваются с лимитом в 100 доменных имен в сертификате. Еще у Let’s Encrypt есть staging-сервер и там лимиты больше, но такие сертификаты считаются не доверенными (non-trusted) и для браузера они аналогичны самоподписанным. На практике с лимитом в 100 имен к нам приходят редко (при том, что у сайтов на Plesk в общей сложности 1 300 000 Let’s Encrypt сертификатов). Медиана, согласно нашей статистике, – 20 имен на сертификат. Так что, если что-то не работает, посмотрите – возможно, достигнут лимит. У Let’s Encrypt хороший error reporting, и обычно можно понять, что произошло.
Что дальше?
Итак, после того, как сертификат получен, сервер передает данные сеансового ключа – это то, с помощью чего дальше будет осуществляться шифрование. Если сервер считает, что нужно аутентифицировать клиента (например, доступ открыт только определенному кругу лиц), он может спросить: клиент, кто ты? И тогда клиенту надо будет послать свой сертификат. После получения сообщения ServerHelloDone клиент понимает, что пора проверять сертификаты и работать с ключами.
Всё, о чем мы говорили, до TLS 1.3 идет по открытому каналу, и все эти штуки может видеть кто угодно. С этим связаны несколько интересных атак, о которых вы можете почитать сами.
Во второй серии части статьи мы узнаем, как клиент проверяет сертификат.