Протокол tls что это
Протокол TLS
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 10
В этой статье для ИТ-специалистов описывается принцип работы протокола TLS и приводятся ссылки на RFC-документы IETF по протоколу TLS 1,0, TLS 1,1 и TLS 1,2.
Протоколы TLS (и SSL) расположены между уровнем протокола приложения и уровнем TCP/IP, где они могут защищать и передавать данные приложений на транспортный уровень. Поскольку протоколы работают между уровнем приложения и транспортным уровнем, TLS и SSL могут поддерживать несколько протоколов уровня приложений.
Для TLS и SSL предполагается, что используется транспорт, ориентированный на соединение, обычно TCP. Этот протокол позволяет клиентским и серверным приложениям обнаруживать следующие угрозы безопасности:
Вмешательство в сообщение
Протоколы TLS и SSL можно разделить на два уровня. Первый уровень состоит из протокола приложения и трех протоколов подтверждения: протокол подтверждения, протокол изменений шифра и протокол оповещения. Второй уровень — протокол записи.
Уровни протокола TLS и SSL
Поставщик услуг SChannel использует протоколы TLS и SSL без изменений. Протокол SSL является частным, но в результате задача инженерного проектирования Интернета выдает общедоступные спецификации TLS. сведения о том, какие версии TLS или ssl поддерживаются в Windows версиях, см. в разделе протоколы в TLS/SSL (Schannel SSP). Каждая спецификация содержит следующие сведения:
Протокол записи TLS
Протоколы подтверждения TLS: изменение протокола шифра — протокол оповещений
Обязательные комплекты шифров
Протокол прикладных данных
Возобновление сеанса TLS
представленный в Windows Server 2012 R2, поставщик общих служб Schannel реализовал серверную часть возобновления сеанса TLS. Реализация RFC 5077 в клиентской части была добавлена в Windows 8.
Устройства, подключающие TLS к серверам, часто требуют переподключения. Возобновление сеанса TLS снижает затраты на установку TLS-подключений, так как возобновление включает в себя сокращенное подтверждение TLS. Это упрощает несколько попыток возобновления работы, позволяя группе TLS-серверов возобновить сеансы TLS друг друга. это изменение обеспечивает следующие возможности для любого клиента TLS, поддерживающего RFC 5077, в том числе устройств Windows Phone и Windows RT.
Уменьшение использования ресурсов на сервере
Сниженная пропускная способность, повышающая эффективность клиентских подключений
Сокращение времени, затраченного на подтверждение TLS из-за возобновления соединения
Сведения о возобновлении сеанса TLS без отслеживания состояния см. в документе IETF RFC 5077.
Согласование протокола приложения
в Windows Server 2012 R2 и Windows 8.1 появилась поддержка, позволяющая согласование протокола приложения TLS на стороне клиента. Приложения могут использовать протоколы в рамках стандартной разработки HTTP 2,0, а пользователи могут получать доступ к веб-службы, таким как Google и Twitter, с помощью приложений, использующих протокол SPDY.
Сведения о том, как работает согласование протокола приложений, см. в разделе Расширение согласования протокола прикладного уровня TLS.
Поддержка TLS для расширений указание имени сервера
Компонент указания имени сервера (SNI) расширяет возможности протоколов SSL и TLS для правильной идентификации сервера в случае, когда на одном сервере запущено несколько виртуальных образов. В сценарии размещения виртуальной среды несколько доменов (каждый с собственным потенциально отличающимся сертификатом) размещаются на одном сервере. В этом случае сервер не может заранее узнать, какой сертификат следует отправить клиенту. SNI позволяет клиенту сообщать целевой домен ранее по протоколу, что позволяет серверу правильно выбирать нужный сертификат.
Это обеспечивает следующие дополнительные функциональные возможности.
Позволяет размещать несколько веб-сайтов SSL с одним сочетанием протокола Интернета и порта
Сниженное использование памяти при размещении нескольких веб-сайтов, работающих по протоколу SSL, на единственном веб-сервере.
Позволяет большему пользователю одновременно подключаться к веб-сайтам SSL
SSL/TLS
Содержание
Протоколы SSL и TLS [ править ]
SSL (Secure Sockets Layer) и TLS (Transport Level Security) — криптографические протоколы, обеспечивающие защищенную передачу данных в компьютерной сети. Они широко используются в веб-браузерах, а также при работе с электронной почтой, обмене мгновенными сообщениями и в IP-телефонии.
Соединение, защищенное протоколом TLS, обладает одним или несколькими следующими свойствами:
Так как большинство протоколов связи могут быть использованы как с TLS/SSL, так и без него, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Один способ добиться этого — использовать порт, по которому соединение всегда устанавливается с использованием TLS (например, 443 для HTTPS). Другой способ — использовать специальную команду серверу от клиента переключить соединение на TLS (например, STARTTLS для протоколов электронной почты).
История SSL [ править ]
Из-за невозможности гарантировать безопасность сети, через которую передается информация наилучшим способом защитить ее было выбрано шифрование и дешифрование на концах устанавливаемого соединения соответственно. Netscape могли бы встроить этот подход напрямую в свой браузер, но это бы не предоставило единого решения, которое другие приложения могли бы использовать. Требовалось получить более общный, независимый от приложения подход.
В итоге, Netscape разработал протокол SSL работающий поверх TCP, а также предоставляющий TCP-подобный интерфейс для приложений более высокого уровня. В теории, одним из преимуществ SSL для разработчиков являлась возможность заменить все традиционные TCP вызовы на новые SSL вызовы. Специфические детали того, как SSL шифрует и дешифрует данные были относительно прозрачны.
Устройство протокола SSL [ править ]
Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET и т.д.) и транспортным протоколом TCP/IP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передает их далее на транспортный уровень.
Работу протокола можно разделить на два уровня:
Первый слой, в свою очередь, состоит из трех подпротоколов:
Протокол подтверждения подключения производит цепочку обмена данными, что в свою очередь начинает аутентификацию сторон и согласовывает шифрование, хэширование и сжатие. Следующий этап — аутентификация участников, которая осуществляется также протоколом подтверждения подключения.
Протокол изменения параметров шифра используется для изменения данных ключа (keying material) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей.
Предупредительный протокол содержит сообщение, которое показывает сторонам изменение статуса или сообщает о возможной ошибке. Обычно предупреждение отсылается тогда, когда подключение закрыто и получено неправильное сообщение, сообщение невозможно расшифровать или пользователь отменяет операцию.
Протокол записи [ править ]
Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.
Существует четыре протокола записи:
Принцип работы SSL [ править ]
Принцип работы SSL состоит из двух фаз: фаза рукопожатия и фаза передачи данных. Во время фазы рукопожатия клиент и сервер используют шифрование открытым ключом для того, чтобы определить параметры секретного ключа, используемого клиентом и сервером для шифрования во время фазы передачи данных.
Клиент инициирует рукопожатие посылая “hello”-сообщение серверу. Такое сообщение содержит список алгоритмов симметричного шифрования (cipher specs), поддерживаемых клиентом. Сервер отвечает похожим “hello”-сообщением, выбрав при этом наиболее подходящий алгоритм шифрования из полученного списка. Далее сервер отправляет сертификат, который содержит его публичный ключ.
Для проверки сертификата сервера клиент использует публичный ключ центра сертификации для расшифровки подписи. Затем клиент самостоятельно считает отпечаток сертификата сервера и сверяет с расшифрованным. Если они не совпадают, то сертификат был подделан. Естественно, для расшифровки подписи у клиента должен быть публичный ключ центра авторизации. Поэтому клиент хранит у себя список публичных ключей подтвержденных центров сертификации. По факту, многие браузерные приложения имеют подобный список, находящийся непосредственно в их коде. Когда клиент установил подлинность сервера (сервер также может запросить сертификат у клиента), сервер использует шифрование открытым ключом для определения секретного ключа для обмена информацией.
Фаза рукопожатия завершается отправкой “finished”-сообщений, как только обе стороны готовы начать использование секретного ключа. Начинается фаза передачи данных, в ходе которой каждая сторона разбивает исходящие сообщения на фрагменты и прикрепляет к ним коды авторизации сообщений MAC (message authentication code). Код авторизации сообщения это зашифрованный отпечаток, вычисленный на основе содержимого сообщений. Из соображений безопасности, он не совпадает с секретным ключом и вычисляется вместе с секретным ключом на стадии рукопожатия. Для получения полноценного SSL пакета каждая из сторон объединяет данные фрагмента, код авторизации сообщения, заголовки сообщения и шифруют с использованием секретного. При получении пакета, каждая из сторон расшифровывает его и сверяет полученный код авторизации сообщения со своим. Если они не совпадают, то пакет был подделан.
Цифровые сертификаты [ править ]
Протокол SSL использует сертификаты для проверки соединения. Сертификаты расположены на безопасном сервере и используются для шифрования данных и идентификации Web-сайта.
Способы получения SSL-сертификата:
Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.
Хэширование [ править ]
Хеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются MD5 (Message Digest 5), который создает 128-битное хеш-значение, SHA-1 (Standard Hash Algorithm), создающий 160-битное хеш-значение, SHA-2 и SHA-3. Результат работы алгоритма хеширования — значение, которое используется для проверки целостности передачи данных.
Шифрование [ править ]
Существует два основных способа шифрования данных: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ).
Открытый ключ [ править ]
Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным — он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот. Такая взаимосвязь позволяет делать две важные вещи.
Любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, владеющий секретным ключом. (RSA)
Если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ. Именно это является основой для цифровых подписей. (DSA)
RSA — самый распространенный алгоритм шифрования с использованием асимметричных ключей.
Секретный ключ [ править ]
При шифровании секретным ключом используется один и тот же ключ для шифрованных данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объёма данных. Обычно используются алгоритмы DES, 3-DES, RC2, RC4 и AES.
Комбинированный подход [ править ]
Алгоритмы симметричного шифрования часто включают установленное число добавок и сдвигов. Такие алгоритмы часто используют ключ для помощи при битовых манипуляциях или для того, чтобы шифруемые данные стали более случайными. Другими словами, при увеличении размера секретного ключа может увеличиться случайность шифруемых данных, но не обязательно возрастет сложность вычислений при расшифровке. Однако, шифрование открытым ключом использует ключ как экспоненту, поэтому значительное увеличения ключа сильно увеличивает количество вычислений, требуемых для шифрования / дешифрования данных.
Таким образом хотя алгоритмы шифрования открытым ключом не сталкиваются с проблемой распределения, с которой сталкиваются алгоритмы шифрования секретным ключом, они требует значительно больше вычислительной мощности. Для использования сильных сторон обоих типов алгоритмов протоколы безопасности обычно используют шифрование открытым ключом для передачи секретных ключей. Как только секретный ключ доставлен начинается передача данных с использованием симметричного шифрования.
Существует еще один подход, использующий открытый ключ как соглашение, а не как способ доставки секретного ключа другим. Обе стороны обмениваются публичными ключами и независимо генерируют секретный ключ. Самой распространенной формой такого соглашения является протокол Диффи-Хеллмана. Хотя SSL поддерживает протокол Диффи-Хеллмана, большинство SSL транзакций не используют его. Вместо него используется алгоритм RSA, который решает проблему распределения секретных ключей.
Аутентификация и обмен ключами [ править ]
SSL поддерживает 3 типа аутентификации:
Обычно для аутентификации используются алгоритмы: RSA, DSA, ECDSA.
Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный сервер должен предоставить допустимый сертификат клиенту. Каждая сторона отвечает за проверку того, что сертификат другой стороны ещё не истек и не был отменен. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента.
Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret).
Анонимный обмен ключами [ править ]
Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret).
Аутентификация и обмен ключами при использовании RSA [ править ]
В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.
Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.
Аутентификация и обмен ключами при использовании протокола Диффи-Хеллмана [ править ]
В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием для того, чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру для уверенности, что параметры принадлежат серверу.
Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (pre_master_secret) каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.
Восстановление сессии [ править ]
Создатели SSL знали, что алгоритмы шифрования открытым ключом вычислительно сложные, и клиент, создающий несколько новых соединений к одному и тому же серверу в течение короткого промежутка времени может сильно нагрузить сервер, что приведет к заметным временным задержкам ответа. Однако, если клиент и сервер уже установили соединение, то ему будет соответствовать уникальный идентификатор сессии, позволяющий ссылаться на него и использовать такой же секретный ключ при последующих соединениях в рамках некоторого временного отрезка. Безусловно, такой подход привносит определенный риск в безопасность соединения. Поэтому, если необходимо, клиент может пересоздать новые идентификатор и секретный ключ для данной сессии. Microsoft’s Internet Explorer, например, проделывают эту операцию каждые 2 минуты.
Администрирование [ править ]
Обслуживание сертификатов и ключей [ править ]
Если клиент планирует обратиться к серверу, который требует клиентской аутентификации, он должен хранить свой сертификат и связанный с ним приватный ключ. Сервер должен всегда хранить свой сертификат и связанный с ним приватный ключ.
Хранилище идентификаторов сессий [ править ]
Клиент и сервер обязаны хранить идентификаторы сессий и связанные с ними секретные ключи для использования во время восстановления соединения.
SSL 1.0, 2.0, 3.0 и TLS [ править ]
Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL 3.0 версии.
Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.
Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” (downgrade) до SSL 3.0 для работы с клиентами, использующими SSL 3.0.
Принцип работы TLS [ править ]
Протокол TLS делится на два слоя: TLS Record и TLS Handshake.
Подтверждение связи (handshake) [ править ]
Возобновление сессии [ править ]
Протокол записи (TLS Record) [ править ]
Этот слой защищает данные с помощью ключей, полученных при подтверждении связи, и проверяет целостность и источник входящих сообщений. Он выполняет следующие функции:
После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.
Введение в 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 идет по открытому каналу, и все эти штуки может видеть кто угодно. С этим связаны несколько интересных атак, о которых вы можете почитать сами.
Во второй серии части статьи мы узнаем, как клиент проверяет сертификат.