Как «HTTPS» объясняет вам HTTPS простым для понимания образом?

HTTPS
Как «HTTPS» объясняет вам HTTPS простым для понимания образом?

Прежде чем читать эту статью, давайте рассмотрим несколько вопросов интервью:

  • чтоHTTPS?
  • HTTPSУлучшатьHTTPКакие проблемы существуют?
  • HTTPSКаков принцип шифрования?
  • что对称加密а также非对称加密?
  • HTTPSпроцесс переноса?
  • Что такое цифровой сертификат? Зачем нужен цифровой сертификат?
  • Зачем нужна цифровая подпись?

...

Если вы можете точно ответить на приведенные выше вопросы, вам не нужно продолжать чтение ниже, если нет, то, прочитав эту статью, я уверен, вы определенно сможете полностью понять ее.HTTPS. Ладно, без лишних слов, приступим.

Что такое HTTPS

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

https1.png

Прежде чем мы захотим что-то узнать, мы должны узнать, что это такое, а затемHTTPSЧто тогда?

Многие студенты могут сказать:HTTPSэто то, что может шифровать наши запросы». Действительно, все мы знаем,HTTPSЕго можно зашифровать, но понимание многих студентов ограничивается этим, и глубокого понимания у них быть не может.HTTPS. Так что же это?HTTPS?

HTTPSвHTTPосновываться наSSLслой шифрования и шифрует передаваемые данные, даHTTPБезопасная версия протокола. Проще говоря,HTTPSто естьHTTP + SSL:

https2.png

О, оказываетсяHTTPS"Волк в овечьей шкуре".HTTPВы должны понять это, если вы этого не понимаете, рекомендуется сначала прочитатьHTTPсвязанная информация.

ЭтоSSLЧто это такое?

https5.png

мы все знаем,HTTPэто протокол прикладного уровня,HTTPпрямо иTCPкоммуникации, когда мы заменяемHTTPS, он эволюционирует в первую иSSLсвязь, а затемSSLа такжеTCPкоммуникация. Зная этот процесс, давайте подумаем, каким процессом осуществляется процесс шифрования? Оказывается, процесс шифрованияHTTP->SSLдостигается на данном этапе, поэтомуSSLПроще говоря, это достижениеHTTPПроцесс шифрования:

https6.png

对称加密а также非对称加密,散列函数Что это? Я расскажу об этом позже, вы должны сначала запомнить эти понятия.

Для чего нужен HTTPS?

Прежде чем объяснять роль HTTPS, давайте посмотримHTTPКаковы недостатки:

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

из-заHTTPУ него нет самой функции шифрования, поэтому он не может шифровать содержимое связи. То есть способ, которым мы передаем, находится непосредственно в форме открытого текста.Эти данные открытого текста будут проходить через несколько физических узлов, таких как промежуточные прокси-серверы, маршрутизаторы, точки доступа Wi-Fi, операторы связи и т. д., что эквивалентно всем коммуникациям. данные в сети裸奔, думать об этом интересно.

Итак, очевидно, что не так с передачей открытого текста? Передача открытого текста может привести к数据泄露,数据篡改,流量劫持,钓鱼攻击череда опасностей. Предположим, что есть такой сценарий: однажды у вашей другой девушки день рождения, поэтому вы входите в свой почтовый ящик с помощью браузера и хотите отправить ей поздравление с днем ​​​​рождения. Если этот сайт электронной почты используетHTTPСоглашение, когда вы нажимаете отправить, ваш «контент благословения» (примечание: он в открытом тексте) перехватывается хакером, а затем этот «контент благословения» напрямую пересылается вашей «текущей девушке», после чего последствия просто невообразимы .

  • Невозможно пройти аутентификацию при общении с сервером

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

Разобравшись с дефектами HTTP, мы, естественно, знаем, для чего используется HTTPS:

  • Обеспечьте безопасность данных (зашифруйте наши данные в виде открытого текста)
  • Гарантия целостности данных
  • Аутентификация

Как шифруется HTTPS (процесс SSL)

Из вышеизложенного мы знаемHTTPSДанные могут быть зашифрованы, так как именно они зашифрованы?

Здесь нам нужно понять два метода шифрования:

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

Не думайте, как трудно их будет понять, твердо верьте, что все знания о компьютерных сетях纸老虎.

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

Так что же对称加密Шерстяная ткань?

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

Проще говоря, симметричное шифрование означает, что обе стороны связи имеют одинаковые钥匙, для открытия же集装箱(расшифровка) и, таким образом, способ получения данных:

https3.png

Возможно ли симметричное шифрование для HTTPS?

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

1. Сервер передает приватный ключ в браузер

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

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

Очевидно, что эти два допущения, мы не можем добиться эффекта шифрования, который мы хотим, так对称加密временно намиpass.

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

Так как симметричное шифрование не работает, то нам нужно рассмотреть非对称加密да, это非对称加密Что это такое?

Давайте посмотрим на тот, что чуть выше 👆运送货物пример:

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

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

Проще говоря, есть два ключа, один называется открытым ключом, а другой называется закрытым ключом. Содержимое, зашифрованное с помощью открытого ключа, можно расшифровать только с помощью закрытого ключа, аналогично, содержимое, зашифрованное с помощью закрытого ключа, можно расшифровать только с помощью открытого ключа. Открытый ключ асимметричен закрытому ключу, поэтому мы называем этот метод шифрования非对称加密:

https4.png

Можно ли использовать асимметричное шифрование для HTTPS?

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

Браузер инициирует запрос к серверу.После того, как сервер получает запрос, он передает браузеру открытый ключ.Затем при следующем общении, когда браузер хочет отправить данные на сервер, он сначала шифрует данные с помощью открытого ключ, а затем отправляет его на сервер. После того, как сервер его получит, он расшифровывает его с помощью соответствующего закрытого ключа, что гарантирует, что浏览器->服务器Безопасность данных таким образом. Поскольку данные, которые браузер отправляет на сервер, только у сервера есть закрытый ключ, чтобы расшифровать их. Затем, в свою очередь,服务器->浏览器Безопасно ли это общение?

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

Итак, очевидно, используя非对称加密Не могу гарантировать服务器->浏览器Безопасность данных для этой ссылки.

Как и выше, давайте найдем способ.

Мы только что узнали посредством анализа, что с помощью набора公钥 + 私钥, мы можем гарантировать浏览器->服务器безопасности, то можем ли мы использовать два набора公钥 + 私钥Для достижения безопасности двух ссылок?

Предположим теперь, что браузер предварительно сохраняет набор公钥а также私钥, сервер также предварительно хранит набор公钥а также私钥, давайте посмотрим на следующий процесс коммуникации:

1. Браузер инициирует запрос к серверу и несет открытый ключ браузера;

2. После того, как сервер получает открытый ключ браузера, он возвращает открытый ключ сервера браузеру;

3. Прежде чем браузер отправит данные на сервер, он использует открытый ключ, предоставленный сервером, для шифрования данных (гарантируя浏览器->服务器безопасность данных);

4. Получив данные, сервер расшифровывает их собственным закрытым ключом, начинает отвечать на запрос и шифрует данные ответа открытым ключом, предоставленным браузером (гарантируя服务器->浏览器безопасность данных);

5. После получения данных браузер расшифровывает их собственным закрытым ключом.

Вышеупомянутый процесс, чтобы мы могли сделать:浏览器->服务器,服务器->浏览器Оба канала безопасны, потому что они оба могут предоставлять друг другу открытый ключ для использования друг другом, и оба могут расшифровывать данные, отправленные другой стороной, с помощью своего собственного закрытого ключа. Кажется идеальным, правда?

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

Поскольку две группы公钥 + 私钥Метод очень трудоёмкий, поэтому давайте найдём способ уменьшить количество асимметричных шифровок, не так ли?

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

теперь, когда非对称加密Сравнивать对称加密Отнимает много времени, можем ли мы объединить их для решения вышеуказанных проблем? Таким образом, мы уменьшаем количество асимметричных шифровок до одного.

Предположим, что сервер предварительно хранит набор公钥(假设叫 A+ )а также私钥(假设叫 A- ), давайте взглянем на следующий процесс коммуникации:

1. Браузер инициирует запрос к серверу;

2. Сервер будет公钥A+ вернуться в браузер;

3. Браузер генерирует ключ локальноB, затем используйте公钥A+ На ключеBШифровать, шифровать и передавать на сервер;

4. Сервер получает данные и использует私钥A-Расшифровать данные и получить ключ, сгенерированный браузеромB;

5. После общения между двумя сторонами используется ключBпровести.

Этот способ идеален, на самом делеHTTPSЭто использование этого метода шифрования для достижения шифрования. Подумайте хорошенько, надежно ли это?

Вот уловка偷梁换柱:

Предположим, что сервер предварительно хранит набор公钥(假设叫 A+ )а также私钥(假设叫 A- )

У посредника также есть набор公钥(假设叫 B+ )а также私钥(假设叫 B- )

Теперь посмотрите на следующий процесс:

1. Браузер инициирует запрос к серверу;

2. Сервер отвечает на запрос и возвращает公钥A+

3. Угнано посредником公钥A+После этого верните свой в браузер公钥B+ :

https8.png

4. Браузер получает公钥B+ После этого сгенерируйте密钥X, то через公钥B+правильно密钥XШифруется и затем отправляется на сервер;

5. Данные, загруженные посредником в угнанный браузер, через его собственный私钥B- Расшифруйте данные, чтобы получить宓钥X(потому что私钥Xчерез公钥B+зашифровано, чтобы человек в середине мог его расшифровать), а затем использовать公钥 A+правильно密钥XЗашифрован и, наконец, передается на сервер:

https9.png

Примечание. Посредник уже получил права доступа к серверу.公钥A+и браузера密钥X

6. Сервер получает данные от посредника и использует私钥A-расшифровать, получить密钥X

Далее, содержимое браузера и сервера может быть украдено посредником, потому что он его получил.密钥X.

Таким образом, посредник получает информацию без ведома браузера и сервера.密钥X, хороший трюк偷梁换柱какие!

Так что похоже,非对称加密 + 对称加密Неужели больше нельзя?

Цифровой сертификат

Как указано выше,非对称加密+对称加密Также существует риск быть украденным и взломанным.Посредник использует хитрость偷梁换柱понятно密钥X, и ни одна из сторон не знает密钥Xпросочился. Давайте сначала проанализируем, почему он может получить密钥XВ чем причина? Давайте посмотрим на шаг 3 выше 👆:

3、中间人挟持到公钥A+之后,给浏览器返回自己的公钥B+;

Ты это видел? Здесь возникает проблема, браузер просто не может подтвердить, что он получил公钥Это целевой веб-сайт?公钥, именно из-за этого посредник возвращает свой公钥B+, но браузер глупо думает, что это то, что предоставляет целевой сервер公钥Вот это да.

Для решения этой проблемы используйте数字证书, что数字证书Шерстяная ткань?

Здесь, позвольте мне сначала задать вам вопрос, как вы докажете, что вы тот, кто вы есть? Например, Чжан Сан, как Чжан Сан доказывает другим, что он Чжан Сан? Это очень просто, просто используйте удостоверение личности, правильно, просто используйте его.身份证. Наше национальное правительство издает身份证, С этим удостоверением личности мы можем использовать его, чтобы подтвердить нашу личность, когда мы занимаемся бизнесом Государство говорит, что вы Чжан Сан, смеют ли другие люди сомневаться в этом?

Затем начинается самое интересное, можем ли мы дать веб-сайту身份证Шерстяная ткань?

Ответ, конечно, да, и когда дело доходит до этого, я думаю, вы поняли:数字证书на самом деле это веб-сайт身份证Ух ты!

Кто будет награжден сайтом身份证Шерстяная ткань?

В мире существует загадочная организация:Агентство ЦА. это то, что он выдает веб-сайт身份证. Когда веб-сайт хочет включитьHTTPSсоглашение, необходимоCA机构подать заявку на один证书,это证书то есть数字证书.

数字证书Включая информацию о держателе сертификата, открытый ключ и срок действия, а также другую информацию.

С этим сертификатом, когда браузер инициирует запрос к серверу целевого веб-сайта, серверу нужно только数字证书Просто верните его в браузер. Поскольку целевой сайт имеет数字证书, как удостоверение личности, то браузер может подумать, что возвращаемые мне данные принадлежат этому веб-сайту.

Вы думали, что это конец?

Здесь возникает другой вопрос: что делать, если сертификат был украден и изменен посредником во время передачи самого сертификата?

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

цифровой подписи

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

Так,数字签名появился. Когда дело доходит до подписи, каждый должен знать, что подпись в повседневной жизни — это использование ручки для подписи на листе бумаги. По сути, наша цифровая подпись такая же. Проще говоря, мы можем понять это так: прежде чем агентство CA выдает сертификат веб-сайту, сертификат размещается на сертификате.签个名.接下来我们来看看到底是如何签名的:

Предположим, что агентство ЦС имеет набор асимметричного шифрования.公钥A+а также私钥A-

1. Сайт обращается в агентство CA для выдачи цифрового сертификата;

2. После того, как агентство CA пройдет аудит, будут сгенерированы данные сертификата (в настоящее время это открытый текст, включая: информацию о владельце сертификата, открытый ключ веб-сайта, срок действия и т. д.);

3. Данные открытого текста сертификата обрабатываются хэш-функцией.Hashпроцесс, генерировать数据摘要;

4. Затем используйте私钥A-к этому数据摘要зашифровать, получить数字签名;

5. Будет证书明文数据 + 数字签名сливаются воедино, образуя целостную数字证书;

5. Поместите это数字证书выдается на соответствующий сайт.

https10.png

Благодаря вышеуказанным шагам мы можем узнать, что на самом деле数字签名то естьДанные после того, как агентство ЦС шифрует данные сертификата с помощью собственного набора асимметричных закрытых ключей..

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

Я не знаю, заметили ли вы, третий шаг выше:

3、利用散列函数对证书的明文数据进行Hash处理,生成一份数据摘要;

На самом деле это не обязательно, потому что на самом деле нам нужно подписать только открытые данные сертификата Почему нам нужно сначала подписать открытые данные здесь?Hashиметь дело с этим?

Это связано с тем, что, вообще говоря, содержание сертификата длинное, а асимметричное шифрование также требует очень много времени, поэтому непосредственное подписание исходного текста занимает много времени. На самом деле агентство CA подписывает долго, но очень болезненно, когда это проверяется браузером. В настоящее время мы можем использовать хэш-функцию для обработки исходных данных.Hash, чтобы получить короче数据摘要, а потом исправить数据摘要Просто подпишите это.

Итак, теперь у нас есть数字签名благословенный数字证书, когда браузер его получит, как это проверить?

Следует отметить, что наш браузер предварительно сохранил CA公钥, роль этого открытого ключа состоит в том, чтобы разблокировать数字签名из.

1. Браузер инициирует запрос к серверу текущего сайта;

2, целевой сервер поставил数字证书Вернитесь в свой браузер (включая данные экспресс-сертификата + ЭЦП);

3, браузер получает数字证书После этого получить签名, используя предварительно сохраненный в браузере открытый ключ центра сертификации, чтобы签名Расшифровать и получить копию после расшифровки数据摘要(ПредполагаяT), затем используйте информацию, предоставленную в сертификатеHash算法правильно明文数据провестиHash, и получить сводку данных (при условии, что она называетсяS). В этот момент, еслиT=S, браузер считает сертификат действительным, в противном случае он недействителен.

https11.png

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

Может быть, у вас все еще есть вопросы, почему数字签名, вы можете проверить数字证书Был ли он изменен? Давайте попробуем:

1. Браузер инициирует запрос к серверу текущего сайта;

2, целевой сервер поставил数字证书Возврат в браузер (включая данные открытого текста сертификата + цифровая подпись);

3. Посредник похищен数字证书и модифицированный数字证书, то он возвращает модифицированный数字证书в браузер;

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

Полный рабочий процесс HTTPS

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

Теперь предположим, что организация ЦС имеет набор асимметричного шифрования.公钥A+а также私钥A-(Браузер предварительно сохранит公钥A+)

Целевой сервер также имеет набор асимметричного шифрования公钥B+а также私钥B-

1. Браузер инициирует запрос к серверу;

2. Целевой сервер получает запрос и数字证书Вернулся в браузер (включая公钥B++ цифровая подпись);

3. После того, как браузер получит сертификат, сначала получите его签名, используя предварительно сохраненный в браузере ЦС公钥A+,правильно签名Расшифровать и получить копию после расшифровки数据摘要(ПредполагаяT), затем используйте информацию, предоставленную в сертификатеHash算法правильно明文数据провестиHash, и получить сводку данных (при условии, что она называетсяS). В этот момент, еслиT=S, сертификат считается действительным. Если он действителен, перейдите к следующему шагу, в противном случае сразу отключитесь;

4. Браузер извлекает информацию о целевом веб-сайте из сертификата.公钥B+, затем сгенерируйте ключ локальноX, затем используйте公钥B+ ключ парыXШифровать, шифровать и передавать на сервер;

5. Сервер получает данные и использует私钥B-Расшифровать данные и получить ключ, сгенерированный браузеромX;

6. После общения между двумя сторонами используется ключXпосле шифрования.

Теперь, вы можете также полностью описать процесс?

Почему не все сайты используют HTTPS

Поскольку HTTPS настолько безопасен, почему до сих пор существует много веб-сайтов, не поддерживающих HTTPS?

  • Сертификат стоит денег 😄

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

  • Развертывание, эксплуатация и обслуживание сложнее, чем HTTP

Для предприятия или компании, если оно может сэкономить затраты, оно сэкономит затраты.После выбора HTTPS рабочая сила также потратит определенное количество ресурсов.

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

сказать в конце

Не знаю, можете ли вы сейчас ответить на изначально поставленные в статье вопросы?

И, наконец, я Дзюфей, передовой инженер-копатель, который любит ловить рыбу. Если вы считаете, что эта статья принесла вам какую-то пользу, пожалуйста, поставьте мне большой лайк 😄

использованная литература

GitHub.com/Parts/BL…

zhuanlan.zhihu.com/p/43789231

блог Лжец Oh.com/full-in-he-and-…

Секунда тела идет store.com/blog/types-…