Зашифровано ли приветственное сообщение сервера в протоколе рукопожатия TLS?
читая о протоколе рукопожатия TLS, я понял, что первым ответным сообщением от сервера к клиенту является серверное приветствие, включающее в себя идентификатор сеанса, а последнее будет служить для идентификации пользователя для следующих подключений. Я читал, что информация об идентификаторе сеанса должна быть секретной, чтобы избежать опасности захвата сеанса, так зашифровано ли приветственное сообщение сервера? если да, то как узнать, что симметричный ключ, который будет использоваться для шифрования, еще не подготовлен?
Я просмотрел форумы и просмотрел учебные пособия, чтобы четко понять протокол рукопожатия TLS, но не нашел ответа на свой вопрос.
@Zergatul, я вообще прошу версии 1.2 или 1.3. Я подробно читал о версиях протокола 1.2, а также просмотрел множество тем и видео, в которых говорится, что идентификатор сеанса должен оставаться в секрете. Я понял, что сообщение сервера, содержащее идентификатор сеанса, не зашифровано.
Вы не читали подробно, потому что TLS 1.2 RFC говорит много информации об идентификаторах сеансов.
RFC говорит, что идентификатор сеанса, случайные числа, сгенерированные клиентом или серверами, передаются без шифрования. Я хочу сказать, что в других учебниках или курсах указано, что идентификатор сеанса должен оставаться в секрете, чтобы избежать опасности перехвата сеанса.
RFC является основным источником информации о протоколах.
Некоторые параметры сеанса, в первую очередь главный секрет, должны храниться в секрете в версии 1.2 и ниже; идентификатор сеанса не является. Возобновление в 1.3 сильно отличается от более ранних версий; нет «общего» ответа, который охватывает как 1.2, так и ниже, и 1.3. (В 1.3 поля идентификатора сеанса являются фиктивными значениями, которые вообще не связаны с возобновлением, в то время как «тикет» может быть либо реальным билетом, либо просто идентификатором, а сообщение билета (супер) зашифровано в любом случае.)
Ответы 1
Из RFC 5246:
Когда клиент и сервер решают возобновить предыдущий сеанс или дублировать существующий сеанс (вместо согласования нового параметры), поток сообщений выглядит следующим образом:
Клиент отправляет ClientHello, используя идентификатор сеанса для сеанса. быть возобновлен. Затем сервер проверяет свой кэш сеанса на соответствие. Если совпадение найдено и сервер желает восстановить соединение в указанном состоянии сеанса, он отправит ServerHello с тем же значением идентификатора сеанса.
ClientHello и ServerHello не шифруются в TLS 1.2.
Предупреждение: Поскольку SessionID передается без шифрования или немедленная защита MAC, серверы НЕ ДОЛЖНЫ размещать конфиденциальные информация в идентификаторах сессий или пусть содержимое поддельное идентификаторы сеанса вызывают любое нарушение безопасности. (Обратите внимание, что содержание рукопожатия в целом, включая SessionID, защищены сообщениями Finished, которыми обмениваются в конце рукопожатие.)
SessionID сам по себе представляет собой просто случайные байты. Клиент и сервер где-то хранят согласованные ключи для каждого идентификатора сеанса. Вы не можете сделать что-то конкретное со стороны злоумышленника, если знаете идентификатор сеанса.
спасибо, в других учебниках, которые я проверял, говорилось, что доступ злоумышленника к идентификатору сеанса опасен, поэтому я подумал, что неправильно понял протокол, и это должно быть своего рода шифрование для приветствия клиента и сервера, которые также содержат используемые случайные числа для создания мастер и сеансовых ключей
Напротив, если вы (реализуете и) используете опцию билета rfc4507/5077 в версии 1.2 и ниже, она содержит (по крайней мере) главный секрет и зашифрована, а идентификатор сеанса НЕ используется.
Вам лучше прочитать TLS 1.2 RFC rfc-editor.org/rfc/rfc5246 Вы спрашиваете именно версию 1.2? Потому что в 1.3 много изменений, связанных с протоколом рукопожатия.