Привет, дорогой читатель!
Зарегистрируйтесь и получите доступ к бесплатному контенту. А также будьте в курсе нового учебного контента. Ссылка на учебную платформу:
Если материал полезен, то есть способ отблагодарить меня. Любая сумма будет отличной наградой и стимулом писать полезный контент для Вас.
Ну вот мы и подобрались к самому важному, в контексте обеспечения сетевой безопасности, протоколу TLS (Transport Layer Security). Да, да – без TLS не было бы безопасной онлайн торговли, онлайн банкинга и вообще ничего безопасного в сети. Иногда, говоря про TLS, люди употребляют аббревиатуру SSL (Secure Socket Layer) – это неправильно, но так повелось и в этом нет ничего критичного. Просто держите в голове, что SSL - устаревший протокол, предшественник TLS. SSL уже давно никто не использует по причине его небезопасности.
О чем будет данная статья?
Цель данной статьи не только выжимка самого главного из различных источников (профессиональных форумов и книг) и результат осмысления данной информации, но и попытка увидеть процесс работы протокола в бою. Я буду использовать Wireshark, чтобы показать процесс работы TLS. Вишенкой на торте будет демонстрация взлома TLS имея полный доступ к инициатору соединения. Мы кратко пробежимся по таким понятиям как сертификаты и удостоверяющие центры, разберем структуру протокола, перечислим криптографические алгоритмы, лежащие в основе TLS 1.3 и улучшения актуальной версии по отношению к предшественникам, узнаем, что такое секретность прошлого и какие проблемы (уязвимости) имеют место быть в виду ограничений реального мира от которых не деться никуда.
Для успешного освоения данного материала советую почитать ряд моих кратких статей – подводок к данной теме:
1. Хеширование информации;
2. Ассиметричная криптография;
3. Электронная цифровая подпись;
4. Одноразовые числа (Nonce числа. Аутентификация без шифрования);
5. Имитовставки (коды аутентификации сообщений).
Ну что, в путь?
Краткая историческая справка:
История TLS начинается в 1995 году, когда компания Netscape создала предшественника TLS, протокол SSL. SSL был далек от совершенства, и в обеих версиях SSL 2.0 и SSL 3.0 были дефекты, относящиеся к безопасности. SSL нельзя использовать ни в коем случае! Важно так же помнить, что не все версии TLS безопасны. Всего на текущий момент существует три версии TLS:
TLS 1.0 (1999) – наименее безопасная версия, но безопаснее чем SSL 3.0;
TLS 1.1 (2006) – безопаснее чем версия 1.0, но включает, по текущим меркам, ряд нестойких алгоритмов;
TLS 1.2 (2008) – версия, обеспечивающая высокую безопасность. Однако версия 1.2 унаследовала множество функций и проектных решений от прежних версий, поэтому не оптимальна с точки зрения безопасности и производительности. Из-за повышенной сложности степень безопасности зависит от правильности конфигурации данного протокола и выбора режимов работы. К примеру, протокол данной версии поддерживает AES в режиме CBC, который уязвим к атакам на оракула дополнения;
TLS 1.3 (2018) – данная версия протокола есть результат полной переработки предыдущих версий. Чтобы расчистить завалы, инженеры-криптографы почти заново изобрели TLS оставив только лучшее от предшественников и добавив самые актуальные средства безопасности.
По факту TLS 1.3 – это зрелый TLS.
О TLS с высоты птичьего полета
TLS – протокол обеспечения безопасного обмена информацией между двумя точками. Обычно этими точками являются клиенты (браузеры, приложения на мобильных устройствах) пользователей с одной стороны и web сервера (сервисы) с другой стороны. Если подзабыли что такое клиент-серверное взаимодействие, то совсем недавно я разбирал эту тему – вот ссылка на статью «Модель OSI. Уровни приложений и транспортный уровень. Клиент-серверное взаимодействие».
Если обратиться к модели OSI, а точнее к победившей данную модель практическим применением модели TCP/IP, то на каком же уровне работает TLS? Зачастую название протокола часто сбивает с толку и многие считают, что ответ – на транспортном. Но это не так – правильный ответ: между прикладным и транспортным (TСP).
Заметили я в скобках указал TCP? Все верно: TLS полагается на TCP. Если говорить про UDP, то и для него есть протокол обеспечения безопасной передачи – DTLS, очень похож по своей структуре на TLS, но в данной статье мы его не разбираем. Просто запомните это различие.
TLS берет данные от прикладного уровня, обрабатывает их в соответствии с внутренней логикой реализации и передает дальше TCP. Протоколу безопасной передачи без разницы какие данные передавать. В этом плане он очень похож на TCP и подходит для любых приложений. Но что удивляться, основным требованием при разработки современных протоколов являются такие их качества как: универсальность, расширяемость и переносимость.
Итак, TLS состоит из двух протоколов: протокола записи и протокола подтверждения связи (квитирования).
Протокол записи:
Чтобы было легче запомнить вспомните как называются единицы передаваемой информации на каждом из уровней моделей OSI/TCP/IP:
Канальный уровень – кадр (фрейм);
Сетевой уровень – пакет;
Транспортный уровень – TCP (сегмент), UDP (дейтаграмма);
TLS – запись.
Уловили логику? Протокол записи это как раз про то, как инкапсулируются данные - формат пакета для инкапсуляции данных протоколов верхних уровней. Говоря про TLS используйте сущность «запись».
Протокол записи – довольно простой протокол и нередко забывают, что он является частью реализации TLS.
Протокол подтверждения связи (TLS handshake) – протокол выработки ключа TLS. Процедура инициируется клиентом, желающим установить безопасное соединение. Клиент посылает начальное сообщение ClientHello, содержащее параметры, в т.ч. шифр, который хочет использовать клиент. Давайте расчехлять Wireshark, чтобы нам стал нагляднее данный процесс. Но предварительно я «положу перед вашими глазами» вот эту картинку, описывающую процесс работы протокола в комплексе, чтобы привязаться к местности, так сказать:
Сервер получает сообщение ClientHello, проверяет его и отправляет клиенту ServerHello:
Помимо Server Hello, сервер передает заголовки: Certificate, Server Key Exchange, Server Hello Done.
Заголовки могут передаваться в разных TCP сегментах так как размер сегмента может быть ограничен. Если MSS (Maximum segment size) позволяет, то сервер может уместить все в один сегмент. Но помнить важно следующее: обращайте внимание на заголовок Server Hello Done. Именно он сигнализирует о том, что сервер передал клиенту все что хотел.
Давайте пройдемся по содержимому данных заголовков.
Certificate
Самый важный шаг процедуры квитирования (подтверждения связи) – проверка сертификата.
Сервер предъявляет клиенту сертификат, подтверждая тем свою подлинность. Еще говорят по-другому: предъявляя сертификат сервер аутентифицирует себя клиенту. Но не суть… Сертификат – это, по факту, открытый ключ, дополненный подписью данного ключа, и дополнительная информация (в т.ч. доменное имя и цепочка сертификации). На браузер или клиентское приложение возлагается задача проверки подлинности сертификата и легитимность его предъявления. Подлинность сертификата проверяется по средством подтверждения/не подтверждения данного факта цепочкой удостоверяющих центров, вплоть до корневого центра (CA). Проверив подлинность проверяется подпись сертификата. На этом этапе клиент сравнивает получившийся хеш с подписью. Если равенство выполняется, то это подтверждает факт обладания сервера секретным ключом. Доменное же имя дает возможность дополнительной проверки на предмет подмены адреса сервера. Браузер производит резолв указанного доменного имя и сравнивает полученный адрес с адресом, участвующим в текущем сеансе установления TLS соединения. Если адреса соответствуют друг другу, то можно довериться серверу и продолжить взаимодействие.
Внимание! Может показаться, что все эти комплексные проверки дают 100% безопасности. Но это не так. Дальше я расскажу при каких условиях возможно полное вскрытие клиент – серверного взаимодействия. Даже покажу это на практике. Могу сказать только, что для этого требуется полный контроль над сервером или рабочим местом пользователя (мобильным устройством). Это абсолютно реальная ситуация так как в большинстве случаев рабочими местами пользователей управляют администраторы и они могут не хитрыми манипуляциями подвергнуть все ваши TLS сессии атаке на секретность прошлого. Но об этом позже.
В Wireshark есть полезная возможность экспорта сертификата. Давайте экспортируем из дампа сертификат сайта 2ip.ru и посмотрим его основные моменты:
Сохраняем файл в формате *.crt и открываем его:
Путь сертификации для сайта 2ip.ru выстроен в указанной на скрине последовательности:
Сертификат для сайта 2ip.ru выдан и подписан организацией R3. ISRG Root X1 является корневым центром сертификации и делегирует R3 доверие к сайту 2ip.ru. В каждом из сертификатов в цепочке есть дополнительная информация о том на какой сетевой адрес обращаться с целью проверки отсутствия проверяемого сертификата в списке отзыва сертификатов CRL и на вышестоящий центр сертификации:
Server Key Exchange и Client Key Exchange
Конечная цель TLS заключается в том, чтобы клиент и сервер могли выработать master keys для симметричного шифрования передаваемого трафика. Если обратиться к нашей схеме, то речь об этом:
На стороне клиента:
keys = DH(c,S), где c - закрытый ключ клиента, S - ephemeral (сеансовый) публичный ключ сервера.
На стороне сервера:
keys = DH(s,C), где c - закрытый ключ c сервера, С - ephemeral (сеансовый) публичный ключ клиента.
Из схемы видно, что клиенту и серверу для вычислений необходимы сеансовые публичные ключи друг друга. Именно они и передаются в рамках сообщений Server Key Exchange и Client Key Exchange.
Криптографические алгоритмы TLS 1.3
В начале статьи я описывал, что TLS 1.2 может использовать шифрование с аутентификацией CBC_SHA если клиент не поддерживает режим GCM. Так вот напомню, что режим CBC_SHA не безопасен и подвержен атаке на оракула дополнения. По этой причине TLS 1.3 поддерживает только три шифра: AES-GCM, AES-CCM, CBC_256(384) и потоковый шифр ChaCha20 в сочетании с имитовставкой Poly1305 (RFC 7539). TLS 1.3, в отличии от предшественников, разрешает использование в функции KDF (см. схему «Процесс подтверждения связи в TLS 1.3 при подключении к HTTPS-сайту») только хеш-функции SHA-256 и SHA-384.
Операции Диффи-Хеллмана ограничены эллиптической криптографией и мультипликативной группой целых чисел по простому модулю. Но есть ограничения:
1. Нельзя использовать любую кривую. Поддерживаются три кривые: NIST, Curve25519, Curve448;
2. Поддерживаются не любые группы целых чисел, а с модулями длиной 2048, 3072, 4096, 6144 и 8192.
2048-битовая группа является самым слабым звеном TLS 1.3. Она обеспечивает уровень безопасности меньше 100 бит. Остальные варианты дают по меньшей мере 128-битовую безопасность.
Основные улучшения TLS 1.3 по сравнению с TLS 1.2
Давайте сравним шифры, предлагаемые клиентом в рамках установления TLS сессии версии 1.2 и 1.3:
В версии TLS 1.3 вы уже не увидите режим CBC + хеш-функцию SHA каковые присутствуют в 1.2. Если сравнивать версию 1.3 и все предыдущие, то актуальный протокол вычищен от таких слабых алгоритмов как MD5, SHA-1, RC4 и АES в режиме СВС_SHA.
Как уже упоминалось, одна из главных целей разработки TLS 1.3 было исключение из версии 1.2 функциональности, ослабляющей протокол, и уменьшение сложности, а значит, и поверхности атаки.
Поверхность атаки — термин, применяемый при решении задач информационной безопасности компьютерных систем, и обозначающий общее количество возможных уязвимых мест. Чем больше компонентов установлено на сервере, тем больше число потенциально уязвимых мест и, соответственно, поверхность атаки.
Одним из таких упрощений стало исключение факультативности сжатия данных, из-за которого стала возможной атака CRIME на TLS 1.2 и предыдущие версии, в том числе SSL протокола. В атаке использовался тот факт, что длина сжатого сообщения раскрывает информацию о содержимом. Вот ссылка на короткое и простое описание данной атаки: «Эксплойт CRIME: расшифровка каждого байта TLS за 4-6 запросов»
Мы рассмотрели основной функционал, которому не нашлось места в версии TLS 1.3.
Теперь затронем основные новшества: защита от понижения версии, квитирование с одни периодом кругового обращения, возобновление сеанса.
Защита от понижения версии
В TLS 1.3 внедрена защита от понижения версии. Как это работает? За счет трех видов паттернов!
1-й Паттерн.
Если клиент запрашивает TLS 1.2 в своем ClientHello, то сервер c TLS 1.3 ДОЛЖЕН установить последние 8 байт 32 байтного случайного числа (random value) в своем ServerHello в значение 44 4F 57 4E 47 52 44 01
2-й Паттерн.
Если клиент запрашивает TLS 1.1 или ниже в своем ClientHello, то сервер c TLS 1.3 ДОЛЖЕН, а TLS 1.2 серверу СЛЕДУЕТ установить последние 8 байт 32 байтного случайного числа (random value) в своих ServerHello в значение 44 4F 57 4E 47 52 44 00
3-й Паттерн.
Если клиент запрашивает TLS 1.3, то получая от сервера ServerHello он ДОЛЖЕН проверить, что последние 8 байт random value не равны ни 44 4F 57 4E 47 52 44 01 ни 44 4F 57 4E 47 52 44 00, т.е. последние 8 байт по факту должны быть случайными.
Естественно, эти значения передаются в зашифрованном виде с использованием эфемерных ключей. Выше я описывал, что в процессе Server Key Exchange и Client Key Exchange на стороне клиента и сервера, среди прочего, генерируются C и S ephemeral (сеансовые) публичные ключи клиента и сервера соответственно. Клиент и сервер обмениваются случайными числами шифруя их сеансовыми публичными ключами.
Такой способ дает возможность клиенту и серверу вскрыть попытку MITM атаки. Клиент обнаруживший такую атаку ДОЛЖЕН прервать TLS-handshake и отправляет уведомление "illegal_parameter"
Еще один важный момент! Если согласована TLS 1.3 сессия, то в рамках текущего сеанса запрещено пересогласование версии TLS.
Квитирование с одни периодом кругового обращения (RTT-0 Data)
В TLS 1.2 и более ранних реализациях пока клиент и сервер не обменяются всеми необходимыми данными для организации защищенного канала данные приложения не будет передаваться. В общем виде процесс TLS рукопожатия выглядит так: клиент посылает данные серверу, ждет ответа, затем еще отправляет данные, снова ждет ответа и только потом начинает отправлять зашифрованные сообщения. В этом случае задержка составляет два периода кругового обращения (round-trip time - RTT). При разработке TLS 1.3 учли эту неэффективность и еще до того как клиент и сервер выполнили все этапы согласования клиент и сервер могут передавать данные приложения в рамках блоков early_data. В RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3, Page 18) обращается внимание на то, что эти порции данных шифруются с помощью сессионных ключей, но не с помощью master key. Этот момент требуется учитывать при проектировании ПО, чтобы эти порции данных не содержали сверхчувствительную информацию. В итоге TLS 1.3 экономит приложениям сотни миллисекунд.
Возобновление сеанса
TLS 1.3 быстрее чем 1.2, но его можно сделать еще быстрее (на несколько сотен миллисекунд). Суть трюка в том, что при возобновлении сеанса используется уже выработанный для предыдущего сеанса мастер ключ. При этом на нулевом периоде кругового обращения (RTT-0) клиент в рамках ClientHello передает новый открытый ключ DH и передает порцию данных зашифрованных мастер ключом из предыдущего сеанса. Сервер же в свою очередь подтверждает аутентификацию не сертификатом, а включает имитовставка в данные отправленные клиентом. В процессе начального этапа возобновления сеанса параллельно с передаваемыми данными вырабатывается новый мастер ключ. И как только все готово обмен данными переводится на шифрование новыми ключами.
Стойкость TLS
Стойкость любой системы защиты необходимо рассматривать относительно заранее определенных аспектов. В частности стойкость TLS рассматривается относительно двух главных аспектов: аутентификация и секретность прошлого.
Аутентификация
В процессе квитирования TLS 1.3 сервер аутентифицирует себя клиенту с помощью сертификата (это мы проходили). По умолчанию клиент себя не аутентифицирует. Если на сервере требуется аутентификация клиента, то обычно это делается с помощью логина и пароля (в настоящее время еще желательна двухфакторная аутентификация). Данные логина и пароля должны передаваться в TLS записи следующей за этапом квитирования (установления безопасного канала). В некоторых случаях клиенты могут аутентифицироваться с помощью тех же сертификатов. В этом случае TLS 1.3 сервер настраивается таким образом, чтобы требовать предоставление сертификата от клиента. Этот вариант встречается не так часто в силу своей сложности и применятся для повышения доверия с клиентам подключающимся к серверу. Обычно речь идет об аттестованных системах где уровень безопасности должен быть на порядок выше чем в публичных сервисах.
Секретность прошлого
Протокол совместной выработки ключа обеспечивает секретность прошлого. Что имеется ввиду? Если скомпрометирован текущий сеанс, то предыдущие сеансы остаются не скомпрометированы. В модели утечки данных компрометируются временные секреты, в модели вскрытия - долговременные.
Модель утечки
Если злоумышленник добыл временные секреты: c, s, secret и keys, то максимальный ущерб для протокола - дешифрование данных в текущем сеансе.
Модель вскрытия
Если злоумышленник добыл еще и закрытый ключ, соответствующий открытому ключу в сертификате, то опять же максимальный ущерб - дешифрование данных в текущем сеансе, так как закрытый ключ применяется только для аутентификации сервера.
Но что может произойти на практике?
Предположим, что злоумышленник скомпрометировал машину клиента и получил доступ к переменной среды или текущей памяти. В этом случае можно создать коллектор сеансовых ключей и секретов для TLS сеансов (далее я на практике покажу как это сделать) и восстановить текущие секреты из памяти.
В первом случае мы можем вскрывать не только текущие сеансы, но и сеансы из прошлого. В этом случае можно обойти теоретическую безопасность прошлого. Поэтому, чтобы реализация TLS действительно гарантировала безопасность прошлого, необходимо стирать ключи в памяти после окончания использования. Давайте я продемонстрирую вариант вскрытия секретности прошлого в Windows и Linux при условии наличия административных привилегий в системах.
Дешифруем TLS траффик в Windows
В исходном состоянии в ОС Windows временные TLS секреты хранятся в текущей памяти (оперативная память). После закрытия браузера память в которой хранились ключики очищается. Если мы запустим Wireshark и соберем дамп трафика TLS сессии, то мы не сможем заглянуть в HTTP обмен. Все, что мы увидим это подсказку Wireshark:
Если к примеру взять 248 фрейм с Application Data, то "провалившись" в содержимое мы можем максимум увидеть вот такое:
Но все может измениться если мы произведем следующие настройки:
Мой компьютер --> Дополнительные параметры системы
После создания новой переменной среды желательно полностью ребутнуть комп. Иногда бывает достаточно закрыть все браузеры и открыть заново.
Если в процессе использования браузера (открытие новых сайтов) размер файла растет, а содержимое похоже вот на вот это, то все сделано как надо:
Все эти манипуляции позволяют для всех TLS сессий сохранять секреты. Подгрузим этот лог файл в Wireshark:
После всех вот этих манипуляций картина в окне Wireshark слегка изменится и появятся упоминания о протоколе HTTP:
Теперь мы можем "провалиться" в содержание расшифрованного HTTP трафика:
В linux системах принцип тот же. Оставлю это вам в качестве домашней работы :)
На этом думаю пора заканчивать. Статья и так получилась большой.
Времени на подготовку данного материала ушло не мало, поэтому если вам было полезно не скупитесь на лайки и комментарии! Все это придает смысл моему альтруизму :)
До скорого!