Wireshark дешифрока HTTPS

Все больше в современных сетях используется шифрование с помощью TLS. Благодаря чему в ПО захвата пакетов, таком как Wireshark, невозможно увидеть внутренности пакета. В этом посте рассказывается про асимметричное шифрование, TLS в версии 1.3 и как можно расшифровать его пакеты в Wireshark.

Содержание:

Введение в шифрование с открытым ключом
Реализация шифрования в TLS
Отличие TLS версии 1.3
Дешифровка TLS с помощью Wireshark

Введение.

Шифрование с открытым ключом уже затрагивалось в этом блоге в этом блоге. Для начала вспомним, что механизм шифрования с открытым ключом очень большая и запутанная тема в нюансах которой разбираются только профессионалы. Для работы с ним на практичном уровне, доступном системному администратору, достаточно знать следующее.

Существуют два ключа (псевдослучайная последовательность данных). Для простоты они называются открытый и закрытый ключи. Они связаны между собой таким образом, что шифрование с помощью одного ключа, можно расшифровать с помощью другого.

Практически это выглядит так.

Клиент запрашивает данные у сервера.
Сервер шифрует данные с помощью своего закрытого ключа и передает клиенту.
Клиент берет открытый ключ сервера и расшифровывает данные.
Клиент шифрует данные с помощью открытого ключа сервера и передает их серверу.
Сервер расшифровывает данные с помощью своего закрытого ключа.

Для этой работы клиенту нужно знать открытый ключ сервера. Он его берет из сертификата сервера.

Ключ сессии

Данный алгоритм упрощен и содержит некоторые допущения. Например, на деле шифрование с открытым ключом (его еще называют асимметричным) используется для шифровки небольших данных, например, симметричного ключа (session key, сеансовый ключ). С помощью сеансового ключа происходит дальнейшие шифровка/дешифровка данных.

Сертификат

Сертификат подтверждает, что открытый ключ принадлежит владельцу сертификата. Сертификат выдается удостоверяющим центром (CA). У удостоверяющего центра есть свой сертификат. Клиент импортирует сертификат CA и поэтому доверяет всем сертификатам, выданным этим удостоверяющим центром.

PFS

В некоторых реализациях асимметричного шифрования существует особенность. Получив доступ к закрытому ключу можно расшифровать перехваченные до этого данные. Пара открытый-закрытый ключ меняется достаточно редко (годы) и поэтому объем информации подверженной расшифровки может быть большой. Для ее решения применяется механизм совершенной секретности (Perfect forward secrecy, PFS). В этом случае сеансовый ключ невозможно скомпрометировать, даже если закрытый ключ был скомпрометирован.

TLS.

Примером реализации криптографических протоколов является Transport Layer Security (TLS). TLS призван решить две цели: конфиденциальность и проверка подлинности.

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

Секретность достигается за счет использования симметричного шифрования. Обе стороны шифруют сообщение перед тем как его отправить.

Проверка подлинности достигается за счет использования открытых ключей.

Веб сервер предоставляет сертификат и публичный ключ для веб браузера.
Браузер доверяет сертификату сервера, если выполнены два условия:
- доказательство, что сервер владелец сертификата,
- доказательство, что сертификату можно доверять.
Сертификат содержит открытый ключ и если веб сервер может доказать, что владеет закрытым ключом, то это подтвердит, что он владелец сертификата.
Сертификату можно доверять, если веб браузер доверяет центру сертификации (CA), выпустившему сертификат, и если он содержит доменное имя сайта.

Для подключения по зашифрованному каналу можно использовать как стандартный порт (TCP 443 для HTPPS), так и произвольный порт. Во втором случае клиент может изначально подключаться по нешифрованному каналу, затем передавать команду на включение TLS (например, STARTTLS для электронной почты).

Handshake

В TLS конфиденциальность и проверка подлинности осуществляется через серию обмена сообщениями, названную рукопожатием (handshake):

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

Таким образом рукопожатие может быть двух видов:

При использовании RSA сеансовый ключ создается клиентом.
- Он шифруется открытым ключом сервера.
- Отправляется серверу.
- Сервер использует свой закрытый ключ, чтобы расшифровать сеансовый ключ. Поэтому при компрометации закрытого ключа сервера возможно расшифровать предыдущую переписку.
При использовании DH используется эфемерные ключи для каждого подключения.
- Он не привязан к закрытому ключу сервера и поэтому обеспечивает совершенную секретность (PFS).
- Поэтому даже при компрометации закрытого ключа сервера невозможно расшифровать предыдущую переписку.

Шифры

Набор шифров состоит из алгоритмов, каждый из которых выполняет свою функцию:

Создание сеансового ключа - RSA или DH
Проверка подлинности (тип сертификата) - RSA или DSA
Секретность (симметричное шифрование) - AES, 3DES...
Целостность (хэш функция) - MD5, SHA1...

Рассмотрим пример набор шифров: ECDHE-RSA-RC4128-SHA

ECDHE - сеансовый ключ получается с помощью Диффи-Хеллмана на эфемерных эллиптических кривых
RSA - проверка подлинности публичного ключа с помощью RSA. Важно отличать, что RSA в этом случае служит только для проверки веб-сервера, а не для защиты соединения
RC4128 - шифрование будет использоваться RC4 с длинной ключа 128 бит. Сеансовый ключ получается через обмен Диффи-Хеллмана и проверку RSA выше
SHA - хэш функция

Таким образом RSA может использоваться для установки сеансового ключа и проверки подлинности.

При использовании RSA для установления ключа небезопасно, как говорилось выше.
При использовании DH для установки ключа, проверка подлинности остается за RSA или другим протоколом, например, DSA.

Еще один пример: ECDHE-ECDSA-AES256-GCM-SHA384

ECDHE - создание сеансового ключа с помощь Диффи-Хеллмана на эллиптических кривых и на эфемерных открытых ключах
ECDSA - проверка подлинности с помощью DSA на эллиптических кривых
AES256 - секретность с помощью AES CM с длинной ключа 256 бит
SHA384 - целостность с помощью SHA с длинной 384 бит

Возобновление сессии

Еще одна из особенность TLS - возобновление сессии (session resumption). Если клиент подключается к серверу, с котором была связь до этого, то он может использовать сокращенную установку связи (abbreviated handshake). Для этого можно использовать два механизма: идентификатор сессии (session ID) и удостоверение сессии (session ticket).

При идентификаторе сессии сервер хранит состояние сессии (сеансовый ключ)
При удостоверении сессии клиент хранит состояние сессии сервера (сеансовый ключ, зашифрованный сеансовым удостоверяющим ключом (session ticket key))

Поскольку при возобновлении сессии используется предыдущий ключ (сеансовый удостоверяющий ключ), то оно не обеспечивает совершенную секретность (PFS).

TLS 1.3.

TLS версии 1.3 находиться сейчас в черновой версии. В этой версии TLS собираются сделать значительные изменения.

Сократить количество шагов для установления сессии (рукопожатия).
Убрать поддержку создания сеансового ключа с использованием RSA.
Изменить механизм возобновления сессии.
При первом подключении клиент и сервер договариваются о ключе возобновления сессии (pre-shared key, PSK).
Сервер отдает клиенту удостоверение сессии.
При возобновлении сессии используется DH, что обеспечивает PFS.
Добавить режим возобновления сессии с немедленным стартом (0-RTT в противовес 1-RTT у TLS1.2). Т.е. возобновление сессии TLS 1.3 начинается сразу с запроса HTTP без предварительного согласования TLS. При повторном подключении клиент отправляет удостоверение сессии и не ожидаясь ответа отправляет HTTP запрос, зашифрованный ключом возобновления сессии. Поскольку в этом случае используется предыдущий ключ, то возобновление сессии не обеспечивает совершенную секретность (PFS).

Дешифровка TLS с помощью Wireshark.

Для расшифровки TLS трафика в современных браузерах появилась возможность сохранять сеансовые ключи. Для этого используется переменная окружения SSLKEYLOGFILE. Проще всего в настройку окружений попасть выполнив команду systempropertiesadvanced и нажав Environment Variables. Назначить в ней путь до файла, браузер будет сохранять в него сеансовые ключи.

SSLKEYLOGFILE = C:\Users\username\sslkeylog.log

После этого настраиваем Wireshark на чтение этого файла. Заходим в

Edit -> Preferences -> Protocols -> SSL -> Pre-Master-Secret log filename

И указываем путь до этого файла.

После этого зашифрованный трафик будет виден.