TLS: двадцать лет спустя

Александр Венедюхин

Группа технологий TLS - самый распространённый инструмент защиты информации в современ­ном Интернете. При помощи TLS защищают не только веб-трафик, но и электронную почту, а так­же целый ряд других сервисов, в том числе, трафик мобильных приложений. Технологии защиты информации — интересный, бурно развивающийся сектор интернет-технологий, относящийся к фундаменту глобальной Сети. Например, без TLS невозможна работа банковских онлайн-сер­висов, однако в современной ситуации защищённый протокол необходим для всякого веб-сайта. Успешное внедрение TLS требует понимания архитектуры протокола.

В 90-х годах прошлого века, вместе с приходом веба, Интернет стал активно превращаться в транспорт для коммерческой активности. Неотделимым элементом этой активности являлась необходимость совершения различных финансовых и околофинансовых транзак­ций. Подобные транзакции не могут проводиться без средств защи­ты информации, а традиционный веб был полностью открыт — не только открыт для прослушивания, но и вообще никак не защищён. Так появился первый прототип технологии, которую сейчас называ­ют TLS/SSL (Transport Layer Security / Secure Sockets Layer). Сейчас оба варианта обозначения — TLS и SSL — могут использоваться в каче­стве синонимов, но каноническим является имя TLS. Аббревиатура TLS появилась в качестве замены обозначения SSL после того, как протокол окончательно стал интернет-стандартом.

То, что первоначальным предназначением TLS являлось всего лишь получение более или менее безопасного канала коммерческих онлайн-транзакций, а не передача секретной информации, никак не помешало этой технологии превратиться в краеугольный камень современного здания пользовательской «приватности» и «безопас­ности» в сети. Самым распространённым, с точки зрения пользова­теля, применением TLS сейчас является защищённый веб-протокол HTTPS. На него сейчас принято полагаться даже в случае обмена критически важной информацией, причём не только информаци­ей рядового пользователя: HTTPS (и, соответственно, TLS) нынче приходится встречать и в промышленных системах управления (SCADA), где от надёжности протоколов зависит работоспособность технологического оборудования.

Новая, весьма популярная тема — Интернет вещей: предполагается, что в обозримом будущем едва ли не каждый предмет человеческого быта превратится в «интеллектуальное устройство», которое будет взаимодействовать с различными глобальными информационными системами, в том числе, с другими интеллектуальными предметами быта. Выстроить такую систему без инструментов защиты инфор­мации вряд ли возможно, так что распространённость TLS только увеличится — недалёк тот замечательный день, когда TLS придёт не только в ваш смартфон и телевизор, как сейчас, но и в зубную щётку, и в кроссовки. Следующая версия базового протокола веба — HTTP/2, — которая близка к финальной стадии разработки, также бу­дет включать TLS по умолчанию. Более того, в HTTP/2 средства уста­новления защищённого соединения непосредственно встроены в про­токол, что составляет одно из ключевых отличий от HTTP. Заметьте, TLS используется и в электронной почте. Иными словами — без TLS нынче нельзя и шагу ступить. Если, конечно, ходить безопасно.

Впервые SSL реализовали в качестве проприетарной технологии в браузере Netscape Navigator, одном из первых веб-браузеров. Первая версия протокола никогда не была официально опубликована. Она так и осталась внутренней разработкой Netscape, развивавшейся в 1994-95 годах. Спецификация SSLv2 — следующая, вторая версия — из-за обнаруженных дефектов и организационных накладок (кроме прочего, связанных с патентами и интеллектуальной собственно­стью) так и не вышла из состояния черновика (draft). Более того, хоть в SSLv2 и скорректировали отдельные дефекты и уязвимости v1, протокол всё равно оказался изначально ненадёжным, по причи­не наличия целого ряда архитектурных недочётов. Необходимо под­черкнуть, что это вполне нормальная — для открытых интернет-про­токолов — эволюция: рекомендации постепенно улучшались, так сложилось исторически. Процесс улучшения, идущий с перемен­ным успехом, не прекращается до сих пор. Иногда можно услышать мнение, что если бы SSL разрабатывали только инженеры специ­альных служб США, то сразу был бы получен качественный прото­кол. Но, во-первых, АНБ и так приложило руку к становлению TLS, а во-вторых, веб всё же был слишком новым направлением, чтобы кто-то мог гарантировано выдать безошибочный рецепт защищён­ного протокола. Ведь некоторые специалисты в 90-х годах всерьёз полагали, что в Интернете можно без изменения использовать меха­низмы защиты, подобные четырёхзначным PIN-кодам банкоматов. Кроме того, становление первых версий SSL пришлось на период так называемых криптовойн (их второй эпохи), когда правительство США активно регулировало развитие общедоступных технологий защиты информации, вводя разнообразные «экспортные ограниче­ния» и прочие препоны.

Эти «экспортные ограничения» из 90-х годов прошлого века аукнулись TLS не далее чем в 2015 году, двадцать лет спустя:
использование заведомо небезопасных алгоритмов в паре с древним архитектурным дефектом протокола — обеспечили наличие долго­играющей уязвимости, ставшей в 2015 году широко известной как Logjam.

SSLv2 давно (более 15 лет назад) и без оговорок признан небезопасным, поэтому сейчас не должен ис­пользоваться: если в 2015 году ваш сервер или клиент всё ещё поддерживает SSLv2, можно смело сказать, что у вас нет безопасного канала.

Протокол SSLv3 ― первая версия SSL, получившая полноценную спецификацию RFC, правда, в статусе исторического документа и значительно позже появления самого протокола: RFC 6101. Имен­но на время SSLv3 пришлось становление TLS как полноценной интернет-технологии. SSLv3 в 2015 году «официально» перешёл в статус не рекомендуемых: в июне этого года выпущен документ RFC 7568, требующий исключить SSLv3 из разряда поддерживаемых клиентами и серверами протоколов. Теперь остались только версии TLS.

Для всех трёх версий TLS есть полноценные RFC (RFC 2246, RFC 4346, RFC 5246), кроме того, многие аспекты применения TLS опи­саны в других, дополнительных RFC. В общей сложности, толь­ко ядро важнейших для TLS RFC насчитывает сейчас более дю­жины документов (в этой популярной статье мы не будем их все перечислять). К сожалению, местами эти документы не очень про­зрачны и однозначны в своих рекомендациях, а кроме того, они на­сыщены взаимными уточнениями и исправлениями. TLS — весьма непростая технология. Это считается её главным недостатком, так как сложность в системах защиты информации всегда ведёт к ошиб­кам и уязвимостям.

Существенное влияние на текущее состояние дел оказывает прак­тика реализации TLS. Прежде всего — в браузерах, именно они, вместе с крупнейшими по веб-трафику сервисами, служат тем ло­комотивом, который вытягивает из туннеля всё новые и новые ва­гоны-дополнения. Нередко стандартным становится отступление от рекомендаций RFC. Показательным примером является порядок SSL-сертификатов в ответах TLS-серверов: RFC предписывает стро­гий порядок следования — от серверного сертификата к сертифика­там удостоверяющего центра. Однако на практике не все серверы этот порядок соблюдают. Обычно — из-за незнания тонкостей про­токола администратором, или просто по ошибке. Требования RFC, это, конечно, хорошо, но распространённые браузеры успешно иг­норируют неверный порядок сертификатов, пытаясь проверить на возможность валидации все их перестановки. Казалось бы, такая мягкая практика — весьма полезна. И это действительно так. Однако многие, так сказать, TLS-пуристы, настаивают, что в криптографии важна именно строгость, до последнего бита — иначе можно собрать кучу проблем.

Слои, шифры и контекст

Как работает TLS? Прежде всего, нужно договориться о контексте этой работы (понятие контекста, кстати, является важнейшим и для самого протокола, так что мы не зря его упомянули). Протокол TLS предназначен для создания между двумя узлами сети защищённого от прослушивания и подмены канала связи, пригодного для пере­дачи произвольных данных в обоих направлениях (шифрование и аутентификация сообщений). TLS также должен позволять провести проверку того, что обмен данными происходит между именно теми узлами, между которыми и планировался (аутентификация узлов). Для работы TLS требует существующего между узлами «потокового» соединения (однако есть «диалект» под названием DTLS, который пред­назначен для работы в режиме нега­рантированной доставки пакетов, без потокового соединения, например, по UDP; но DTLS мы не рассматриваем).

TLS предполагает, что между узлами установлено относительно надёжное соединение, поэтому, например, про­токол TLS не охватывает повторную отправку потерянных пакетов данных. Обычно TLS работает поверх TCP. По­следний позволяет надёжно обмени­ваться данными, но содержимое па­кетов (за исключением специальных случаев) может быть легко прочитано, если у третьей стороны есть доступ к каналу связи. Кроме пассивного про­слушивания, TCP позволяет легко за­менить сами пакеты, а также частично подменить передаваемые в них дан­ные. Именно для защиты от этих угроз и используется TLS.

Таблица 1  Таблица уровней работы TLS: от пользователя (наверху) ― к физическому каналу (внизу)

В TLS есть своя иерархия уровней протокола (таблица 1), там ис­пользуются два «слоя»: нижний ― это уровень TLS-записей, где пере­даются данные. Записи проще всего представлять как блоки данных, имеющие установленный формат. Шифрование, коды аутентифика­ции ― явления этого, нижнего слоя. Уровнем выше ― другой слой: здесь расположились управляющие логические конструкции, состо­ящие из последовательностей TLS-сообщений, отвечающих за уста­новление защищённого канала и за контроль его успешной работы. Ниже мы практически не касаемся уровня TLS-записей, а больше говорим о том, что происходит на уровне сообщений. Сообщения, конечно, также имеют установленный формат.В целом, при исполь­зовании TLS предполагается, что атакующий может как угодно вме­шиваться в канал связи, в том числе активно подменять пакеты. За­дачи TLS состоят в обеспечении трёх ключевых моментов:

• конфиденциальность, то есть защита от утечек передаваемой ин­формации;
• обнаружение подмены, то есть сохранение целостности передава­емой информации;
• аутентификация узлов, то есть обеспечение проверки подлинно­сти узлов, обменивающихся информацией.

TLS пытается решить перечисленные задачи, но с некоторыми «граничными условиями». И у нас нет никаких оснований пола­гать, будто TLS решает данные задачи полностью. Это важнейший момент практического применения TLS. Нередко приходится слы­шать, что TLS полностью обеспечивает и конфиденциальность, и целостность, и аутентификацию. Но такая оценка является большой ошибкой. Да, протокол и его реализации пытаются решить описан­ные задачи, однако TLS в целом не обладает доказанной стойкостью, как не обладают ей и многие важнейшие составляющие части прото­кола. Косвенным результатом этого является тот поток уязвимостей, который устремился на страницы технической прессы, как только за протокол взялось большое количество опытных исследователей. Верна такая рекомендация: не следует доверять TLS и связанным технологиям свою жизнь или жизнь других людей.

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

Вернёмся к контексту. В TLS для успешного обмена данными узлы должны находиться в одном контексте, это означает, что они успешно согласовали целый ряд криптографических параметров, среди которых исходные данные для выработки сеансового ключа шифрования, используемый шифр, код аутентификации сообщений и другие. Часть этих параметров объединяется спецификациями в типовой, фиксированный набор: Cipher Suite, или, на русском, — шифронабор. Шифронабор — важнейшая составляющая практики использования TLS. Шифронабор определяет криптосистемы, ко­торые применяются при обмене информацией в данном сеансе. В шифронабор входят: криптосистема электронной подписи, симме­тричный шифр, алгоритм дайджеста сообщений (хеш-функция).

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

В современной криптографии известны два типа криптосистем: симметричные и асимметричные (к последним относятся и крипто­системы с открытым ключом, например, RSA). В симметричных системах знание шифрующего ключа позволяет легко получить расшифровывающий ключ, то есть расшифровать секретное сооб­щение. В используемых сейчас массовых симметричных криптоси­стемах шифрующий и расшифровывающий ключи просто совпада­ют. Другими словами, симметричные системы подразумевают, что обе стороны, обменивающиеся информацией по закрытому каналу, знают некий общий секрет ― например, секретный симметричный криптографический ключ, который позволяет как шифровать, так и расшифровывать сообщения. Этот секрет, вместе с тем, не должен быть известен прослушивающей канал стороне: иначе эта сторона сможет легко расшифровать сообщения.

Примерами симметричных криптосистем являются как наивные исторические шифры — например, шифры простой замены букв текста на естественном языке, где в качестве ключа может высту­пать та или иная перестановка алфавита, — так и современные шиф­ры, вроде AES и 3DES. Базовая идея современных симметричных криптосистем, используемых на практике, состоит в «перемешива­нии» символов открытого текста: традиционно такими символами являются биты. Ключом в массовых современных симметричных криптосистемах является целое число достаточно большой разряд­ности ― 128 бит и более. Основной объём зашифрованного трафика в Интернете шифруется именно симметричными криптосистемами. Главной проблемой использования симметричных криптосистем является распределение ключей: очевидно, ключ не может быть пе­редан по открытому каналу, а для организации защищённого кана­ла ― нужен ключ.

Асимметричные криптосистемы не позволяют простым способом получить из шифрующего ключа расшифровывающий. То есть сто­рона, знающая шифрующий ключ, может только зашифровать не­которое сообщение, но не может прочитать другие зашифрованные сообщения. Применительно к асимметричным криптосистемам принято говорить о паре ключей: открытом и секретном. Отсюда другое название асимметричных систем ― системы с открытым ключом. Открытый ключ является шифрующим. Секретный ― по­зволяет расшифровать сообщение. Асимметричные криптосистемы ― новое изобретение, они появились в 70-х годах прошлого века. Поэтому наивных и исторических примеров здесь нет, а примером современной распространённой криптосистемы является RSA. Фун­даментальной идеей современных асимметричных криптосистем является однонаправленная функция, имеющая «секретный ход», который позволяет эту функцию обратить, если известен дополни­тельный параметр. Однонаправленная (односторонняя) функция позволяет легко вычислить «зашифрованный» блок, но не позво­ляет простым способом выполнить обратную операцию ― найти аргумент по известному зашифрованному блоку. «Секретный ход» однонаправленной функции позволяет найти аргумент, то есть рас­шифровать блок, но требует использования дополнительного пара­метра ― таким параметром и является секретный ключ. Так, в слу­чае с криптосистемой RSA, однонаправленной функцией является возведение в фиксированную степень (называемую шифрующей экспонентой) в некотором алгебраическом кольце, а секретным параметром, позволяющим обратить операцию, является знание обратного к шифрующей экспоненте показателя степени ― расшиф­ровывающей экспоненты. Таким образом, в криптосистеме RSA от­крытый ключ состоит из модуля (числа, задающего кольцо, в кото­ром производятся операции) и шифрующей экспоненты; секретный ключ — из секретной экспоненты (модуль используется тот же).

Также различают блочные и потоковые шифры. Блочный шифр, как нетрудно догадаться по названию, работает с блоками входных данных фиксированной длины; он требует разбиения открытого текста на подходящие блоки. Потоковый шифр ― работает с непре­рывным потоком входных данных, без разбиения на блоки. Суще­ствуют режимы шифрования блочных шифров, по сути, превраща­ющие их в потоковые.

Необходимо различать шифры, предназначенные для сокры­тия информации, и системы электрон­ной подписи, предназначенные для аутентификации, установления под­линности информации и/или её источ­ника. Криптосистема RSA, как и вся­кая криптосистема с асимметричным шифром, может быть использована и в качестве шифра, и в качестве системы электронной подписи. Однако другие системы электронной подписи не могут служить шифрами. К таким системам от­носится ECDSA ― современная система, работающая на эллиптических кривых.

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

Взглянем на шифронаборы, использу­емые в TLS, чуть подробнее. Криптоси­стема электронной подписи служит для аутентификации сервера и выработки общего для узлов секретного ключа симметричной системы: подробнее об этом рассказано ниже. Симметричная криптосистема (обычно это блочный шифр, используемый в том или ином ре­жиме) обеспечивает шифрование потока данных. Код аутентификации сообще­ний (MAC) служит для проверки целост­ности, он позволяет определить, что дан­ные не изменялись в процессе передачи.

Типовые шифронаборы находятся в реестре, который ведёт IANA, а обозна­чаются специальной строкой символов. Например, TLS_RSA_WITH_AES_128_ CBC_SHA означает, что будет использо­вана криптосистема RSA для передачи сеансового ключа, AES со 128-битным ключом в режиме CBC в качестве сим­метричного шифра, SHA-1 в качестве хеш-функции HMAC. Современной ре­комендацией является использование шифров в режиме аутенти­фицированного шифрования (AEAD), из доступных вариантов — это AES в режиме GCM. Особенностью этого режима шифрования явля­ется то, что механизм аутентификации встроен в алгоритм приме­нения блочного шифра, поэтому дополнительный код аутентифика­ции сообщению не требуется.

Другой важнейший протокол, используемый в TLS, это протокол Диффи-Хел­лмана. Он не является шифром или алгоритмом электронной подписи (строго говоря, на основе протокола можно построить асимметричную криптосистему; также существует математически родственная этому протоколу система элек­тронной подписи, но их нельзя перепутать). Этот протокол позволяет участни­кам обмена информацией договориться об общем секретном ключе через от­крытый канал связи. Задача Диффи-Хеллмана, лежащая в основе протокола, связана с алгебраической задачей дискретного логарифмирования в конечной группе ― на вычислительной сложности этой задачи построена защита прото­кола от перехвата секретного ключа. Сейчас используются два варианта прото­кола ― «классический» и «эллиптический». Математические операции прото­кола в обоих случаях эквивалентны, отличие кроется в используемых группах: «эллиптический» вариант работает на группе точек эллиптической кривой, а «классический» — на группе, в простейшем случае относящейся к более при­вычной из курса высшей алгебры структуре: это мультипликативная группа кольца вычетов, заданного некоторым простым числом (модулем). Мы, впро­чем, оставим алгебраические подробности в стороне. В общих чертах протокол Диффи-Хеллмана может быть изложен без привлечения излишне технических подробностей.

Для того чтобы получить общий секретный ключ, стороны сначала выбирают общие параметры Диффи-Хеллмана ― это модуль, задающий группу (простое число), а также некоторое число, называемое генератором, соответственно, P и G. Оба параметра открыты и могут стать известны третьей стороне. В слу­чае с TLS действующие параметры передаются сервером в открытом виде при установлении соединения. На следующем шаге каждая из сторон выбирает собственное секретное число a (и, соответственно, b) и вычисляет значение A = G^amod P (соответственно, B = G^bmod P). Все операции проводятся по мо­дулю P. Далее стороны обмениваются по открытому каналу значениями A, B и каждая вычисляет A^bmod P и B^amod P. Полученные значения равны, так как, из свойства степеней, A^b = (G^a)^b = B^a = (G^b)^a = G^ab. Таким обра­зом, стороны получили общий секретный ключ G^ab. В случае TLS сервер пе­редаёт в сторону клиента параметры Диффи-Хеллмана и свой открытый ключ (A), который удостоверяет электронной подписью (либо RSA, либо ECDSA). Удостоверение необходимо для того, чтобы активно перехватывающая канал третья сторона не могла подменить ключ на свой.

Прослушивающая канал сторона знает значения P, G, A и B. Но для того, чтобы определить значение секретного ключа, необходимо вычислить a или b, решив относительно x уравнение вида A = G^xmod P. Стоящая за решением этого уравнения задача и называется задачей дискретного логарифмирования в конечной группе. Она вычислительно сложна, если, конечно, P является до­статочно большим. Сейчас для классической версии протокола рекомендуется разрядность модуля не менее 2048 бит, а для версии на эллиптических кривых ― не менее 224 бит. Как упоминалось выше, отличие версии протокола на эл­липтических кривых состоит лишь в арифметической структуре группы точек выбранной эллиптической кривой: на кривой групповая операция определя­ется совсем иначе, чем при построении кольца вычетов.

Выбор шифронабора является ключевым действием для обеспе­чения надёжности защиты канала TLS. Ненадёжная криптосистема делает канал слабо защищённым, даже если все другие параметры выбраны верно. Очевидно, что слабый шифр (например, DES с 40-битным ключом) практически не защищает передаваемые дан­ные от прослушивания. Но в TLS с выбором криптосистем связаны и более тонкие уязвимости. Так, уже упоминавшаяся уязвимость Logjam основана на том факте, что протокол Диффи-Хеллмана (сам по себе считающийся стойким) может использовать слабые параме­тры, а именно — короткий (либо некоторый типовой) модуль, задаю­щий группу, в которой производятся операции протокола. В случае с Logjam оказывается, что третья сторона может восстановить этот ключ из-за того, что выбранные параметры криптосистемы несовер­шенны, а именно ― используется короткий типовой модуль, заранее известный атакующему.

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

SSL-сертификат представляет собой не что иное, как небольшой электронный до­кумент (файл) установленного формата, снабжённый электронной подписью. Вопре­ки расхожему мнению, сертификаты непо­средственно не связаны с шифрованием, но информация из сертификата используется в процессе генерации общего секретного ключа. Предназначение SSL-сертификата — привязка некоторого открытого крипто­графического ключа к некоторому сетево­му имени, не более того. Такая привязка, в свою очередь, обеспечивается с помощью механизма электронной подписи, удо­стоверяющей сертификат: удостоверение подписей реализовано при помощи иерар­хии удостоверяющих центров (УЦ). К этой иерархии есть много претензий, так как компрометация УЦ позволяет нивелиро­вать многие аспекты TLS.

Установление соединения

Всякая сессия TLS начинается с установления соединения. Этот процесс представляет собой обмен специальными сообщениями между узлами. Сообщения следуют в строгой последовательности, а само установление соединения регулируется собственным прото­колом (часть TLS).

Установление соединения (см. Рис1) требует обмена несколькими сообщениями:

• клиент отправляет сообщение Client Hello. Это сообщение, на­пример, содержит список шифронаборов, которые поддерживает клиент. Кроме того, в составе Client Hello передаётся случайная байтовая строка, которая будет использована при выработке об­щего сеансового ключа, а также целый ряд так называемых рас­ширений, содержащих большое число дополнительных параме­тров, важных для устанавливаемой TLS-сессии;
• при успешной обработке Client Hello сервер отвечает определён­ным набором (кортежем) сообщений, первым из которых всегда будет Server Hello. Server Hello прежде всего задаёт выбранный сервером шифронабор. Следом за Server Hello могут быть пере­даны сообщения, содержащие сертификаты (серверные), параме­тры для создания сеансового ключа и другие данные. Замыкает кортеж серверных сообщений сообщение Server Hello Done;
• если клиент принял решение продолжать установление соедине­ния, то он отвечает своим кортежем сообщений. Этот кортеж, в частности, включает сообщение Client Key Exchange, которое слу­жит источником сеансового ключа шифрования;
• важную часть протокола установления соединения составляют специальные сигналы Change Cipher Spec (за которыми следуют сообщения Finished) ― Change Cipher Spec обозначают, что уста­новление параметров шифрования завершено, криптографиче­ский контент согласован, а клиент (и сервер) переходят на защи­щённый обмен сообщениями.

после обмена собщениями Finished начинается TLS-сессия, в рамках которой данные приложений передаются в составе защищённых сообщений Application Data.

На этапе установления соединения узлы проводят аутентифика­цию и генерируют общий секретный ключ, требуемый для симме­тричной криптосистемы. Именно на этом этапе в игру вступает са­мый известный среди пользователей аспект TLS — SSL-сертификаты. Надо отметить, что SSL-сертификаты вовсе не являются необходи­мым элементом TLS-соединения. Протокол определяет SSL-серти­фикаты как опциональный фактор, который, впрочем, требуется для аутентификации сторон. Без сертификатов возможно устано­вить только анонимное соединение (за редкими, весьма экзотиче­скими исключениями). Анонимное соединение уязвимо для атаки типа «человек посередине».

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

SSL-сертификат представляет собой не что иное, как небольшой электронный документ (файл) установленного формата, снабжён­ный электронной подписью. Вопреки расхожему мнению, сертифи­каты непосредственно не связаны с шифрованием, но информация из сертификата используется в процессе генерации общего секрет­ного ключа. Предназначение SSL-сертификата — привязка некото­рого открытого криптографического ключа к некоторому сетевому имени, не более того. Такая привязка, в свою очередь, обеспечива­ется с помощью механизма электронной подписи, удостоверяющей сертификат: удостоверение подписей реализовано при помощи ие­рархии удостоверяющих центров (УЦ). К этой иерархии есть мно­го претензий, так как компрометация УЦ позволяет нивелировать многие аспекты TLS. Однако рассмотрение данной иерархии вывело бы нас далеко за пределы протокола TLS, поэтому оставим его за рамками данной статьи.

Сертификат может иметь разные типы электронной подписи. В современном вебе подавляющее большинство сертификатов — сер­тификаты с подписью RSA. Примерно с 2013 года стала заметна доля ECDSA-сертификатов (они используют криптографию на эллипти­ческих кривых, которая, по ряду практических свойств, превосходит криптосистему RSA). Других типов сертификатов практически не встречается. Серверный сертификат позволяет клиенту проверить, что он соединяется именно с тем узлом, с которым планировал. Для этого клиент проверяет подпись сертификата, сверяя источник этой подписи со списком доверенных ключей, принадлежащих удосто­веряющим центрам. То, что в распоряжении сервера имеется соот­ветствующий секретный ключ, гарантируется механизмом создания общего сеансового ключа сессии, корректное завершение которого невозможно без наличия на сервере секретного ключа сертификата.

Получение сторонами общего сеансового секретного ключа, кото­рый будет использоваться в симметричном шифре, — другой ключе­вой аспект процедуры установления соединения. Для того, чтобы прослушивать TLS-соединение, третьей стороне достаточно полу­чить сеансовый ключ. Знание же секретного серверного ключа из сертификата само по себе не даёт возможности чтения сеанса. Од­нако существуют исторические реализации TLS, в которых сервер­ный ключ позволяет расшифровать сеансовый. Это касается схемы, использующей RSA: в этом случае во время установления соедине­ния клиент (обычно это браузер) генерирует 48-байтовое случайное число, которое служит основой для выработки сеансового ключа, шифрует это число открытым RSA-ключом сервера, полученным в сертификате, и передаёт результат на сервер; если сервер знает соот­ветствующий секретный ключ, то он сможет расшифровать данные клиента. Но то же самое сможет проделать и третья сторона, про­слушивающая канал и знающая секретный серверный ключ RSA, а так как остальные данные, необходимые для получения сеансового ключа, открыты, эта третья сторона сможет вычислить и его. Неу­странимая для данного механизма генерации ключа архитектур­ная уязвимость позволяет раскрывать ранее записанный трафик TLS-сессий, даже если серверный ключ стал известен много позже записи трафика.

Проблема секретности здесь вовсе не является надуманной. Так например, в 2008 году была обнаружена ошибка в процедуре ге­нерации псевдослучайных чисел в ветке Debian популярнейшего набора криптобиблиотек OpenSSL. Ошибка радикально сокращала число возможных вариантов начального состояния генератора и приводила к тому, что количество различных ключей, генерируе­мых библиотекой, измерялось всего лишь десятками тысяч — такое множество элементарно перебирается за минуты. Так как OpenSSL применяют и для генерации серверных ключей RSA, все ключи, соз­данные уязвимой версией, оказались известны, что, потенциально, позволило раскрывать ранее записанный TLS-трафик. Отметим, что использование ECDSA вместо RSA не позволяет вырабатывать сеансовый ключ описанным выше способом, так как криптосисте­ма ECDSA не позволяет зашифровать данные, а лишь сгенерировать значение электронной подписи.

Современные реализации TLS должны использовать при уста­новлении соединения протокол Диффи-Хеллмана (рекомендуется вариант на эллиптической кривой). Сервер лишь удостоверяет элек­тронной подписью (от ключа, соответствующего сертификату) свой открытый ключ Диффи-Хеллмана. Как упоминалось выше, шаг с подписью необходим для того, чтобы предотвратить возможную атаку «человек посередине», которой подвержен протокол Диф­фи-Хеллмана. Сеансовый ключ записанной сессии, таким образом, оказывается недоступен атакующему, который позже получил секретный серверный ключ. То есть можно говорить, что данная криптографическая схема обладает так называемой прогрессивной секретно­стью (Forward Secrecy): компрометация серверного ключа не приводит к рас­крытию ранее записанных сообще­ний. Интересно, что если атакующая сторона обладает серверным клю­чом сертификата и может прово­дить активный перехват трафика, то она сможет перехватить новую сессию, подменив открытый ключ Диффи-Хеллмана на свой.

Но не следует полагать, что исполь­зование протокола Диффи-Хеллмана полностью защищает от последующей расшифровки трафика. Сеансовый ключ некоторое время сохраняется и на сервере, и на клиенте, а утечка ключа возможна с обоих уз­лов. Более того, на серверной стороне сеансовый ключ может передаваться в открытом виде и записываться системами инспекции трафика. Например, распространена практика экспорта сеансового ключа во внешние (относительно веб-сервера) системы противодействия атакам и обнаружения вторжений. Также в TLS существует оптимизация, позволяющая возобновлять ранее со­хранённую сессию по сокращённой схеме (Abbreviated Handshake). Хранение сессии на стороне сервера подразумевает сохранение и се­ансового ключа — время, в течение которого этот ключ сохраняется, может измеряться сутками.

Большинство современных сценариев использования TLS под­разумевают только аутентификацию сервера клиентом. Однако протокол позволяет проводить и «обратную» аутентификацию — клиента сервером. Для этого служат клиентские SSL-сертификаты, которые клиенты передают в ответ на запрос сервера. Так как ис­пользование клиентского сертификата не связано с выработкой се­ансового ключа, для подтверждения обладания соответствующим секретным ключом клиент подписывает блок данных, переданный сервером. Клиентские сертификаты иногда используются для авто­ризации в веб-интерфейсах, например, в платёжных системах или в системах управления контентом сайта.

После того, как клиент и сервер успешно договорились о крипто­системах и выработали общий сеансовый ключ, TLS-соединение можно перевести в защищённый режим, включив шифрование. Переключение происходит при помощи обмена специальными сиг­налами. С этого момента новые сообщения передаются в зашифро­ванном виде. Для транспортировки полезной нагрузки служат со­общения специального типа (Application Data). Каждое сообщение не только шифруется, но и, как описано выше, снабжается кодом аутентификации. Таким образом и клиент, и сервер могут прове­рить, что сообщение не было подвержено изменению. Кроме того, код аутентификации защищает от повтора атакующей стороной пе­реданных ранее сообщений.

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

Современное состояние

TLS используется в сети повсеместно. Это касается и веба. В 2015 году уже мож­но сказать, что если вы веб-мастер, но ваш сайт не поддерживает HTTPS в качестве основного протокола, то вы сильно отстаёте. Сайты массово пере­ходят на защищённый протокол. Мо­жет показаться, что HTTPS требуется только там, где сайт работает с конфи­денциальными данными. Но не нужно забывать о второй, не менее важной, чем шифрование, функции TLS — протокол обеспечивает целостность данных. То есть использование HTTPS позволяет веб-мастеру быть уверенным, что страницы его сайта не будут изменены на пути к пользователю, что в их составе не возникнет «вдруг» дополнительный контент — какой-нибудь замысловатый javascript-код. Это отнюдь не выдуманная угроза: на инъекциях в веб-страницы дополнительного кода, показывающего рекламу, уже попадались весьма крупные провайдеры интернет-до­ступа. Некоторые — попадались не один раз. Поэтому, если веб-ма­стер заботится о сохранении контента на пути до пользователя, то он обязательно внедряет HTTPS, на любом сайте. Не так давно и Google стал ранжировать выше сайты, доступные по HTTPS.

Протокол TLS относится к одному из самых изученных протоко­лов современного Интернета. Тщательно изучаются и его реализа­ции. Казалось бы, многолетний и всесторонний аудит должен был бы давно искоренить большинство ошибок. Тем не менее, ошибки и уязвимости и в реализациях TLS, и в самом протоколе, продолжают находить регулярно. Нет оснований полагать, что в ближайшее вре­мя не будет найдено новых критических уязвимостей. Некоторые ранее найденные дефекты исправляются достаточно медленно. Ре­кордсменом, по всей вероятности, является уязвимость веб-сервера IIS — CVE-2010-3332: об уязвимости стало известно в 2003 году, но корпорация Microsoft исправила дефект в реализации SSL своего веб-сервера лишь семь лет спустя, в 2010.

Фундаментальным недостатком TLS является большая сложность использования этого протокола. Да, в TLS можно выделить техно­логическое ядро, которое окажется относительно простым и, как говорится, обозримым для квалифицированного разработчика, а не только для специалиста в области защиты информации, специально занимающегося TLS. Это ядро включает в себя протокол установле­ния соединения и небольшой набор современных типовых шифров. Проблема в том, что в чистом виде подобное ядро не используется, да и использовать его просто не выйдет: реализации окутаны много­численными дополнениями и уточнениями, многие из них возник­ли как оптимизации, придуманные разработчиками того или иного массового сервиса. Например, инженеры и учёные Google предло­жили целый ряд модификаций для TLS, в том числе, модификаций, затрагивающих самые основы протокола (к таким относится TLS False Start и другие, частично перекочевавшие в черновики TLS 1.3). То есть изменения в TLS диктует практика использования протоко­ла, но это не приводит к его упрощению, из-за того, что протокол из версии в версию тянет за собой огромное историческое наследие.

Сейчас в стадии разработки в IETF находится версия TLS 1.3. С самого начала работы над ней было предложено удалить многие и многие невостребованные особенности и дополнения, чтобы упро­стить протокол и, опять же, сделать его обозримым. Например, обсуждается запрет на сжатие данных: все предыдущие версии предусматривают возможность сжатия данных перед шифровани­ем, с использованием некоторого алгоритма (это наверняка будет DEFLATE, являющийся небезопасным); сжатие используется край­не редко и несёт с собой дополнительные уязвимости. Однако едва ли не каждая попытка удаления подобного «исторического насле­дия» приводит к возражениям: современный Интернет настолько разнообразен, что в нём не только не трудно найти TLS-серверы, поддерживающие SSLv2, но и всякая экзотическая технология не­ожиданно оказывается востребованной тем или иным малоизвест­ным сервисом. А пренебречь интересами даже небольшой группы пользователей — крайне нелегко.

Тем не менее, рабочей группе есть чем похвалиться: список вы­кидываемого «старья» не так уж и короток. Спецификация TLS 1.3 пока находится в статусе черновика, но многие полезные изменения уже зафиксированы. Так, исчезнет поддержка алгоритма электрон­ной подписи DSA — в Интернете такие сертификаты сейчас не встре­чаются, сам алгоритм считается историческим и неперспективным. Более того, упоминавшаяся выше схема обмена сессионным клю­чом с использованием шифрования RSA также удалена из прото­кола установления соединения, как не обладающая прогрессивной секретностью.

Достаточно серьёзно урезано число потенциальных каналов утеч­ки метаинформации, характерных для TLS. Например, поле, обо­значающее тип записи (Content Type) и ранее передававшееся в открытом виде, будет зашифровано: информация о типе записей является одним из каналов утечки метаинформации, так как позво­ляет стороне, ведущей пассивное наблюдение за каналом, видеть некоторые события — например, поступление сообщения об ошибке протокола. Метаинформация вообще является богатым источником сведений о ходе защищённого обмена данными и даже позволяет строить идентификационные профили и узнавать конкретные сер­висы, которые посещает пользователь.

Исключается поддержка хеш-функции SHA-1 в составе криптоси­стемы электронной подписи: данная хеш-функция считается уста­ревшей и недостаточно стойкой (к нахождению коллизий). Также, наконец-то, из протокола удаляется поддержка хеш-функции MD5, а для полноты картины — и SHA-224.

Изъята целая пачка разнообразных алгоритмов «пересмотра» па­раметров соединения, которые ранее могли быть применены как на этапе установления соединения, так и в ходе сеанса. Считается, что наличие подобных «обходных тропинок» ведёт не к оптимизации использования вычислительных ресурсов, а к возникновению но­вых источников уязвимостей. Тем более, что многие из этих прото­колов реально не использовались.

Большая чистка идёт. TLS 1.3 будет существенно отличаться от предыдущих версий TLS. Есть шанс, что технология обретёт поло­женную ей строгость и стойкость. К сожалению, можно с ничуть не меньшей уверенностью сказать, что новой версии также будут со­путствовать новые уязвимости. Остаётся надеяться, что среди них архитектурные дефекты протокола окажутся в меньшинстве.

С подробным техническим описанием TLS, интересным для специ­алистов, можно ознакомиться в отдельной статье автора.