Трассировка TCP-потока
TLS/SSL устанавливается между прикладным уровнем и транспортным уровнем TCP и шифрует данные до того, как они достигнут TCP.Раньше было проделано так много работы, например согласование ключа рукопожатия, защита от отказа от цифровой подписи и т. д., все для обеспечения данные, целостность и конфиденциальность. HTTP в сочетании с протоколом TLS/SSL — это HTTPS.Если HTTP-сообщения не передаются протоколу TLS/SSL, после перехвата трафика самой большой проблемой является утечка конфиденциальности. Если мы регистрируем нашу информацию на веб-сайте, который не использует HTTPS, и отправляем ее в виде HTTP-трафика, как только запрос будет перехвачен из-за передачи открытого текста, содержимое внутри будет просочено. Маршрутизация позволяет этим пакетам проходить через множество узловых устройств.Пакеты, ожидающие пересылки пакетов на этих маршрутах узла, могут быть перехвачены, а затем подделаны.Хотя протокол TCP может гарантировать, что данные поступают правильно обеим сторонам, он не может гарантировать правильность данных. Подделанный, для серверов, не использующих TLS/SSL, если полученный HTTP-запрос имеет правильный формат, он будет отвечать. Вроде следующая ситуация:
Если мы передаем данные на HTTP-странице, например, на странице входа, вводим свой логин и пароль и отправляем на сервер, трафик будет перехвачен посередине, а отправляемые нами данные будут напрямую сливаться, просто как на картинке выше. И если мы войдем на веб-сайт, где развернут HTTPS, поскольку данные шифруются протоколом TLS/SSL до достижения TCP, а затем отправляются, то после перехвата промежуточного трафика мы видим зашифрованный шифротекст:
Как видите, имя пользователя и пароль представляют собой строку искаженных символов. Взяв в качестве примера согласование ключа DH, клиент и сервер получают открытый ключ другой стороны после согласования ключа, а шифротекст, зашифрованный с помощью открытого ключа, может быть расшифрован только закрытым ключом другой стороны, поэтому даже если трафик перехватывается во время процесс передачи Он также может гарантировать, что данные не будут пропущены.
В дополнение к проблеме незашифрованных данных, проверка личности также является проблемой.На веб-сайте, где развернут HTTPS, агентство CA выдает для него сертификат.Сертификат содержит некоторую ключевую информацию о сервере, такую как открытый ключ сервера. и имя хоста. И т. д. Агентство ЦС подписывает сертификат своим закрытым ключом RSA. Поскольку браузер доверяет агентству ЦС, он обычно встраивает открытый ключ агентства ЦС. Во время проверки личности сервер отправляет свой собственный сертификат в клиент и просматривает Сервер использует открытый ключ ЦС для проверки подписи сертификата.После успеха открытый ключ сервера может быть использован для согласования ключей.
Протокол TLS/SSL делает много вещей.В предыдущем журнале также приведены общие шаги, а также различные подпротоколы, подсообщения и расширения.Затем захватите HTTPS-трафик, чтобы увидеть URL-адрес с момента установления соединения. к сеансу, восстановлению и другим частям контента, анализировать весь процесс обработки TLS.
Захват HTTPS-трафика
Сначала открываем веб-страницу HTTPS, в качестве примера возьмем домашнюю страницу CSDN.После открытия веб-сайта мы захватываем трафик HTTPS в процессе и видим, что веб-сайт, использующий протокол TLS, отправляет обмены во время установления соединения между клиентом (браузером) и сервер. Отдельные подсообщения :
Видно, что когда мы посещаем веб-сайт HTTPS, мы используем протокол версии TLS v1.2 и проходим процесс протокола рукопожатия.
1, Сначала клиент отправляет подсообщение Client Hello, а затем сервер отвечает ServerHello.
2, Затем сервер (обратите внимание на передний план, IP-адрес сервера — 47.95.47.253) отправляет сертификат сертификата, расширение статуса сертификата используется для проверки статуса отзыва сертификата, а подсообщение Server Key Exchange указывает часть согласования ключа, например используя согласование ключа DH, сервер должен отправить клиенту свои собственные параметры DH и открытый ключ DH, поэтому он передается через это подсообщение. Наконец, отправьте сообщение Server Hello Done.
3. После того, как клиент получает сообщение Server Hello Done, он отвечает на обмен ключами клиента для согласования ключа (например, пара ключей DH клиента генерируется в соответствии с параметрами DH, отправленными сервером, а затем Подсообщение Key Exchange отправляет открытый ключ клиента на сервер для завершения согласования ключа. Подсообщение Change Cipher Spec указывает, что параметры шифрования, необходимые для уровня записи TLS, готовы, и состояние соединения можно переключать между состояния для чтения и записи. Последний зашифрованный Подсообщение Handshake Message — это подсообщение Finished, которое используется для проверки того, что сообщение квитирования не было изменено.
4. Наконец, сервер отправляет спецификацию изменения шифра и зашифрованное сообщение рукопожатия.Обратите внимание, что сервер также отправляет новый билет сеанса на приведенном выше рисунке, указывая, что сеанс может быть восстановлен с использованием метода билета сеанса. После того, как сервер отправит подсообщение Finished, следующие данные прикладного уровня могут быть зашифрованы.
Client Hello
Как мы уже говорили, подсообщение Client Hello содержит наборы шифров (используемые для согласования), поддерживаемые клиентом, расширения и т. д. Давайте рассмотрим подробности в подсообщении Client Hello:
Вы можете видеть, что верхняя запись Уровень: протокол рукопожатия, протокол рукопожатия инкапсулирован уровнем записи TLS.Подсообщение, отправляемое в протоколе рукопожатия, является Client Hello, которое содержит самый высокий номер версии TLS v1.2, поддерживаемый клиентом, случайное число, случайный, сеанс ID и поддерживаемые наборы шифров, вы можете видеть, что существует 17 поддерживаемых наборов мумий, а поддерживаемый приоритет — TLS_AES_128_GCM_SHA256 (0x1301).
Глядя вниз, Есть также расширения для клиента, server_name указывает на то, что клиент использует расширение индикации имени сервера SNI, который сообщает серверу имя узла доступа запроса и позволяет серверу отправить соответствующий сертификат для проверки. Расширение session_ticket это сказать сервер для запроса на использование SessionTicket для восстановления сеанса. Когда полный TLS рукопожатие устанавливаются в первый раз, расширение отправленного клиента пусто, и сервер решает, поддерживать ли SessionTicket. Status_request расширение также обобщены ранее. Если OCSP онлайн протокол статуса сертификата используется для проверки состояния отзыва сертификатов, то расширение посылается. Если OCSP инкапсуляция используется, сервер отправляет запрос на OCSP. После получения ответа, то сервер отправляет клиенту клиенту. Отправить CertificateStaus суб-сообщение, содержащее информацию о состоянии отзыва сертификатов. Существует также расширение signed_certificate_timestamp , который поддерживает механизм прозрачности сертификата, которое передается от ЦС учреждения или субъекта сервера. Бревна сертификата возвращает информацию SCT, что эквивалентно билет. Контролируемые и аудит.
Server Hello
Далее смотрим Сервер, на который отвечает сервер Привет:
Видно, что обычный номер версии TLS, информация случайного числа, стоит отметить, что идентификатор сеанса равен 0, что указывает на то, что в этом рукопожатии сервер решил не использовать идентификатор сеанса для восстановления сеанса. и Server Hello All видят пустое расширение session_ticket, указывающее, что служба поддержки на стороне сервера также выбирает использование SessionTicket для восстановления сеанса, поэтому идентификатор сеанса устарел.
Certificate
Спускаясь вниз, сервер отправляет сертификат сертификата для проверки клиентом.Из информации о сертификате мы видим, что в дополнение к сертификату сущности сервера существует также промежуточный сертификат:
Первый сертификат — это наш сертификат объекта сервера, который является сервером CSDN, commonName=*.csdn.net. Версия сертификата v3, информация о серийном номере и используемый алгоритм подписи сертификата — sha256WithRSA. Следующий срок действия определяет период действия сертификата с 07.11.2018 по 06.11.2020, а еще одна важная информация, на которую стоит обратить внимание, — это открытый ключ сервера subjectPublicKey. Второй сертификат является промежуточным сертификатом, который выдается организацией GeoTrust RSA CA. Подробная информация не будет отображаться. Если вам интересно, вы можете перейти на домашнюю страницу CSDN, чтобы увидеть его.
Certificate extension
В сертификате мы также должны обратить внимание на элемент расширения сертификата, который содержит много содержимого для определения роли сертификата.В качестве примера возьмем сертификат объекта сервера, чтобы увидеть, что такое элементы расширения:
В сертификате есть 10 расширений, authorKeyIdentifier — это идентификатор ключа ЦС, subjectKeyIdentifier — это идентификатор ключа пользователя, а расширение subjectAltName определяет имя хоста сервера. Расширение keyUsage более важно и определяет функцию сертификата. Например, digitalSignature: True указывает, что цифровые подписи могут быть выполнены, а расширение extKeyUsage используется для указания использования сертификата. Часть, обведенная красным пером, может видеть, что сертификат можно использовать для проверки подлинности на стороне сервера и проверки личности на стороне клиента.
Адрес службы OCSP и адрес сертификата записываются в расширении AuthorityInfoAccess.Расширение basicConstraints указывает, что сертификат является обычным сертификатом и не может использоваться для выдачи других сертификатов.
Server Key Exchange
Используя метод согласования ключа DH, сервер отправляет клиенту параметры DH и открытый ключ, поэтому требуется подсообщение Server Key Exchange:
Вы можете увидеть открытый ключ Pubkey сервера параметра ECDH (EC Diffie-Hellman), а значение подписи подписи — это сторона сервера, подписывающая параметр DH.
Client Key Exchange
После получения параметров DH и открытого ключа, отправленных сервером, клиент использует параметры DH для создания собственной пары ключей, сохраняет закрытый ключ и отправляет открытый ключ на сервер через Client Key Exchange для завершения согласования ключа:
Change Cipher Spec
Подсообщение Change Cipher Spec очень простое: оно сообщает серверу, что параметры шифрования, требуемые клиентом, готовы, протокол уровня записи TLS клиента может шифровать данные, а состояние соединения переключается с состояния чтения на состояние записи.Для состояний чтения и записи:
Зашифрованное сообщение рукопожатия (завершено)
После того, как ваш собственный блок ключей будет готов, после отправки Change Cipher Spec отправьте другой стороне сообщение Finished, чтобы убедиться, что все сообщения рукопожатия не были подделаны:
Верх отправляет клиент, а низ отправляет сервер.
Захват сеанса возобновления
Как упоминалось ранее, существует два метода восстановления сеанса: идентификатор сеанса и билет сеанса.Здесь я беру широко используемый метод билета сеанса в качестве примера для захвата трафика HTTPS и просмотра того, какие подсообщения отправляются во время метода восстановления билета сеанса. .
Я перехватил HTTPS-трафик веб-сайта Jianshu и впервые посмотрел на процесс установления полного рукопожатия TLS:
Можно видеть, что первое полное рукопожатие TL, приветствие клиента и приветствие сервера (если сервер поддерживает это) будут иметь пустое расширение session_ticket, и сервер, наконец, отправит подсообщение New Session Ticket, которое сохраняет текущая сессия.Некоторая информация о сессии:
Например, срок действия билета 300 секунд, то есть 5 минут, и в нем же находится зашифрованное значение билета на стороне сервера. Затем мы закрываем веб-страницу Jianshu, а затем снова открываем ее, чтобы посмотреть, восстанавливает ли она сеанс с помощью метода Session Ticket: