предисловие

Все содержание этой статьи основано на содержании предисловия.

Персонажи: Маленький Синий, Маленький Красный, Маленький Черный.

Событие: Общение

Алгоритм шифрования

Симметричное шифрование

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

Маленькие синие и красные пишут любовные письма друг другу, но они не хотят, чтобы истинное содержание писем между ними было известно другим людям. Так они хотят, чтобы их любовное письмо, как другие люди не знают об этом?

Поскольку письмо отправляется через почтовое отделение, нет никакой гарантии, что письмо не будет прочитано Сяо Хэем (Сяо Темная Любовь Сяо Хун) в пути. Но им нужно только убедиться, что никто другой не может понять буквы между ними, поэтому они могут заранее договориться о правиле написания букв, например, брать каждое третье слово или брать только среднее слово каждого предложения и т. д. правило .

Согласно вышеприведенным правилам, даже если письмо прочитает Сяо Хэй, пока Сяо Хэй не знает этого правила, тогда Сяо Хэй не знает, что должно выражать письмо. Таким образом, настоящая память о письме не известна Сяо Хэю.

преимущество

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

недостатки

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

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

Зачем ограничивать Сяоланя и Сяохуна общением только через письма?Разве они не могут сначала обсудить правила шифрования наедине? Если это действительно возможно в реальной жизни, но если в нашей интернет-среде наш веб-сайт не может в частном порядке согласовать ключи со всеми пользователями, мы можем только сгенерировать симметричный ключ через запрос и отправить его пользователю, последующая связь Стороны используют этот симметричный ключ для шифрования и расшифровки содержимого, но запрос на создание и отправку ключа в начале находится в открытом тексте. Пока он находится в открытом тексте, это рискованно.

Асимметричное шифрование

Асимметричное шифрование имеет два ключа, один из которых называется закрытым, а другой — открытым. Можно использовать либо шифрование с открытым ключом, либо шифрование с закрытым ключом. Но при шифровании с открытым ключом можно расшифровать только закрытый ключ, а при частном шифровании можно расшифровать только открытый ключ.

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

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

преимущество

Открытый ключ доступен любому.

Контент, зашифрованный открытым ключом, может быть расшифрован только закрытым ключом.

недостатки

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

По сравнению с симметричным шифрованием асимметричное шифрование имеет большую потерю производительности, поэтому в целом его используют в сочетании с асимметричным шифрованием и симметричным шифрованием, как в случае с https.

Но асимметричное шифрование имеет одну из самых больших уязвимостей:атака «человек посередине», как показано на рисунке,

Из этого мы можем видеть, что наиболее важной частью является то, что Сяо Хэй перехватил сейф Сяо Ланя и заменил его своим собственным сейфом, но Сяо Лан и Сяохун ничего об этом не знали, потому что Сяохун не знал о сейфе Сяохун. Лан отправила, она могла быть уверена только в том, что сможет получить его. И Сяолань не знал, что отправленный им сейф был перехвачен, потому что ответ, который он получил, действительно был его собственным сейфом, и он мог открыть его своим ключом.

https

Как мы все знаем, все сообщения, передаваемые по протоколу http в сети, являются открытым текстом, а это означает, что мы находимся в мире сети. Пока мы получаем информацию в сети с помощью таких инструментов, как сниффер Wireshark, tcpdump, dsniff и т. д., мы можем получать информацию, отправленную другими людьми в сети.

https — это комбинация протокола http + протокола tls/ssl.

https = http + tls / ssl

Это то, что мы используемhttpУровни сетевого протокола, к которым можно получить доступ во время протокола:

Это то, что мы используемhttpsУровни сетевого протокола, к которым можно получить доступ во время протокола:

Мы видим, что https — это слой TLS/SSL, добавленный между TCP и HTTP.

Пожать руки

Ниже приведен сетевой запрос, который возникает при посещении домашней страницы Nuggets.Я использую Wireshark для захвата пакетов для анализа процесса рукопожатия Https. Я буду опускать процесс трехстороннего рукопожатия tcp и сосредоточусь только на процессе рукопожатия tls/ssl.

Client Hello

Уровень IP-протокола: красное поле слева — мой внутренний сетевой адрес, который будет преобразован во внешний сетевой адрес через протокол NAT маршрутизатора при доступе к внешней сети, а красное поле справа — внешний сетевой адрес Наггетс.

Уровень протокола TCP: красное поле слева — это порт (также называемый исходным портом), который я использовал для отправки этого запроса. Мы будем использовать этот порт (желательно с серийным номером), чтобы найти информацию, которую мне ответил сервер. Красное поле справа — это порт назначения, к которому я хочу получить доступ.Здесь видно, что порт, используемый Https, — 443, порт по умолчанию для https — 443, а порт по умолчанию для протокола http — 80.

Мы можем примерно понять, что IP — это поиск хоста, а TCP — поиск процесса на хосте.

Уровень протокола TLS: более важным является содержимое синего поля.

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

Server Hello

После того, как сервер получит сообщение Client Hello, отправленное клиентом, он немедленно отправит сообщение этого типа.

Через адрес и номер порта в красном поле мы можем подтвердить, что информация будет отвечать на указанный выше клиент Hello.

Мы по-прежнему видим, что находится в синем поле:

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

На этом этапе клиент и сервер согласовали номер версии и набор шифров, и у клиента и сервера есть два случайных числа.

Server Certificate

Сразу после сообщения Server Hello сервер немедленно отправит сообщение Server Certificate, в котором содержится очень важная вещь — CA-сертификат, именно его мы обычно и называем цифровым сертификатом.

Вы можете видеть, что красная рамка — это сертификат ЦС.

Этот сертификат обычно служит двум целям:

• Один из них аутентификация
• Во-первых, сертификат содержит открытый ключ сервера, который согласовывает предварительный главный ключ с алгоритмом согласования ключей набора шифров.

Server Key Exchange

Это сообщение отправляется только при определенных условиях.Помните, что я только что сказал в Server Hello, при выборе разных наборов шифров будут сгенерированы разные действия, и отправка этой информации относится к разным действиям.

Он отправляется с условием, что если в сертификате недостаточно информации для обмена ключами, то эта информация должна быть отправлена. Обычно согласованные наборы шифров относятся к следующим типам и будут отправлены:

• DHE_DSS
• DHE_RSA
• ECDHE_ECDSA
• ECDHE_RSA

Мы видим, что набор шифров, согласованный клиентом и сервером, относится к типу ECDHE_RSA. Итак, здесь мы видим, что это сообщение отправляется. За этой информацией следует информация о сертификате сервера.

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

Открытый ключ DHPubkey, подпись естьSignatrue, параметр DH определяется выражениемCurve Type,Named Curve,Pubkeyсостоит из.

Эта информация используется для обмена ключами. Поскольку https шифрует содержимое с помощью симметричного шифрования на этапе реальной связи, безопасность обмена ключами симметричного шифрования очень важна.Если безопасно гарантировать, что и клиент, и сервер могут получить это симметричное шифрование, вся эта информация содержится в ключе. нужно сделать.

Для получения более подробной информации вы можете проверить процесс алгоритма DH самостоятельно.Вот некоторая информация:

• Ууху. Call.com/topic/20030…
• blog.CSDN.net/Lee24486814…
• Ууху. Call.com/question/28…

Server Hello Done

После того, как сервер отправит вышеуказанную информацию, он отправит информацию немедленно, а затем дождется ответа клиента.

Эта информация выполняет две основные функции:

• Сервер отправляет достаточно информации, а затем согласовывает с клиентом предварительный мастер-ключ.
• После того, как клиент получает эту информацию, она может шагать сертификаты проверки и других ключевых переговоров

Client Key Exchange

После получения сообщения Server Hello Done от сервера клиент ДОЛЖЕН отправить это сообщение немедленно. Основная функция этой информации заключается в согласовании предварительного мастер-ключа, как правило, есть два пути:

• Клиент шифрует подготовленный мастер-ключ по алгоритму RSA/ECDSA, а затем отправляет его на сервер
• Открытый ключ DH клиента вычисляется на основе параметров DH, отправляемых сервером, и передается на сервер.

Из информации о захвате пакетов видно, что здесь используется второй метод. Потому что на сервер отправляется только один открытый ключ DH.

То, как клиент вычисляет открытый ключ Диффи-Хелмана, может относиться к процессу реализации алгоритма Диффи-Хелмана Ссылка на ссылку была дана выше.

В конечном итоге клиент и сервер вычислят один и тот же подготовительный мастер-ключ. В качестве третьего случайного числа используется предварительный мастер-ключ.

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

Конечно, нам нужно только убедиться, что третье случайное число является безопасным, тогда симметричный ключ является безопасным, и алгоритм DH используется для получения третьего случайного числа.Что касается того, как алгоритм DH обеспечивает безопасность третьего случайного числа , проверьте сами.

Изменить протокол спецификации шифра

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

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

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

Finished

Эта информация является первой информацией, зашифрованной и защищенной протоколом уровня записи TLS.Обе ​​стороны должны проверить готовую информацию, отправленную другой стороной, чтобы убедиться, что согласованный ключ доступен и что он не был подделан в процессе согласования.

Проверьте содержимое данных проверки, включая три части:

1. отмычка
2. Метка, метка клиента завершена клиентом, а метка сервера завершена сервером
3. handshake_messages, включая всю информацию о протоколе рукопожатия.

конфиденциальность

Фактически набор шифров, согласованный между клиентом и сервером, содержит несколько алгоритмов одновременно.

Возьмем наборы шифров, о которых шла речь в нашей статье:

набор шифров	алгоритм согласования ключей	Алгоритм аутентификации	Алгоритм шифрования	Хэш-алгоритм	протокол
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	ECDHE	RSA	AES-128-GSM	SHA256	TLS

Как https обеспечивает конфиденциальность Мы знаем, что симметричная криптография согласовывает случайное число с помощью алгоритма ECDHE, а затем использует случайное число 1, случайное число 2 и случайное число 3 для совместного вычисления симметричного ключа с помощью метода вычисления, потому что ключ вычисляется локально и не передается по сети, поэтому симметричный ключ является безопасным.

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

Но как алгоритм Диффи-Хелмана гарантирует, что отправленный открытый ключ Диффи-Хелмана будет отправлен клиентом? Я также столкнулся с той же проблемой, что и сертификат ЦС здесь.Как убедиться, что сертификат ЦС действителен? В сертификате CA цифровая подпись выполняется на информации CRS пользователя + информации CA + открытом ключе, предоставленном пользователем с использованием закрытого ключа CA.Пока браузер может использовать открытый ключ для расшифровки, это означает, что сертификат действителен.

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

Вот справочная статья:Как алгоритм DH предотвращает атаки типа «человек посередине»

Сертификация

Как браузер проверяет сертификат ЦС?

Прежде всего, нам нужно знать, как генерируется сертификат ЦС.Во-первых, обслуживающая сторона S, которая подает заявку на сертификат, должна предоставить CSR (запрос на подпись сертификата) стороннему агентству ЦС. получает запрос, он ответит на запрос.Например, принадлежит ли предоставленное доменное имя поставщику услуг, правильный ли адрес и т. д., только если сторонняя организация считает, что предоставленная вами информация является точной, он будет основан на (вы предоставляете информацию + информацию об агентстве CA + открытый ключ) для создания сообщения, затем для сообщения будет выполнен дайджест сообщения, а затем будет выполнена цифровая подпись для дайджеста сообщения с закрытым ключом CA . Затем сгенерируйте цифровой сертификат вместе с сгенерированной информацией и цифровой подписью и выдайте его обслуживающей стороне.

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

честность

Как клиент гарантирует, что сертификат ЦС завершен и не был изменен другими? Например, после того как третья сторона перехватывает сертификат, она изменяет содержимое сертификата.

Мы знаем, что при создании сертификата будет создан информационный дайджест для информации.После того, как клиент получит сертификат ЦС, информация в сертификате будет сгенерирована один раз, а затем сравнена с содержимым, расшифрованным цифровой подписью. если содержимое сертификата было изменено.

вопрос

Посредник мог подделать сертификат

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

Можно ли мужчине посередине заменить аттестат

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

На самом деле такой ситуации не произойдет, потому что доменное имя будет проверено в процессе проверки, и если доступное доменное имя не соответствует доменному имени в сертификате, будет предложена небезопасная ссылка. А вот если посредник может использовать ваше доменное имя для подачи заявки на сертификат, это другое дело, но этого не произойдет, потому что заявка на сертификат требует проверки информации, а подача заявки не является бесплатной.

Почему цифровые подписи подписывают хеш-значения?

На самом деле это только вопрос производительности, поскольку значение хеш-функции является относительно коротким значением по сравнению с информацией о сертификате ЦС, и шифрование и дешифрование значения будет выполняться быстрее. Обычно это время не учитывается при создании сертификата, но когда браузер расшифровывает, если время слишком велико, пользователь не может ждать так долго.

Продемонстрируйте, как государственным учреждениям можно доверять CA

На самом деле открытые ключи в ЦС встроены в операционную систему, а открытым ключам, встроенным в операционную систему, нужно доверять. Если они даже не верят, то мы не можем завершить проверку сертификата ЦС.

И сертификат ЦС не обязательно выдается агентством ЦС, но также может быть выдан агентством, уполномоченным агентством ЦС, то есть агентство ЦС также доверяет уполномоченному им агентству. Поэтому обычно мы получаем сертификат третьего уровня: сертификат первого уровня — это корневой сертификат организации ЦС, сертификат второго уровня — сертификат агента, авторизованного организацией ЦС, а сертификат третьего уровня является нашим собственным сертификатом.Эти три сертификата составляют цепочку сертификатов.

Мы видим, что сертификат в самородках представляет собой трехуровневую цепочку сертификатов.

Должен ли HTTPS сначала выполнять рукопожатие на уровне SSL/TLS при каждом запросе на передачу ключа?

Если для каждого https-запроса требуется рукопожатие TLS, рукопожатие TLS настолько сложно, что неизбежно приведет к большой задержке связи, что неприемлемо для веб-сайтов, ориентированных на взаимодействие с пользователем. Так есть ли способ избежать этого?

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