Это версия документа от 04/09/2015, устаревшая. Актуальная версия описания TLS существенно дополнена и доступна по основному адресу.
Автор: Александр Венедюхин
SSL и TLS представляют собой развитие одной и той же технологии. Аббревиатура TLS появилась в качестве замены обозначения SSL после того, как протокол окончательно стал интернет-стандартом. Такая замена вызвана юридическими аспектами, так как спецификация SSL изначально принадлежала компании Netscape. То есть, во многих случаях SSL и TLS можно употреблять в качестве синонимов, хотя каноническим именем сейчас является TLS.
TLS/SSL изначально разработали для защиты коммерческих транзакций, проводимых через Интернет. То есть основной целью являлось получение относительно безопасного канала для осуществления покупок или управления банковским счётом - хотя, ни первое, ни второе ещё не пользовались какой-то популярностью у рядовых пользователей во времена становления SSL. Зато в современном Интернете на TLS/SSL полагаются не только в коммерческой деятельности, но и при решении гораздо более общей задачи сохранения "приватности" и конфиденциальности важной информации. Одним из самых распространённых применений TLS является HTTPS. В новой версии HTTP/2 защита информации средствами TLS будет использоваться по умолчанию. Благодаря такому положению дел, SSL/TLS - один из самых изученных, исследованных протоколов современного Интернета. Вместе с тем, история этого протокола показывает, насколько мало бывает практического толка от исследований: например, в 2010 году корпорация Microsoft исправила дефект в реализации SSL своего веб-сервера IIS - CVE-2010-3332; а соответствующая уязвимость в реализациях SSL была продемонстрирована в 2003 году. То есть, семь лет результаты исследования считались чистой теорией, не заслуживающей практического исправления.
Впервые SSL появился в качестве проприетарной технологии, реализованной в браузере Netscape Navigator, одном из первых веб-браузеров. Версия 1 протокола не была опубликована, а так и осталась внутренней разработкой Netscape, развивавшейся в 1994-95 годах. SSLv2 - следующую, вторую версию протокола - опубликовали, однако спецификация так и не вышла из состояния черновика (draft). Более того, хоть в SSLv2 и скорректировали отдельные дефекты и уязвимости v1, протокол оказался ненадёжным, содержащим серьёзные архитектурные огрехи. SSLv2 давно (более 15 лет назад) и без оговорок признан небезопасным, поэтому сейчас не должен использоваться. Хотя на просторах веба всё ещё можно встретить архаичные серверы, которые поддерживают SSLv2, более того, многие современные криптографические библиотеки всё ещё поддерживают SSLv2 по историческим причинам. Вытеснение дефектных технологий идёт медленно. Однако если ваш сервер или клиентское ПО поддерживает SSLv2, можно смело сказать, что у вас просто нет безопасного канала, вы не поддерживаете TLS/SSL вовсе.
SSLv3 - это развитие SSLv2, но с весьма существенными доработками. SSLv3 представлен в 1996 году. Этот протокол получил полноценную спецификацию RFC, правда, значительно позже своего появления, и в статусе исторического документа: RFC 6101. На время SSLv3 пришлось становление TLS как интернет-технологии. Именно на базе SSLv3 и появился протокол TLS.
Сейчас существует три версии TLS, все они описаны в RFC: TLS 1.0, TLS 1.1 и TLS 1.2. Разрабатывается версия TLS 1.3, ожидается, что в ней появятся значительные улучшения. TLS 1.0 во многом повторяет SSLv3, за исключением ряда деталей, которые, впрочем, являются весьма важными. (В криптографических протоколах детали важны как ни в каких других протоколах Интернета.) Ключевым отличием TLS от SSL является наличие поддержки целого ряда расширений протокола, позволяющих реализовать современные методы защиты информации. TLS 1.1 и 1.2 достаточно близки к 1.0, но в версии 1.2 появились заметные изменения, например, используется другая основа псеводслучайной функции и появилась поддержка шифров в режиме аутентифицированного шифрования.
Сейчас рекомендованными являются TLS 1.1 и TLS 1.2. Повсеместно поддерживается TLS 1.0 - данный протокол совместим даже с древним браузером IE 6. TLS 1.1 поддерживается практически всеми сколь-нибудь распространёнными программными сервисами веба, а также других интернет-приложений. Поддержка TLS 1.2 несколько ограничена, но этот протокол в 2015 году также является общедоступным: все современные браузеры его поддерживают, проблемы могут возникнуть только со старыми сборками и, иногда, на стороне сервера, при излишне консервативных настройках.
TLS 1.0 можно назвать версией 3.1 SSL. Собственно, именно так и сделано в спецификациях при описании способа наименования версий: SSL 3.1 - это TLS 1.0; 3.2 - TLS 1.1; 3.3 - TLS 1.2.
С 2015 года SSLv3, следом за публикацией очередных уязвимостей, перешёл в статус нерекомендуемых. Этот статус вполне официальный, каким только официальным он может быть в рамках технологических традиций Интернета: в июне 2015 года выпущен документ RFC 7568 (https://tools.ietf.org/html/rfc7568), требующий исключить SSLv3 из разряда поддерживаемых клиентами и серверами протоколов. Теперь остались только версии TLS.
TLS ставит своей целью создание между двумя узлами сети защищённого от прослушивания и подмены канала связи, пригодного для передачи произвольных данных в обоих направлениях, а также проверку того, что обмен данными происходит между именно теми узлами, для которых канал и планировался. Предполагается, что TLS работает поверх существующего между узлами "потокового" соединения (с которым обычно связан "сокет" - откуда название). Сейчас, в подавляющем большинстве случаев, TLS будет работать поверх TCP. Именно TCP отвечает за установление соединения, разбивку данных на пакеты, гарантированную доставку этих пакетов (при наличии соединения, естественно) и за разные другие телекоммуникационные моменты. TLS считает, что между узлами установлено надёжное соединение, поэтому, например, протокол не охватывает повторную отправку потерянных пакетов данных. (Для работы в условиях негарантированной доставки и неустойчивой связи существует особый, родственный протокол - DTLS, который мы здесь не рассматриваем.) TLS использует установленный канал связи для передачи сообщений. Эти сообщения кардинальным образом отличаются от пакетов данных (IP-пакетов в TCP/IP) и представляют собой структуру более высокого уровня. TCP позволяет надёжно обмениваться данными, но содержимое пакетов (за исключением специальных случаев) может быть легко прочитано кем-то, кто имеет доступ к каналу связи. Хуже того, этот кто-то может заменить пакеты или изменить передаваемые в них данные. Именно для защиты от этих угроз и используется TLS.
Другими словами, модель угроз TLS предполагает, что атакующий может как угодно вмешиваться в канал связи, в том числе активно подменять пакеты и вообще - прерывать связь. Ключевые задачи TLS: 1) обеспечить конфиденциальность, то есть реализовать защиту от утечек передаваемой информации; 2) обеспечить обнаружение подмены, то есть реализовать сохранение целостности передаваемой информации. TLS как-то справляется с этими задачами. Но не следует полагать, что TLS решает эти задачи полностью. Такое мнение является большой ошибкой, к сожалению, весьма распространённой. Протокол и его реализации пытаются решить описанные задачи на максимально доступном уровне надёжности. Однако TLS в целом не обладает доказанной стойкостью, как не обладают ей и многие важнейшие составляющие части протокола. Обычно в качестве экстремального примера данного наблюдения приводят такую рекомендацию: не следует доверять TLS и связанным технологиям свою жизнь или жизнь других людей.
TLS использует концепцию клиент-сервер, которая, в логике данного протокола, во многом совпадает с логикой клиент-сервер TCP: например, и там и там соединение инициирует клиент.
TLS работает с записями (records). Записи находятся в фундаменте протокола. Это нижний транспортный уровень TLS. Если рассматривать сеанс TLS на уровне условного сокета (TCP), то каждая передаваемая запись представляет собой блок, состоящий из короткого заголовка и, собственно, самих данных. Сообщения TLS, относящиеся к верхним уровням, могут быть разбиты на несколько записей.
Обратите внимание, что в SSL/TLS используется сетевой порядок байтов (старший байт идёт первым, слева направо - "тупоконечное" представление). Заголовок имеет длину 5 байтов, и следующий формат:
00 Тип (1 байт) 01 Версия протокола (2 байта) 03 Длина данных (2 байта)
Тип - это тип записи. Определено четыре типа: 20 (0x14) - сообщение Change Cipher Spec (CCS); 21 (0x15) - сообщение Alert (не обязательно предупреждение, есть вполне "фатальные alert-ы"); 22 (0x16) - сообщение Handshake (установление соединения); 23 (0x17) - Application Data (запись содержит прикладные данные - то есть, полезную нагрузку). При передаче информации, основные преобразования с шифрами и кодами аутентификации как раз происходят в блоке данных записи с типом 23 (0x17) Application Data. Прочие записи обычно передаются в открытом виде;
Версия протокола - это версия, записанная в двух байтах, как указано выше: 03 00 - это SSLv3, 03 01 - TLS 1.0; 03 02 - TLS 1.1; 03 03 - TLS 1.2;
Длина данных - количество байтов, содержащих данные (сами байты следуют после заголовка). Так как используется сетевой порядок байтов, для определения длины нужно значение первого байта (h) умножить на 2^8 и прибавить значение второго (младшего, l) байта, вот так: h*256+l. Пустой блок данных (длина нуль) - допускается протоколом, но иногда вызывает сбои в клиентах, написанных с ошибками.
Пример заголовка записи (значения байтов в шестнадцатеричной записи):
16 03 02 03 FE
Раскодируем: это сообщение Handshake; версия 3.2 - то есть TLS 1.1; длина данных - 0x03FE байтов (1022 байта).
Заголовок всегда передаётся в открытом виде.
За заголовком должно следовать определённое число байтов (>=0), которые представляют собой содержимое данной записи. Максимальное значение - 18432 байта. 18432 = 16384 + 2048. То есть, 16 килобайт + два раза по килобайту. Такое значение может показаться странным. Действительно, "базовая" версия записи, описанная в спецификации, предполагает поле данных в 2^14 байтов, то есть 16 килобайт. Но такой размер относится только к записям, содержащим открытый текст (TLSPlaintext). Например, к сообщениям, управляющим установлением соединения (Handshake). Здесь, действительно, максимальная длина - 16К.
Для защищённых записей ситуация меняется. Во-первых, вводится сжатие данных. В TLS все данные защищённой записи должны сжиматься, так предписано спецификацией. Но на практике это означает не совсем то, о чём можно подумать (для TLS это нередкая ситуация): на практике сжатие сейчас не используется. Дело в том, что TLS среди алгоритмов сжатия содержит алгоритм null, означающий, что никакого сжатия не производится. Этот алгоритм служит вариантом по умолчанию (некоторое время можно было встретить алгоритм DEFLATE, но сейчас он относится к нерекомендованным из-за обнаруженных уязвимостей). Тем не менее, сжатые данные могут, в ряде случаев, оказаться длиннее, из-за особенностей алгоритма сжатия. TLS отводит на такое увеличение длины 1024 байта (на практике хорошо реализованные алгоритмы используют значительно меньше).
Во-вторых, для проверки целостности зашифрованных данных к ним приписывается код аутентификации сообщения (MAC) и дополнительная информация (вроде инициализирующих векторов для шифров) - на это отводится ещё 1024 байта. Итого - 2048, хотя данный момент и вносит некоторую сумятицу в организацию протокола. Естественно, универсальные и, потому, фиксированные 16K в качестве максимального предела смотрелись бы лучше. В реальности, редкая запись TLS дотягивает и до 16K - обычно длина заметно меньше.
Код аутентификации - важнейший элемент защиты информации в TLS. Обычно используется HMAC - версия с той или иной хеш-функцией. Типичный выбор: SHA-1 или SHA-256. Код аутентификации приписывается к блоку данных. Один из архитектурных дефектов всех используемых сейчас версий TLS состоит в том, что спецификация предписывает сперва вычислять MAC, а потом шифровать сообщение. То есть, вычисленный код аутентификации присоединяется к открытому тексту сообщения, а потом все вместе шифруется. При этом принимающая сторона должна сперва расшифровать полученные данные, а потом - проверить MAC. Сейчас хорошо известно, что такой метод легко приводит к возникновению "криптографических оракулов", на использовании которых основано несколько эффективных атак против TLS. Современный подход: код аутентификации добавляется после шифрования открытого текста, то есть MAC вычисляется для уже зашифрованного соообщения и прикрепляется к нему. Для внедрения современного подхода в спецификацию добавлено специальное расширение, позволяющее клиенту и серверу договориться о том, в какой последовательности они генерируют коды аутентификации - RFC 7366. Более того, современные шифры в TLS используются в режиме аутентифицированного шифрования (а именно - AEAD). Этот режим не нуждается в MAC, так как целостность данных защищается самим алгоритмом шифрования. Пример: AES в режиме GCM.
Используемые криптосистемы в TLS объединяются в типовые шифронаборы (Cipher Suites). Чтобы начать обмен информацией по защищённому каналу, клиент и сервер должны согласовать используемый шифронабор. Это делается на этапе установления соединения (Handshake). В шифронабор входят криптосистема, используемая для аутентификации сервера и сеансового ключа, шифр, который будет использоваться для защиты передаваемых данных, хеш-функция, служащая основой для HMAC. Например, выбор типового шифронабора TLS_RSA_WITH_AES_128_CBC_SHA означает, что будет использована криптосистема RSA для передачи сеансового ключа, AES со 128-битным ключом в режиме CBC в качестве симметричного шифра, SHA-1 в качестве хеш-функции HMAC. Шифронаборы строго фиксированы, состав закреплён в RFC, каждому приписан свой индекс, а реестр ведёт IANA.
Шифронаборы имеют важнейшее значение для безопасности TLS. Выбор нестойкой комбинации означает, что достаточной защиты конкретная реализация TLS не обеспечивает. Применительно к вебу: браузеры используют встроенный комплект шифронаборов, обычно это 10-15 вариантов; на сервере поддерживаемые шифронаборы настраиваются администратором. Реестр IANA в настоящий момент содержит свыше 300 (трёх сотен, да) шифронаборов (в число которых входят и так называемые псевдошифры, которые используются в качестве сигналов). Среди шифронаборов встречается экзотика вроде TLS_KRB5_WITH_RC4_128_SHA и безнадёжно устаревшие варианты, например - TLS_RSA_EXPORT_WITH_RC4_40_MD5. Современные серверы и клиенты не должны использовать подобного. В 2015 году добротным вариантом считается TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
(TLS Handshake иногда в современных русскоязычных статьях называют "рукопожатием", что является прямым, и не очень удачным, переводом английского термина.)
Клиент и сервер должны договориться об используемых шифрах и методах аутентификации, согласовать ключи и другие параметры сеанса связи. Это делается при установлении соединения при помощи обмена специальными сообщениями - handshake-сообщениями. Такой обмен в TLS происходит поверх обмена записями. Каждое handshake-сообщение содержит специальный заголовок, состоящий из четырёх байтов. Первый байт содержит код типа сообщения, три следующих байта - длину сообщения.
Handshake-сообщения отправляются в виде записей, которые мы обсудили выше. Это означает, что заголовку сообщения может предшествовать заголовок записи, где тип сообщения определён кодом 22 (0x16) - см. выше. Несколько handshake-сообщений могут быть переданы в одной записи - это распространённый случай, например, так нередко поступает Miscrosoft IIS. А самое интересное, что одно сообщение может быть разбито на несколько записей, передаваемых последовательно - спецификация допускает и это. К счастью, последний вариант скорее теоретический, на практике встречается исчезающе редко. (А экстремальный метод "запутывания" состоит в передаче перед разрезанным на несколько записей сообщением пустых записей, то есть TLS-записей, состоящих из одного заголовка, где в качестве длины указан нуль; такой вариант также допустим спецификацией.) Все эти случаи должны корректно поддерживаться добротной реализацией TLS. Таким образом, находящийся ниже протокола установления соединения уровень TLS-записей нужно рассматривать как некий потоковый псевдосокет, куда сообщения записываются как есть, и где они могут быть разрезаны на блоки для передачи. Единственное, что запрещает спецификация TLS - это нарушение порядка при доставке записей (в отличие от IPv4).
Спецификация предполагает, что любой клиент и сервер TLS по умолчанию уже согласовали шифронабор null, без MAC и с "нулевым" сжатием. То есть клиент и сервер могут обмениваться сообщениями в виде открытого текста. Установление соединения всегда начинает клиент. В типичной конфигурации, TLS здесь оказывается схож с TCP, так как, например, при работе с сервером по HTTPS TCP-соединение также инициирует клиент. То есть, благодаря историческому совпадению принципов построения технологий, клиент HTTPS, TLS, TCP - один и тот же узел. Можно предложить теоретические конфигурации протоколов, когда это не так, но в наиболее распространённой ситуации веба - подобные конфигурации едва ли возможны.
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Схема обмена Handshake-сообщениями
(ChangeCipherSpec - не является сообщением Handshake).
Источник: RFC 5246
Первым сообщением в протоколе установления TLS-соединения всегда является сообщение ClientHello (тип 01). Сообщение содержит следующие данные:
Каждое из полей в сообщении ClientHello также имеет свой формат, а полю предшествуют данные о его длинне и, в случаях расширений, дополнительный заголовок. Заголовок обычно содержит тип расширения и длину его данных. Такая структура позволяет реализациям корректно разбирать сообщения. Например, список шифронаборов может быть представлен в таком виде (шестнадцатеричная запись):
[...] 00 06 c0 2b c0 2f с0 29 00 06 - шесть байтов занимают идентификаторы шифронаборов; c0 2b - шифронабор 0xc02b - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256; с0 2f - шифронабор 0xc02f - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256; с0 29 - шифронабор 0xc029 - TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256.
Расширения ClientHello позволяют использовать различные нововведения, которые появились позже, чем структура данного сообщения. Так, например, в расширениях могут быть перечислены эллиптические кривые, которые готов использовать клиент. Самым распространённым расширением является SNI (Server Name Indication), позволяющее браузеру указать имя веб-сервера, с которым он пытается установить соединение. SNI необходимо для того, чтобы на одном IP-адресе могли корректно откликаться по HTTPS веб-серверы, размещённые под разными доменами.
Разберём ClientHello в деталях. В качестве примера возьмём специальный образец ClientHello, сгенерированный утилитой опроса TLS-серверов в исследовательских целях. В качестве сервера используется sbrf.ru.Смещение Байты Комментарий (десятичное) (шестнадцатеричное представление) 0000 16 ; Первый байт заголовка TLS-записи - тип 22, сообщение Handshake. 0001 03 02 00 65 ; Версия TLS 1.1 (03 02), длина пакета данных - 0065 (101 байт). 0005 01 ; Первый байт сообщения TLS: 01 - тип ClientHello. 0006 00 00 61 ; Длина блока данных - 000061 (97 байтов). 0009 03 02 ; Версия TLS 1.1 (03 02). 0011 53 53 4c 20 53 ; 32 байта случайных значений, ClientRandom [...] 0043 00 ; Длина поля SessionID - 0 байтов, так как SessionID в данном сообщении не используется (в случае браузерного ClientHello будет указана длина записи SessionID, за которой последует значение SessionID). 0044 00 16 ; Длина поля со списком шифронаборов (Cipher Suites) - 22 байта: в данном ServerHello указано 11 шифронаборов, по два байта на каждый из них. 0046 c0 2b ; Шифронаборы. [...] 0068 01 00 ; Длина поля CompressionMethods (1 байт) и значение этого поля (00 - null, без сжатия: клиент не поддерживает сжатие). 0070 00 22 ; Длина поля Extensions (0022 - 34 байта), поле, в нашем случае, содержит расширения: SNI, Elliptic Curves, Elliptic Curves Point Formats. 0072 00 00 ; Расширение SNI (Server Name Indication, тип 0000). Данное расширение позволяет указать имя сервера, с которым будет происходить соединение по протоколу HTTPS. 0073 00 0c ; Длина данных в расширении SNI. 0075 00 0a 00 00 07 ; Заголовок расширения SNI - длина списка имён (000a - 10 байтов), тип имени (hostname - 00), длина строки с именем (7 байтов). 0080 73 62 72 66 2e 72 75 ; Значение имени SNI: sbrf.ru 0086 00 0a ; Тип расширения - Elliptic Curves (000a), данное расширение позволяет клиенту указать список эллиптических кривых, с которыми этот клиент умеет работать. 0088 00 08 ; Длина данных расширения (8 байтов). 0090 00 06 ; Длина списка кривых (6 байтов - три кривые, по два байта на идентификатор). 0092 00 17 00 18 00 19 ; Идентификаторы кривых. 0098 00 0b 00 02 01 00 ; Расширение Elliptic Curves Point Format, тип (000b), длина (0002), длина списка (01), формат записи точек - полный (то есть, полностью передаются две координаты x,y в аффинном представлении; есть форматы со сжатием, где передаётся только одна координата, х, а для второй указывается только знак).
Согласно спецификации, после отправки ClientHello клиент ожидает ответа сервера. В ответ может прийти либо сообщение об ошибке, в виде Alert, либо сообщение ServerHello.
Если сервер смог успешно обработать ClientHello, то он отвечает сообщением ServerHello. Это сообщение также имеет заголовок из четырёх байтов: тип сообщения (один байт) и длина (три байта). ServerHello содержит следующие поля:
1) версию протокола, которую будут использовать клиент и сервер;
2) 32 байта случайных значений - Server Random. С этой строкой ситуация такая же, как и с Client Random: первые четыре байта могут быть таймстемпом, а могут и не быть. Интересным свойством данной метки времени является то, что она может послужить некоторым справочным материалом при последующем анализе записанного трафика: если сервер отвечает достоверным значением времени, то, учитывая, что полный набор сообщений Handshake содержит сообщение, криптографически удостоверяющее целостность данных (см. ниже про сообщение Finished), получаем подписанную сервером квитанцию о времени соединения по его часам, с точностью до секунды - иногда эти данные помогают правильно составить запрос в адрес администрации сервера об извлечении записей из логов.
3) идентификатор сессии - SessionID, присвоенный новой сессии сервером;
4) выбранный сервером шифронабор - Cipher Suite, этот шифронабор будет использоваться в дальнейшем и клиентом, и сервером. Сервер выбирает шифронабор из предложенных клиентом в ClientHello;
5) выбранный сервером метод сжатия - скорее всего, это null;
6) некоторый набор расширений.
В современных реализациях TLS раздел "Расширения" (Extensions) имеет очень большое значение, так как в нём передаются параметры, определяющие схему работы и клиента, и сервера. Предназначение ServerHello - согласовать параметры соединения. TLS использует хорошо известную схему "запрос-ответ-подтверждение", а сообщения ClientHello и ServerHello запускают схему. Эти сообщения не содержат никакой секретной информации, соответственно - передаются в открытом виде. Именно поэтому данные сообщения, особенно - ClientHello, часто используются в системах DPI для обнаружения факта установления (или попытки установления) TLS-соединения.
В рамках каждой сессии TLS, клиент и сервер согласовывают следующие параметры (RFC 5246):
1) роли узлов: какой узел является клиентом, а какой - сервером. Распределение этих ролей происходит "естественным образом", при установлении соединения - клиент всегда начинает сессию;
2) алгоритм PRF (псевдослучайная функция) - используется для генерации сеансового ключа, на основе данных, переданных в ClientHello и ServerHello, поэтому клиент и сервер должны использовать согласованный алгоритм;
3) алгоритм шифрования - для успешного шифрования потока данных внутри сессии оба узла должны использовать один и тот же алгоритм, в согласованном режиме. Узлы согласуют тип шифра (потоковый, блочный), сам шифр, размер ключа, размер блока (для блочных шифров), инициализирующие векторы, а также дополнительные параметры (если они требуются, например, в случае с AEAD-шифрами);
4) алгоритм аутентификационного кода сообщения (MAC) - аналогично шифрованию, в рамках сессии необходимо использовать согласованный алгоритм аутентификации. Напомню, что для AEAD-режима шифрования MAC не используется;
5) алгоритм сжатия - также должен быть общим, однако в современной реализации сжатие, фактически, не используется;
6) основной секрет (master secret) - массив из 48 секретных байтов, известный серверу и клиенту. Основное предназначение данного массива - генерация сеансового ключа, в тех шифронаборах, где применимо;
7) случайные данные клиента (ClientRandom) - 32 байта случайных значений, передаются в ClientHello;
8) случайные данные сервера (ServerRandom) - 32 байта случайных значений, передаются в ServerHello.
Эти параметры позволяют построить контекст для работы криптосистемы, которая будет обрабатывать защищённые TLS-записи на стороне сервера и клиента. Помимо ClientHello и ServerHello, установление соединения подразумевает обмен несколькими другими сообщениями.
За отправкой ServerHello, со стороны сервера следует ряд других сообщений, состав и содержание этих сообщений зависят от выбранного сервером режима работы.
Certificate. Ключевым аспектом для современных реализаций TLS является использование SSL-сертификатов, мы рассмотрим их подробнее ниже. Сертификаты передаются сервером в сообщении Certificate. Это сообщение присутствует практически всегда. Серверный сертификат содержит открытый ключ сервера. В теории, спецификация позволяет установить соединение без отправки серверных сертификатов. Это так называемый "анонимный" режим, однако он практически не используется, как и режимы TLS без шифрования. Так, примерно 100% веб-серверов, поддерживающих TLS, передают SSL-сертификаты. Для типичной конфигурации сообщение Certificate будет включать несколько SSL-сертификатов, среди которых один серверный сертификат и так называемые "промежуточные сертификаты", позволяющие клиенту выстроить цепочку валидации. Спецификация предписывает строгий порядок следования сертификатов в сообщении: первым должен идти серверный сертификат, а последующие - в порядке удостоверения предыдущего. Однако на практике серверы нередко возвращают сертификаты в произвольном порядке. На клиентской стороне браузеры также достаточно свободно относятся к порядку сертификатов, пытаясь выстроить из них корректную цепочку путём различных подстановок. Такое положение дел прямо нарушает спецификацию TLS версий 1.0,1.1,1.2, но такова реальность: несмотря на все строгости криптографии - реализации допускают вольности (последние нередко ведут к уязвимостям). Хотя, достаточно сложно найти веские причины для строго порядка следования сертификатов в TLS-сообщении. Возможно, в новых версиях протокола требование смягчат, сделав порядок нестрогим.
ServerKeyExchange. Это сообщение, содержащее серверную часть данных, необходимых для генерации общего сеансового ключа. Это сообщение может отсутствовать. В зависимости от выбранного шифронабора, данных, содержащихся в SSL-сертификате, может быть недостаточно для выработки общего ключа. Недостающие данные как раз и передаются в ServerKeyExchange. Обычно это параметры протокола Диффи-Хеллмана (DH). Если используется классический вариант, то в сообщении ServerKeyExchange передаётся значение модуля и вычисленный сервером открытый ключ DH. В варианте на эллиптических кривых (ECDH) - идентификатор самой кривой и, аналогично DH, открытый ключ. Параметры подписываются сервером, клиент может проверить подпись, используя открытый ключ сервера из SSL-сертификата. В зависимости от используемой криптосистемы подпись может быть DSA (сейчас практически не встречается), RSA или ECDSA.
CertificateRequest. В TLS возможна обоюдная (двухсторонняя) аутентификация узлов, использующая SSL-сертификаты. Сервер может запросить клиентский сертификат при помощи сообщения CertificateRequest. Сообщение содержит список поддерживаемых сервером типов сертификатов и типов криптосистем - здесь указываются криптосистемы, относящиеся к процедуре валидации клиентского сертификата: алгоритмы подписи, хеш-функции. Также в составе CertificateRequest могут быть переданы имена удостоверяющих центров, ключи которых сервер будет использовать для проверки клиентского сертификата.
ServerHelloDone - обозначает окончание пакета сообщений, возглавляемого ServerHello. Это сообщение имет нулевую длину (однако заголовок никто не отменял, поэтому в TLS-записи ServerHelloDone соответствует 4 байта) и служит простым флагом, обозначающим, что сервер передал свою часть начальных данных и теперь ожидает ответа от клиента.
Итак, сервер отвечает на ClientHello последовательностью сообщений TLS Handshake, максимум - пятью сообщениями. Типичный для современного состояния TLS случай: передача сервером четырёх сообщений - ServerHello, Certificate, ServerKeyExchange (с параметрами алгоритма Диффи-Хеллмана), ServerHelloDone. После передачи ServerHelloDone сервер ожидает ответа клиента. Клиент должен ответить своим набором сообщений:
Certificate - это сообщение содержит клиентский сертификат, если он был запрошен сервером. Если у клиента сертификата нет, а сервер его запрашивает, то клиент либо пропускает данное сообщение (SSLv3), либо отвечает пустым сообщением с типом Certificate (TLS). Клиентский сертификат требуется для двухстороннней аутентификации. Типичные сценарии использования: аутентификация в системах "телебанка", в платёжных системах, в корпоративных веб-шлюзах. Все современные браузеры, работающие на десктопе, поддерживают клиентские сертификаты. Клиентский сертификат, в ряде случаев, может заменить пару "логин/пароль" для аутентификации на том или ином онлайн-ресурсе.
ClientKeyExchange - клиентская часть обмена данными, позволяющими узлам получить общий сеансовый ключ. Содержание этого сообщения зависит от того, какой шифронабор выбран. Есть два основных типа - RSA и несколько вариантов протокола Диффи-Хеллмана. В случае использования RSA, клиент генерирует 48-байтовый случайный секрет, шифрует его открытым ключом сервера (этот ключ передаётся в составе серверного SSL-сертификата, см. выше) и передаёт зашифрованные данные на сервер. Сервер может расшифровать значение, используя соответствующий секретный ключ. Данная схема является исторической, так как обладает целым рядом недостатков. Например, если секретный серверный ключ станет известен третьей стороне, то она сможет расшифровать ранее записанный TLS-трафик. Тем не менее, обмен сеансовым ключом при помощи RSA продолжает использоваться в некоторых реализациях TLS. Современный метод - использование протокола Диффи-Хеллмана. В этом случае, ClientKeyExchange содержит открытый ключ DH. Этот ключ генерируется клиентом либо в соответствии с параметрами, переданными сервером в ServerKeyExchange, либо в соответствии с параметрами, указанными в серверном SSL-сертификате, если последний поддерживает DH. Случай с передачей параметров классического DH в составе сертификата - сейчас является экзотическим, таких сертификатов в "дикой природе" не встречается. Напомню, что серверные параметры DH (или ECDH) подписываются серверным ключом, клиент проверяет подпись, используя открытый ключ сервера.
CertificateVerify - если клиент передал в ответ на запрос сервера свой сертификат, то серверу требуется некоторый механизм, позволяющий проверить, что клиент действительно обладает секретным ключом, связанным с сертификатом. Для этого клиент подписывает массив переданных и принятых ранее сообщений Handshake. Такая подпись, если её значение удастся успешно проверить открытым ключом из сертификата, удостоверит факт наличия секретного ключа у клиента. Сообщение передаётся только если был передан клиентский сертификат в сообщении Certificate.
В современной конфигурации клиентские сертификаты используются редко. Поэтому в типичном случае клиент, на данном этапе, передаёт одно сообщение ClientKeyExchange. Это сообщение является, согласно спецификации, обязательным.
Следом за сообщением ClientKeyExchange, если оно было единственным, либо за CertificateVerify, клиент должен передать сообщение ChangeCipherSpec. Важный момент: это сообщение не является сообщением Handshake. Да, в спецификации TLS встречаются такие, не совсем прозрачные, моменты, когда вроде бы логичное течение протокола прерывается специальными "вставками".
ChangeCipherSpec - это специальное сообщение-сигнал, обозначающее, что с данного момента клиент переходит на выбранный шифр, а следующие TLS-записи будут зашифрованы. ChangeCipherSpec (CCS) имеет собственный тип и, соответственно, передаётся в отдельной TLS-записи. Таким образом, CCS имеет весьма важное значение в TLS, отделяя открытую часть сеанса связи от закрытой.
Со стороны клиента установление соединения звершается отправкой сообщения Finished.
Finished. Это сообщение передаётся в зашифрованной TLS-записи, так как следует за сигналом ChangeCipherSpec, который обозначает момент перехода к защищённому обмену информацией. Finished является первым защищённым сообщением, в рамках нового сеанса TLS. Вспомните, что к моменту его отправки, если всё прошло успешно, сервер и клиент уже согласовали все необходимые параметры сессии: шифронабор, сеансовый ключ, алгоритм кода аутентификации сообщения. Предназначение сообщений Finished - получить криптографически стойкое подтверждение, что сервер согласовал эти параметры именно с тем узлом, с которым предполагалось, то же самое - и для клиента, который получит сообщение Finished от сервера.
Клиентское Finished содержит отпечаток - значение хеш-функции, - от всех предыдущих сообщений Handshake, отправленных, на данный момент, и клиентом, и сервером. Получив это сообщение в защищённой TLS-записи, сервер может вычислить хеш-сумму от известных ему предшествовавших сообщений и сравнить результат. Таким образом подтверждается подлинность сообщений и, соответственно, оказываются криптографически защищены выбранный шифронабор и другие параметры соединения. Впрочем, данная защита не лишена недостатков: например, так как сообщения ClientHello и ServerHello не содержат подписей, Finished никак не защищает сессию от атак, основанных на подмене параметров до отправки ChangeCipherSpec. Этот дефект протокола использован в нашумевшей в 2015 году атаке LogJam (об атаках на TLS/SSL мы подробно поговорим ниже).
В ответ на Finished со стороны клиента, сервер, в случае успешного установления соединения, отправляет свою пару ChangeCipherSpec и Finished. На стороне клиента полученное серверное сообщение Finished также используется для проверки, что сообщения Handshake не подверглись модификации активным атакующим, который перехватил канал. Состав Finished сервера отличается от клиентского варианта, так как включает в свой состав клиентское сообщение (и отличную от клиентской дополнительную строку).
Третьей стороне, активно перехватывающей канал связи, для того, чтобы успешно произвести подмену сообщений Handshake, потребуется вычислить сеансовый ключ и другие секретные параметры (если они использовались) для того, чтобы сфабриковать корректное сообщение Finished. Это вычислительно трудная задача, обычно неразрешимая на практике, если выбраны правильные настройки протокола и корректная реализация. Однако, в случае использования нестойких шифронаборов, атакующий может на лету вычислить секретный сеансовый ключ и - успешно подделать сообщение Finished.
После того как клиент и сервер обменялись парами ChangeCipherSpec и Finished, защищённое соединение успешно установлено и последующие данные могут передаваться в закрытом виде.
Посмотрим на ServerHello и последущие сообщения сервера в деталях, примером послужит ответ сервера на сообщение ClientHello, которое разбиралось выше. В этом примере несколько сообщений TLS передаются в одной TLS-записи.
Смещение Байты Комментарий (десятичное) (шестнадцатеричное представление) 0000 16 03 02 ; Тип записи - Handshake (0x16) - версия TLS 1.1 (0x0302). 0003 07 02 ; Длина пакета данных (0x0702 = 1794 байта - в этой записи содержатся все отправленные сервером сообщения - ServerHello, Certificate, ServerKeyExchange, ServerHelloDone - отсюда и такая длина). ServerHello. Начало сообщения 0005 02 ; Тип сообщения: ServerHello (02). 0006 00 00 46 ; Длина данных: (0x000046 = 70 байтов - это данные ServerHello). 0009 03 02 ; Версия протокола: 0x0302 - TLS 1.1. 0011 55 dc ; 32 байта ServerRandom, в начале поля сервер указывает timestamp. [...] 0043 20 ; Длина SessionID - (0x20 = 32 байта). 0044 81 19 ; 32 байта, содержащие переданный сервером идентификатор сессии (SessionID). [...] 0076 c0 14 ; Выбранный сервером шифронабор - 0xc014 - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (протокол Диффи-Хеллмана на эллиптических кривых для генерации сеансового ключа, RSA - для подписи, AES с 256-битным ключом в режиме CBC в качестве потокового шифра, SHA-1 для генерации MAC). 0078 00 ; Выбранный сервером метод сжатия - 00 - null. Certificate. Начало сообщения 0079 0b ; Сообщение Certificate (тип - 0x0b = 11). 0080 00 05 21 ; Длина сообщения (0x000521 = 1313 байтов). 0083 00 05 1e ; Длина данных сертификатов (0x00051e = 1310 байтов). 0086 00 05 1b ; Длина поля с сертификатом. Каждый из сертификатов, указанных в сообщении Certificate, предваряется тремя байтами, содержащими длину записи данного сертификата. Также передаётся общая длина набора сертификатов - отсюда и эти "вложенные" поля с числом байтов. 0089 30 82 05 17 30 ; Байты, составляющие сертификат (сам сертификат здесь не приводится). Сертификат передаётся сервером в бинарном представлении, с использованием определённого кодирования. На практике это означает, что передаются сертификаты в общепринятом формате DER, который поддерживается большинством утилит, например из пакета OpenSSL и др. [...] ServerKeyExchange. Начало сообщения 1396 0c 00 01 8b ; Сообщение ServerKeyExchange (тип - 0x0c = 12), длина данных (0x00018b = 395 байтов). Так как выбран шифронабор с ECDHE, то сообщение ServerKeyExchange содержит параметры именно для алгоритма ECDHE. Каких-то специальных флагов, обозначающих ServerKeyExchange как ECDHE, - не предусмотрено, всё определяется шифронабором. Использование DH на эллиптических кривых описано в RFC 4492 (https://tools.ietf.org/html/rfc4492). 1400 03 ; Тип кривой (0x03 - типовая именованная кривая). 1401 00 19 ; Идентификатор выбранной сервером кривой (0x0019 - secp521r1, реестр кривых ведёт IANA, каждая из типовых кривых содержит в своём определении необходимые для DH параметры, которые строго зафиксированы: это генератор, разрядность группы точек). 1403 85 ; Длина поля публичного ключа, которое идёт следом (0x85 = 133 байта). 1404 04 00 8f 96 86 ; 133 байта, представляющие собой публичный ключ ECDHE сервера. Публичный ключ - это точка на кривой, которую сервер вычислил, используя параметры кривой. В соответствии с форматом записи точек, указанным клиентом в расширении ClientHello, передаются аффинные координаты точки (x,y) (запись предваряется заголовком). Клиенту параметры кривой известны, потому что используется типовая кривая. [...] 1537 01 00 ; Длина подписи, соответствующей параметрам DH (0x0100 - 256 байтов). За значением открытого ключа DH следует серверная подпись, выполненная по алгоритму и с ключом, соответствующим указанным в серверном сертификате (в нашем случае это RSA). 1539 25 23 f5 ; Значение подписи DH (полностью не приводится). [...] ServerHelloDone. Начало сообщения 1795 0e 00 00 00 ; Сообщение ServerHelloDone (тип - 0x0e = 14). Это сообщение имеет нулевую длину, поэтому следом за типом идут три байта с нулевыми значениями (это обозначающие длину байты).
Установление TLS-соединения - многоступенчатый процесс, достаточно сложный и требующий проведения заметного количества вычислительных операций, особенно жадными в плане процессорного времени оказываются операции проверки подписей и других действий с асимметричными криптосистемами. Установление соединения TLS - затратно, особенно если ваш онлайн-сервис обслуживает большое число клиентов. Для экономии ресурсов существует сокращённая версия Handshake.
В составе ServerHello сервер передаёт SessionID - идентификатор новой сессии. Этот идентификатор может быть использован клиентом позже, в составе ClientHello (см .выше). Предполагается, что на стороне сервера (и клиента) сохранены необходимые параметры, которые могут быть быстро восстановлены, возобновив сессию.
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Установление соединения по сокращённой схеме
Источник: RFC 5246
В случае использования сокращённой схемы, сразу после получения ClientHello, содержащего валидный идентификатор сесcии SessionID, сервер отвечает сообщениями ServerHello, ChangeCipherSpec и Finished. После того как клиент пришлёт свои CCS и Finished, сессия возобновляется и узлы могут начать обмен данными в защищённом режиме.
Сокращённый сценарий содержит существенно меньше сообщений, позволяет не использовать вычислительно затратные операции проверки подписей и генерации общего секрета, кроме того, из-за меньшего количества сообщений заметно уменьшается задержка при установлении соединения (экономится время, требуемое на отправку пакетов от клиента к серверу и обратно). Современные браузеры широко используют сокращённый Handshake. Сессии могут сохраняться на серверах в течение нескольких минут и даже часов.
После того как клиент и сервер установили соединение (по полной или сокращённой схеме), они обмениваются TLS-записями с типом Application Data, каждая такая запись содержит блок данных, зашифрованный симметричным ключом, а также код аутентификации сообщения. Код аутентификации защищает сообщение от изменения. Клиент и сервер самостоятельно ведут учёт полученных и переданных блоков.
TLS имеет ряд важных, и достаточно общих, криптографических особенностей: во-первых, этот протокол никак не скрывает факт установления соединения (как указано выше, системы DPI могут относительно уверенно детектировать начало сенса TLS при помощи простых правил-фильтров); во-вторых, в TLS возможны утечки мета-информации: число переданных блоков, различные предупреждения, передаваемые в открытом виде - всё это позволяет пассивному наблюдателю сделать некоторые выводы о характере передаваемой информации и, в случае веба, о типе совершаемых пользователем на веб-ресурсе действий. TLS лишь более или менее надёжно защищает от перехвата и подмены саму передаваемую информацию.
Во время работы в рамках TLS-сессии клиент и сервер могут столкнуться с необходимостью повторно провести Handshake. Такой случай предусмотрен протоколом. Хрестоматийная ситуация, когда это может потребоваться, выглядит следующим образом: после того как установлено TLS-соединение, клиент, использующий HTTP, запрашивает документ по некоторому URL, однако этот URL требует дополнительной авторизации с использованием клиентского сертификата. Клиентский сертификат может быть передан только в составе сообщения Handshake, поэтому сервер отправляет клиенту сообщение HelloRequest, требующее повторного обмена сообщениями Handshake (уже с клиентским сертификатом). Клиент может инициировать новую сессию в любой момент, передав сообщение ClientHello. Так как узлы уже согласовали TLS-соединение, обмен сообщениями повторного Handshake будет проводиться в защищённом виде. В примере с клиентским сертификатом это означает, что сертификат не будет виден прослушивающей канал стороне.
Асимметричные криптосистемы (с открытым ключом) не подходят для быстрой передачи потоков данных. Поэтому для шифрования данных внутри сессии TLS использует симметричные шифры. Обычно это блочные шифры, нередко используемые режиме, сходном с потоковым (GCM). Есть несколько основных способов выработки общих данных для сеансового ключа. Сеансовый ключ, при этом, должен по понятным причинам оставаться секретным. О симметричном сеансовом ключе узлы договариваются в процессе установления соединения (Handshake). Основные методы генерации общего ключа рассмотрены выше, осталось обсудить некоторые подробности.
Собственно, основа ключа - Master Secret - генерируется из нескольких переменных составляющих: так называемый Premaster Secret, ClientRandom и ServerRandom. Premaster Secret - согласуется в рамках обмена ключами, это либо последовательность случайных байтов, зашифрованная открытым ключом сервера, либо значение, полученное в результате обмена по протоколу Диффи-Хеллмана. Master Secret - это массив из 48 байтов, получаемый в результате применения клиентом и сервером к этим составляющим псевдослучайной функции, определённой спецификацией. Псевдослучайная функция TLS 1.2 построена на базе хеш-функции SHA-256, предыдущие версии используют конструкцию на базе сочетания MD5 (которая давно не считается криптографически стойкой) и SHA-1. При этом, способ использования MD5 при генерации сеансового ключа не приводит к возникновению уязвимостей, связанных с недостаточным качеством данной функции. RFC 5246 определяет Master Secret для TLS 1.2 следующим образом:
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)[0..47];
Master Secret - это ещё не сеансовый ключ. Дело в том, что разные шифры требуют разных ключей и дополнительных данных (например, инициализирующих векторов). Эти ключи и данные вычисляются на основе Master Secret, с использованием той же псевдослучайной функции. Делается это следующим способом (TLS 1.2):
Само шифрование осуществляется на уровне TLS-записей.
Большинство методов получения исходных данных сеансового ключа так или иначе оперируют публичным ключом сервера. На практике этот ключ использует почти 100% TLS-сессий. Публичный ключ передаётся сервером в сертификате. Помимо рассмотренных выше вариантов RSA и Диффи-Хеллмана, возможны экзотические схемы получения общего секрета:
1. PSK - pre-shared key. Схема основана на использовании общего секретного ключа и симметричной криптосистемы, при условии, что ключ был согласован заранее;
2. временный ключ RSA - исторический метод, предполагавший создание сеансового ключа RSA. Сейчас данный метод не используется, однако его поддержка послужила основой для атаки FREAK, опубликованной в 2014 году;
3. SRP - протокол SRP (Secure Remote Password), RFC 5054. Протокол, позволяющий сгенерировать общий симметричный секретный ключ достаточной стойкости на основе известного клиенту и серверу пароля, без раскрытия этого пароля через незащищённый канал;
4. Анонимный DH - анонимный вариант протокола Диффи-Хеллмана, в котором не используется подпись на серверных параметрах. Такая схема подвержена атаке типа "человек посередине", практически не встречается;
5. DH с сертификатом - вариант DH, в котором параметры (модуль, генератор) определены в серверном сертификате. Этот метод является историческим, требует специального сертификата и на практике не встречается.
Современный метод генерации сеансового ключа - это протокол Диффи-Хеллмана. Использование DH, прежде всего, позволяет добиться так называемой прогрессивной секретности (Perfect Forward Secrecy, PFS), когда раскрытие серверного ключа асимметричной криптосистемы (RSA или DSA), не приводит к раскрытию ранее записанного трафика. Подробное описание протокола и его реализаций, применительно к TLS, будет дано отдельно, а в рамках этого обзора - краткие пояснения.
В классическом случае, DH работает на “обычной” конечной группе. Группа DH задаётся единственным числом – модулем. Это обязательно большое простое число. Именно это число передаёт сервер в составе сообщения ServerKeyExchange. На практике веб-серверы используют ту или иную типовую группу (заданную типовым модулем). Модуль не является секретным - он передаётся в открытом виде. Таким образом, известны группы, используемые большинством веб-серверов, поддерживающих DH. Вообще говоря, уникальные группы DH рекомендуется генерировать при начальной настройке TLS, это несложно сделать стандартными утилитами. Тем не менее, в настоящий момент (август 2015 года) наиболее распространена типовая группа, имеющая разрядность в 1024-бита, что не так много.
Вся практическая полезность DH строится на сложности задачи дискретного логарифмирования в конечной группе (отыскания по известным A,G такого e, что A = G^e). Известно, что при наличии больших, но вполне реальных, вычислительных мощностей, для 1024-битной группы можно уже сейчас предвычислить её арифметические структуры, потратив пару лет работы суперкомпьютера и сохранив результаты в специальных таблицах. После этого вычислять дискретный логарифм в этой группе можно достаточно быстро (за часы, а возможно, просто на лету), особенно, если вы используете специальную многопроцессорную систему. Это означает, что можно расшифровать записанный ранее трафик TLS-сессий (а также других протоколов, использующих DH). Дело в том, что сеансовый ключ, если вы умеете отыскивать дискретный логарифм, элементарно вычисляется из ключа DH, который передаётся в открытом виде.
Предвычислить нужную структуру можно только для известной группы, поэтому для атакующего важно, чтобы TLS-серверы использовали типовые параметры. При этом, для тех, у кого ресурсов мало (кто не является специализированным агентством, например), группа остаётся вполне стойкой.
Современная разновидность DH работает на группе точек эллиптической кривой и называется ECDH. Это рекомендуемый вариант алгоритма, он получает всё большее распространение в современных реализациях TLS. В случае классического DH операции аналогичны привычным арифметическим операциям над натуральными числами (но они выполняются по модулю, определяющему группу). Для того чтобы построить группу, соответствующую эллиптической кривой, на последней определяют групповую операцию сложения (и удвоения) точек. Таким образом, результатом ECDH являются уже не "обычные" натуральные числа, а координаты точек кривой, именно поэтому открытый ключ ECDH представляет собой, в обычном представлении, пару чисел (x,y).
Из-за особенностей групповой операции на эллиптической кривой, отыскание дискретного логарифма в такой группе вычислительно сложнее, поэтому можно использовать более короткие ключи (высокую секретность, согласно современным представлениям, обеспечивает группа эллиптической кривой с разрядностью 192 и более бит). Также алгоритм позволяет использовать общую кривую, а не генерировать новую для каждого сервера. По крайней мере, современная ситуация такова, что рекомендовано использовать хорошо известные кривые из утверждённого списка (хотя никто не мешает договориться о собственной кривой). Самый распространённый случай – кривая secp256r1, предлагающая разрядность 256 бит. Если группу классического DH в TLS легко поменять – модуль и генератор передаются в сообщении сервера и могут быть любыми, – то для типовых эллиптических кривых всё сильно сложнее: параметры здесь фиксированы заранее, клиент и сервер могут договориться только о самой кривой, выбрав её из ограниченного списка.
Параметры DH всегда задаёт сервер. Эти параметры подписываются серверным ключом, это необходимо для того, чтобы параметры не могли быть заменены в момент передачи. Хотя сообщение Finished защищает весь обмен Handshake, активный атакующий мог бы подменить параметры DH на свои собственные, перехватив соединение и, в дальнейшем, сгенерировав для клиента и сервера разные, но корректные сообщения Finished - протокол DH сам по себе не защищён от атаки типа человек посередине. Поэтому подпись на данных параметрах крайне важна. В зависимости от типа сертификата, в качестве криптосистемы подписи может использоваться либо ECDSA (современный вариант), либо RSA, а устаревший алгоритм DSA сейчас не встречается.
Спецификация TLS предусматривает обмен сообщениями с типом Alert. Это предупреждения и сообщения об ошибках. Например, в случае, если сервер не смог корректно разобрать сообщение ClientHello, он отвечает сообщением Alert, содержащим код ошибки Parse Error. Сообщения Alert иногда могут быть использованы в составе атак на TLS-узлы: так, при помощи отправки этих сообщений можно "подвешивать" сессию, когда перехватывающему устройству требуется время на, например, вычисление ключа. После того, как узлы согласовали криптографический контекст и обменялись сообщениями ChangeCipherSpec - сообщения Alert передаются в зашифрованном виде. То есть, с этого момента содержание предупреждения не может быть прочитано прослушивающей трафик стороной, но сам тип записи - Alert - всё равно передаётся в открытом виде, что, соответственно, может приводить к утечке информации о состоянии узлов и соединения.
SSL-сертификаты играют важную роль в современной инфраструктуре TLS. У SSL-сертификата одно предназначение: сопоставить открытый ключ некоторому сетевому имени. Например, сопоставить ключ 0xA3VEF7...DA3107 имени example.com. SSL-сертификаты не содержат никакой секретной информации, соответственно, они не являются непосредственными носителями ключей шифрования передаваемых данных в TLS (за исключением открытого серверного ключа RSA, который может быть использован для шифрования сеансового ключа в старых режимах работы TLS).
Открытый ключ, который содержится в сертификате, принадлежит искомому серверу, с которым клиент планирует установить соединение. Однако открытый ключ может быть подменён третьей стороной на свой, имитирующий легитимный ключ сервера. Для того, чтобы можно было обнаружить подобную подмену, служит инфраструктура удостоверяющих центров, которая даёт клиенту механизм проверки принадлежности ключа. То есть, клиент соглашается верить некоторой третьей стороне (не злоумышленнику, а удостоверяющему центру - УЦ), что эта третья сторона проверила соответствие ключа и сетевого имени (в вебе это обычно домен). Результат такой проверки подтверждается подписью УЦ, которую он ставит на сертификате сервера.
Предполагается, что клиент TLS имеет в своём распоряжении некоторый набор сертификатов удостоверяющих центров, часть из этих сертификатов является корневыми, и может проверить подписи на предоставляемых сервером сертификатах, выстроив цепочку доверия, ведущую от серверного ключа к одному из доверенных корней. На практике, в браузеры встроены многие десятки корней, соответствующих различным УЦ.
В SSL/TLS используются сертификаты формата X.509, это очень старый формат, изначально разрабатывавшийся для телеграфа, но позже адаптированный для использования в Интернете, в частности, в вебе.
Сертификат представляет собой электронный документ определённой спецификацией структуры. Так, каждый сертификат содержит поля Issuer и Subject. Поле Issuer определяет имя стороны, выпустившей данный сертификат (поставившей на нём подпись), а поле Subject - имя стороны, для которой сертификат выпущен. В случае веба в Issuer обычно указано имя УЦ, а в Subject - доменное имя, адресующее сайт.
Клиент получает серверные сертификаты (обычно - это цепочка, но сертификат может быть и один) в сообщении Certificate (см. выше), выстраивает их в последовательность, где каждый сертификат удостоверяет следующий, проверяет подписи и соответствие имени серверного сертификата имени сервера, с которым планирует установить соединение. Проверка имени является важнейшим аспектом, так как злоумышленник может выпустить свой сертификат для своего сервера, но предъявлять его под именем другого сервера (перехватив сеанс тем или иным способом). В таком случае, полностью валидный сертификат злоумышленника будет отличаться от легитмного только указанным именем.
Сертификат выпускается на определённый срок, который указан в самом сертификате. Сертификат может быть отозван по какой-то причине раньше окончания срока действия. Браузеры и другие TLS-клиенты должны проверять статус отзыва сертификатов, для этого существует ряд механизмов, однако в повседневной реальности проверка отзыва так, фактически, и не работает.
Посмотрим на пример SSL-сертификата - это расшифровка полей сертификата, выпущенного для dxdt.ru УЦ WoSign, полученная утилитой openssl x509:
Version: 3 (0x2)
; Версия спецификации, обычно - 3
Serial Number: 58:04:6c:41:4b:a3:02:a0:a7:c1:13:a3:07:53:97:90
; Серийный номер сертификата. На генерацию серийных номеров наложены определённые
требования. Так, номера не должны идти подряд, не должно быть двух сертификатов
одного УЦ с одинаковым серийным номером.
Signature Algorithm: sha256WithRSAEncryption
; Алгоритм подписи: это RSA-сертификат, с RSA-подписью, использующей хеш-функцию
SHA-256.
Issuer: C=CN, O=WoSign CA Limited, CN=WoSign CA Free SSL Certificate G2
; Имя стороны, выпустившей сертификат: WoSign. Это простое текстовое поле,
определённого формата. В сертификате имеет значение каждый байт, это касается
и имени в Issuer.
Validity
Not Before: May 5 23:50:37 2015 GMT
Not After : May 6 00:50:37 2018 GMT
; Срок действия сертификата. Не ранее - не позднее.
Subject: CN=dxdt.ru
; Имя, для которого выпущен сертификат - в нашем случае это dxdt.ru. Обратите
внимание, что если не указано дополнительных имён DNS (см. ниже), сертификат
будет валиден только для для dxdt.ru, для www.dxdt.ru такой сертификат не
подойдёт.
Subject Public Key Info:
; Данные открытого ключа сервера.
Public Key Algorithm: rsaEncryption
; Алгоритм (RSA).
Public-Key: (2048 bit)
; Сам ключ (разрядность 2048 бит). Напомню, что в RSA открытый ключ состоит из
двух чисел. Первое из них - модуль, задающий кольцо, в котором будут проводиться
операции криптосистемы; именно модуль является произведением двух больших
простых чисел (p*q); второе число - шифрующая экспонента, обычно она выбирается
из типовых значений, удобных для оптимизации вычислительных операций.
Modulus:
00:c4:c5:f6:49:02:50:3b:d2:9d:b6:d6:cd:19:80:
0f:66:a0:c9:eb:6b:b5:05:c5:52:e3:d9:09:25:a0:
2e:86:d8:e5:20:0c:39:66:bb:03:57:3e:23:a5:f7:
98:2d:99:16:f6:70:d4:87:c6:76:86:79:78:6a:4f:
bd:61:6a:89:23:7d:8c:dd:fc:8b:8f:d6:91:a5:33:
ed:df:35:b0:ee:cb:e7:43:1e:5a:8c:7e:e9:49:c3:
82:2a:95:9f:f1:a6:86:61:22:97:81:df:2b:55:b8:
f4:ad:0e:c1:f6:d2:c6:66:31:d3:57:a0:51:1e:5f:
7e:ce:d3:ba:27:21:cd:16:66:e5:22:e5:64:45:46:
64:8f:6a:f1:6c:2d:f2:8e:28:c1:72:27:3b:bf:8a:
10:56:c0:16:94:ec:60:c1:70:c0:c2:3d:28:8b:5c:
4c:44:e2:ac:67:1a:e7:93:ec:ec:1f:9b:a1:30:f6:
71:95:77:8d:8d:d4:d4:43:4e:1f:5e:5b:13:a9:48:
1d:c2:a3:87:26:e6:65:8a:ff:75:fb:84:c9:67:e3:
88:51:28:b2:2c:45:3a:7f:37:68:dd:da:14:73:c7:
71:b7:1c:ea:ea:d3:08:b4:a8:6b:8d:df:f6:be:71:
07:f0:fe:5c:b4:4e:15:de:2e:d8:96:8b:15:96:83:
b4:c3
; Модуль.
Exponent: 65537 (0x10001)
; Экспонента.
; Далее идут расширения формата, играющие важную роль в современной
инфраструктуре использования SSL-сертификатов. Ряд из этих расширений
имеет прямое отношение к работе TLS.
X509v3 extensions:
X509v3 Key Usage:
Digital Signature, Key Encipherment
; Указание на допустимое использование ключа из сертификата: в данном
случае ключ может быть использован для создания подписи и для шифрования
других ключей. Первый вариант необходим для генерации сеансового ключа
по алгоритму Диффи-Хеллмана; второй - для передачи клиентом зашифрованного
ключа.
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
; Дополнительные параметры использования ключа: допускается применение для
аутентификации веб-клиента и веб-сервера (обычное использование).
X509v3 Basic Constraints:
CA:FALSE
; Ограничения на использование ключа и сертификата: данный сертификат не
является сертификатом УЦ, то есть от него не должны выпускаться другие
сертификаты. Технически, никаких проблем с выпуском ещё одного сертификата,
подписанного ключом данного, нет. Однако при выстраивании цепочки доверия,
клиент (например, браузер), должен сверять статусы сертификатов и доверять
только подписям, полученным от сертификатов, для которых в этом поле указано
CA:TRUE. Интересно, что браузер Microsoft IE длительное время, до 2003 года,
некорректно проверял статус сертификата (из-за ошибки в коде), что позволяло
выпускать валидные, с точки зрения IE, сертификаты для любого имени, приобретя
обычный серверный сертификат у того или иного УЦ.
X509v3 Subject Key Identifier:
37:93:60:97:E7:8A:3C:FF:C6:68:6A:DD:97:92:A5:32:59:87:8A:E4
X509v3 Authority Key Identifier:
keyid:D2:A7:16:20:7C:AF:D9:95:9E:EB:43:0A:19:F2:E0:B9:74:0E:A8:C7
; Специальные идентификаторы ключей, позволяющие клиенту быстрее найти
соответствующие ключи в сертификатах в своих хранилищах. Это особенно актуально
для поиска подходящего ключа УЦ, так как ускоряет построение цепочки валидации.
Authority Information Access:
OCSP - URI:http://ocsp6.wosign.com/ca6/server1/free
CA Issuers - URI:http://aia6.wosign.com/ca6.server1.free.cer
; Адреса: ответчика OCSP (Online Certificate Status Protocol) - это протокол
онлайн-проверки статуса отзыва сертификата, - и сертификата УЦ, от которого
выпущен данный сертификат.
X509v3 CRL Distribution Points:
Full Name:
URI:http://crls6.wosign.com/ca6-server1-free.crl
; Существует исторический метод отзыва сертификатов при помощи выпуска списков
отозванных сертификатов (CRL - Certificate Revocation List). Данное поле
содержит адрес, где список публикуется.
X509v3 Subject Alternative Name:
DNS:dxdt.ru, DNS:www.dxdt.ru, DNS:tls.dxdt.ru
; Дополнительные имена. Это расширение очень полезно, так как позволяет указать
дополнительные имена, для которых валиден данный сертификат. Например, здесь
указано www.dxdt.ru и tls.dxdt.ru - последнее имя позволяет вам читать этот
материал через безопасное соединение на сайте tls.dxdt.ru, который находится
на другом, относительно dxdt.ru, сервере. Более того, данный сертификат вообще
не используется на dxdt.ru, хотя домен и указан в Subject.
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.36305.6.1.2.2.1
CPS: http://www.wosign.com/policy/
; Перечень политик, которым соответствует данный сертификат. Политики
устанавливаются УЦ (в соответствии с некоторыми нормами, если УЦ желает, чтобы
его корни были включены в распространённые браузеры), но являются чисто
административным инструментом, напрямую не относящимся к криптографии, хотя
и влияющим на используемые механизмы. Например, именно политика определяет, будет
ли сертификат расцениваться как сертификат "Расширенной проверки" (EV), а такие
сертификаты, в свою очередь, требуют использования некоторых дополнительных
криптографических механизмов.
Signature Algorithm: sha256WithRSAEncryption
09:20:65:da:92:9f:93:d2:96:55:80:51:8e:06:3a:37:c1:26:
33:af:da:2a:63:0e:da:c2:b2:c9:31:80:b3:de:9a:b2:48:ce:
3b:11:ee:a7:81:fc:9e:48:5d:a0:59:6f:b6:d0:e7:da:c9:86:
47:79:ef:ea:71:cd:72:2f:b1:7d:ac:84:88:84:c5:a8:19:47:
4d:6b:1c:e0:8f:81:b0:c9:13:95:c9:f7:27:7a:93:2b:2c:08:
ac:c8:69:2d:0d:4f:c6:4d:b7:18:96:4f:50:c0:0f:23:20:cf:
22:28:5d:fd:e5:89:dd:c9:1d:9c:c6:b3:54:4b:65:e5:8d:2e:
26:07:85:fb:d4:d8:23:ed:30:dc:60:33:da:9e:85:79:37:1d:
ec:04:87:ad:c2:00:7b:87:06:7e:ee:26:27:25:ef:4a:5c:8f:
64:0f:77:28:3f:69:61:37:36:f8:40:78:8d:7d:00:f3:2f:e7:
fb:5b:c6:52:c4:5e:e5:19:54:06:ad:3f:7d:48:19:59:82:ef:
46:96:3b:fc:71:3f:4f:99:94:d5:1d:c2:80:44:e6:af:3c:cf:
01:c2:4c:e7:e8:53:8b:56:ad:06:c7:c9:23:90:7e:93:1d:f5:
f6:2e:29:21:ae:13:23:da:7a:f9:04:ea:62:8c:e3:24:f1:05:
db:0d:e5:1f
; Значение подписи сертификата. Подпись вычисляется от значения хеш-функции, аргументом
которой является весь сертификат (за исключением, соответственно, подписи).
Генерируется подпись при помощи секретного ключа УЦ, соответствующего сертификату
с именем, указанным в Issuer.
Итак, SSL-сертификаты являются важным элементом TLS, позволяющим проводить аутентификацию. Ключи из сертификатов используются при генерации общего секрета. В теории, возможно установление TLS-соединения без использования сертификатов (это не запрещено спецификацией, а серверное сообщение Certificate не является строго обязательным), однако массово применяемые на практике методы генерации сеансовго ключа основываются на использовании серверного сертификата (а точнее - на использовании открытого ключа из сертификата).
Основные современные претензии к SSL-сертификатам касаются сложившейся административной структуры УЦ. Так, пока что никакая распространённая технология не мешает УЦ выпустить "подменный" сертификат, позволяющий прозрачно перехватывать TLS-соединения, используя атаку типа "человек посередине" (см. ниже в разделе про перехват HTTPS). Но такие технологии разрабатываются, к ним относится инициатива Certificate Transparency (поддерживаемая Google), Certificate Pinning или Public Key Pinning, когда в браузерах сохраняются (и обновляются) заведомо корректные для данного узла сертификаты или открытые ключи, а также технология DANE, использующая DNS в качестве дополнительной системы контроля.
Как рассказано выше, TLS использует для защиты информации шифронаборы. Шифронабор (Cipher Suite) позволяет обеспечить не только сокрытие информации, но и её целостность. Возможно использование TLS без шифрования, однако это не является распространённым случаем.
В терминологии TLS существуют шифрующие и расшифровывающие функции. Эти функции работают с криптографическим контекстом соединения, о котором договорились узлы. После того, как узлы обменялись сообщениями ChangeCipherSpec (см. выше), все TLS-сообщения шифруются. Шифрующая функция преобразует открытый текст записи (строго говоря, после сжатия, но в современной реальности TLS-сжатие обычно не используется) в секретный (зашифрованный), расшифровывающая функция выполняет обратную операцию. Для того, чтобы шифрующие и расшифровывающие функции успешно работали на обоих узлах и требуется выработка общего криптографического контекста - это происходит в рамках обмена сообщениями Handshake.
В TLS могут использоваться и классические потоковые, и блочные шифры, последние - в различных режимах. Напомню, что блочные шифры отличаются от потоковых тем, что работают с блоками фиксированной длины и требуют разбиения потока байтов на такие блоки; в блочном шифре каждый байт шифруется в составе блока байтов. Потоковые шифры, напротив, работают прямо с потоком байтов, без разбиения, каждый байт шифруется соответствующим байтом так называемой гаммы ("ключевого потока"). Существуют режимы использования блочных шифров, которые позволяют рассматривать их, фактически, как потоковые. Классический потоковый шифр TLS - RC4, который сейчас считается устаревшим. Блочные шифры требуют использования дополнения (padding), в случае, если открытый текст не кратен размеру блока, а также имеют ряд других особенностей, ведущих в TLS к уязвимостям. Суперсовременная рекомендация: блочный шифр AES в режиме GCM, который является режимом шифрования с аутентификацией, к тому же, сходным по свойствам с потоковым шифром. Типичный для современного Интернета вариант: AES в режиме CBC (это блочный режим, с дополнением).
Внутри записи защищённые данные размещаются вместе с кодом аутентификации (MAC), если последний используется. В типовом случае код аутентификации вычисляется до шифрования, и шифруется вместе с открытым текстом. Как указано выше, это неверный метод, представляющий собой один из серьёзных архитектурных недостатков современных версий TLS. Проблема состоит в том, что MAC проверяется после расшифровывания сообщения и, если его значение оказалось некорректным, реализация TLS должна сообщить об ошибке, из-за этого активный атакующий, манипулируя шифрованным текстом, может использовать расшифровывающий узел в качестве криптографического оракула, который постепенно раскроет весь секретный текст. На этом основано несколько практических атак на TLS (см. ниже).
Запись с защищёнными данными также содержит необходимую для работы конкретного шифра дополнительную информацию - обычно это инициализирующие векторы. Как читатель помнит, у каждой TLS-записи есть открытый заголовок, поэтому прослушивающая канал сторона всегда знает сколько записей было передано между узлами. Эта особенность может послужить транспортом для утечки информации.
С шифронабором связано несколько криптографических примитивов, к которым применимо понятие разрядности. Возьмём в качестве примера шифронабор TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - здесь есть разрядность ключа RSA (рекомендуемое значение - 2048 бит или более); разрядность симметричного ключа AES (указано 128 бит) и, наименее важная, разрядность хеш-функции (256 бит). Есть ряд рекомендаций по выбору разрядности ключей для криптосистем в TLS. Так, максимальная степень защиты должна применяться к сеансовым данным, потому что ради их защиты TLS и используется. Эти данные защищает симметричный шифр. 128 бит для AES считаются достаточными, 256 бит - обеспечат защиту уже на грани разумного. Большие длины ключей для добротного симметричного алгоритма не имеют никакого смысла: дело в том, что полный перебор уже и 2^128 вариантов вычислительно невозможен за разумное время. В качестве симметричного шифра может служить не только AES, но и CAMELLIA, и даже корейский шифр ARIA. В теории, возможно и использование шифров ГОСТ, однако, к сожалению, с ними есть немалые проблемы в реализации программного обеспечения, кроме того, они не входят в типовой список IANA.
Криптосистемы с открытым ключом служат в TLS для аутентификации. Заметьте, что задача выработки общего секрета - эквивалентна аутентификации узла, с которым устанавливается соединение. Действительно, при использовании слабого ключа аутентификации, атакующая сторона может перехватить сессию, выдав себя за сервер (например). Однако на практике это означает проведение сложной активной атаки, которая представляет собой менее вероятную угрозу, чем простое прослушивание канала, от которого защищает симметричный шифр. Естественно, перехвативший сессию атакующий уже не будет испытывать проблем со взломом симметричного шифра. Тем не менее, защита процедуры аутентификации нередко перемещается на второе по важности место, после защиты потока данных.
Хорошим примером, почему это происходит, является следующее наблюдение (подсказанное Z.T. в комментариях на dxdt.ru): если вы испльзуете нестойкий алгоритм для аутентификации узла, то, в обозримой перспективе, например, через десять лет, этот алгоритм может быть взломан; взломавшая алгоритм сторона получает возможность подделывать сессии, но как атаковать сессию десятилетней давности? Никак. А вот если взломан шифр, защищающий передаваемый трафик, то становится возможным прочитать трафик, записанный десять лет назад. В этом может быть смысл, так как он, возможно, содержит до сих пор актуальные сведения.
Весьма полезной практикой является разумное выравнивание стойкости используемых криптосистем. Например, в подавляющем большинстве случаев не имеет смысла использовать RSA-ключ длиной в 4096-бит, если ваш TLS-сервер всё ещё поддерживает SSLv3, а в качестве симметричного шифра применяет DES с 56-битным ключом.
TLS имеет дефекты на уровне протокола, но гораздо больше дефектов обнаруживается в его реализациях. Например, до сих пор можно нередко встретить поддержку заведомо нестойких, устаревших шифронаборов, использующих ключи длиной менее 128 бит. Иногда встречается и поддержка SSLv2, который давно не является хоть сколь-нибудь защищённым на практике. Использование устаревших протоколов и шифронаборов означает, что, в теории, атакующий может провести понижение уровня защиты до шифра, уровня, который может взломать на лету, после чего подделает сообщения Finished, став, тем самым, посредником в сессии. (Посредник может прослушивать весь трафик.) Однако современные браузеры не позволяют использовать заведомо нестойкие сочетаний криптосистем и не поддерживают устаревшие версии SSL/TLS, что сводит поверхность для атаки к минимуму. Тем не менее, неверно было бы считать, что проблем здесь нет: существует большое число устаревших клиентских устройств, которые всё ещё поддерживают старые протоколы, по историческим причинам среди них немало важных узлов, например таких, как домашние WiFi-роутеры.
Мы уже упоминали необходимость дополнения данных при использовании блочных шифров, которая приводит к появлению нежелательных криптографических оракулов (такой оракул помогает "угадывать" секретные тексты). Есть целый класс оракулов, которые в англоязычной литературе называются Padding oracle, породивший несколько нашумевших атак. Одно из первых использований оракула, связанного с дополнением данных, относится к 2003 году. Атака, сконструированная Сержем Воденэ (Serge Vaudenay), основывалась на том факте, что реализация протокола SSL возвращала разные сообщения об ошибках в зависимости от того, удалось ли после расшифровки записи обнаружить корректное дополнение, но не совпал код аутентификации (MAC), или корректного дополнения данных обнаружить не удалось. Именно последствия этой атаки были устранены только спустя семь лет в веб-сервере IIS. Видимое "снаружи" различное поведение программной реализации TLS в зависимости от того, были в TLS-записи обнаружены корректные дополнение и MAC или некорректные, - традиционный фундамент для атак, актуальный до сих пор: на нём пострены атаки BEAST, CRIME и POODLE. Эти атаки привели к тому, что сейчас не рекомендуется поддержка SSLv3 (и, естественно, более ранних версий). Шифры, работающие в режиме GCM - а именно, AES, - не используют уязвимого дополнения блоков, соответственно, ликвидируют основу для большинства оракулов.
Отдельный большой класс атак составляют атаки, использующие побочные каналы утечки. Однако они в большей степени связаны с аппаратурой, поэтому мы рассмотрим их позже и за пределами данного текста.
В 2015 году появилась атака Logjam, связанная с использованием устаревших шифронаборов, а именно с протоколом Диффи-Хеллмана в так называемом "экспортном" варианте ("экспортные" шифры относятся к первому периоду криптовойн, к 90-м годам 20 века, когда был запрещён экспорт стойкой криптографии за пределы США, а вместо стойкой экспортировались заведомо нестойкие криптосистемы). Logjam не использует оракулов, но позволяет провести понижение уровня секретности, навязав клиенту и серверу нестойкий вариант DH, на группе малой разрядности (512 бит). Это возможно из-за архитектурного недостатка протокола: предложенные клиентом шифронаборы никак не удостоверяются, при этом клиент принимает любые параметры DH, переданные сервером, если только может их обработать. (В распространённых браузерах проблема была исправлена летом 20015 года.)
Для большого класса добротных, стойких криптосистем, широко используемых сейчас в TLS на практике, возможно восстановление сеансового ключа из записанного трафика, при условии, что атакующая сторона имеет в своём распоряжении секретный серверный ключ (ключ из пары, открытая часть которой указывается в сертификате сервера). Это означает, что получив секретный ключ сервера (не сеансовый!), кто-то может расшифровать накопленные ранее записи TLS-сеансов между клиентом и сервером. Упомянутый ключ может быть раскрыт разными способами: например, его можно скопировать с сервера, если есть доступ, или он может просто оказаться нестойким (такое случается не так редко, как можно подумать). Сгенерированный по протоколу Диффи-Хеллмана сеансовый ключ также может стать известен злоумышленнику, либо в результате активной атаки на уровне канала (как Logjam), либо в результате получения доступа к серверу, где сеансовый ключ может сохраняться достаточно долго, и не обязательно в защищённом хранилище. Очевидно, что если атакующая сторона получила соответствующий сеансовый ключ, то она может раскрыть TLS-трафик. Секретный серверный ключ или SSL-сертификат для этого не требуются.
Возможность выпустить SSL-сертификат для атакуемого домена сама по себе никак не помогает расшифровать TLS-трафик, идущий в этот домен, даже если трафик записывается. Процедура выпуска сертификата не требует передачи секретного ключа в удостоверяющий центр (передаётся только открытый ключ), поэтому у удостоверяющего центра секретного серверного ключа тоже нет, за исключением распространённого сейчас случая, когда заказчик поручает генерацию такого ключа УЦ (что, впрочем, является административной, а не технической, проблемой).
Однако валидный SSL-сертификат, выпущенный для атакуемого домена, позволяет провести незаметную для пользователя атаку типа “человек посередине”. Для этого требуется, чтобы между атакуемым пользователем и сервером существовал управляемый атакующим узел, активно перехватывающий трафик. Этот узел выдаёт себя пользователю за легитимный сервер, предъявляя тот самый валидный сертификат. Пассивное прослушивание канала не позволяет раскрыть TLS-трафик подобным образом – наличие сертификата или секретных ключей УЦ никак тут не помогает.
Перехват TLS-соединения может быть автоматизирован – существуют специальные узлы-прокси (SSL-прокси), которые выполняют такой перехват на лету, в том числе, генерируя нужные сертификаты. В такой прокси должен быть загружен сертификат и секретный ключ, позволяющие подписывать другие сертификаты (например, годится промежуточный сертификат УЦ, выпущенный для этих целей и соответствующий ему секретный ключ). Такой “человек посередине” не работает при наличии некоторых дополнительных мер: например, установление TLS-соединения требует взаимной аутентификации, и перехватывающему узлу недоступен клиентский секретный ключ (либо ключи УЦ, удостоверяющего клиентский ключ); или – пользовательский браузер ведёт реестр отпечатков открытых ключей сервера, которым он доверяет; или – пользователь применяет дополнительные источники сведений о разрешённых ключах и сертификатах, которые недоступны для подмены на перехватывающем узле (таким источником может служить DNS, либо другая база данных).
На практике, для массовых сервисов, возникают другие технические направления для атак, напрямую не связанные с какими-то особенностями TLS.
Так, массовые онлайн-сервисы используют так называемый SSL termination: то есть, пользовательский TLS-трафик в зашифрованном виде доходит только до пограничного прокси, где благополучно транслируется в открытый протокол, обычно это HTTP, сответствующий HTTPS, который дальше ходит по внутренним (в логическом, а не техническом смысле) сетям сервиса в открытом виде. Тотальный HTTPS, с ростом числа клиентов, быстро превращается в неподъёмную, плохо масштабируемую технологию, поэтому SSL termination является весьма распространённым решением. Если система инспекции трафика (DPI) находится внутри сетей сервиса, за таким пограничным SSL-прокси, то никакой TLS ей не помешает. Именно так получают доступ к данным платёжных систем и веб-почты специальные службы, располагающие, на законных основаниях, собственным оборудованием DPI за пограничными прокси.
Сеансовые ключи могут экспортироваться сервером наружу, в другие системы, которые, например, осуществляют балансировку нагрузки или "очистку" трафика. В некоторых случаях вообще используются услуги третьей стороны для организации TLS-соединения. Кроме того, внутренний трафик распределённых сервисов с легкостью ходит между узлами и дата-центрами по арендованным у крупных операторов каналам связи в открытом виде, такой трафик может прослушиваться, хотя для пользователя он выглядит как TLS-соединение.
Иными словами: TLS не предоставляет абсолютной защиты, но в подавляющем большинстве сценариев использования Интернета этот протокол делает обмен информацией хорошо защищённым; для повышения скрытности и безопасности, если такое требуется, TLS должен использоваться совместно с другими решениями.