предисловие

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

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

Эта статья также будет синхронизирована с моейперсональный сайт.

текст

Как выглядит HTTP?

HTTP — это протокол прикладного уровня, основанный на TCP/IP, поэтому он указывает только некоторый контент для передачи, а также информацию заголовка, а затем передает его по протоколу TCP, полагаясь на протокол IP для адресации. , Фигура для описания:

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

Как насчет шифрования?

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

Этот метод шифрования называется:Симметричное шифрование. Шифрование и дешифрование одним и тем же ключом называется симметричным шифрованием.

Хорошо, мы зашифровали данные, проблема решена?

А несколько клиентов?

Это один клиент, а в WWW тысячи клиентов, что будет?

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

Подумайте, есть ли другой выход?

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

Как передаются симметричные ключевые ключи шифрования?

Мы применяем разные симметричные ключи шифрования к каждому клиенту, так как клиент или сервер узнают этот ключ?Он может сгенерировать секретный ключ только на одном конце и передать его на другой конец через HTTP:

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

как будто мы вошлиwhile(1), не могу выйти.

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

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

Закрытый ключ хранится только на стороне сервера, а открытый ключ может быть отправлен всем клиентам.

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

Теперь у нас все еще есть проблема, что если посредник подделал открытый ключ:

MITM: Атака «Человек посередине»

Открытый ключ, полученный клиентом, является поддельным, как решить эту проблему?

сторонняя сертификация

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

В HTTPS используйтеСертификат + цифровая подписьДля решения этой проблемы.

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

Цифровой сертификат = информация о веб-сайте + цифровая подпись

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

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

Зачем подпись?

Можно подумать, зачем вам цифровая подпись?

Сторонний орган по сертификации является открытой площадкой, мы можем подать заявку, и посредники также могут подать заявку:

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

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

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

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

Общая проточная диаграмма

HTTPS = HTTP + TLS/SSL

В HTTPS есть много более конкретного содержимого, вы можете использовать следующий рисунок в качестве справки:

Суммировать

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

Добро пожаловать, чтобы обратить внимание на мой общедоступный номер

Справочная статья

en.wikipedia.org/wiki/HTTPS woohoo.instant SSL.com/HTTPS-tutor… он сказал.com/blog/201610... Ооо,ооо .вест.К/инициировать/список.Осин... woo woo .cn blog on.com/Zhang's he oh you... woohoo.wired.com/2016/04/HAC…