Обзор протокола HTTPS

HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, протокол передачи гипертекста на основе Secure Socket Layer) — это HTTP-канал, нацеленный на безопасность.Проще говоря, это безопасная версия HTTP. То есть к HTTP добавляется уровень SSL. Основой безопасности HTTPS является SSL. Идентичность сервера проверяется с помощью сертификата SSL, а связь между браузером и сервером шифруется. Используемый номер порта — 443.

SSL и TLS

SSL: SSL (Secure Socket Layer) — протокол безопасной передачи, разработанный Netscape главным образом для Интернета. Этот протокол широко используется в Интернете. Аутентификация сертификата гарантирует, что данные связи между клиентом и сервером веб-сайта зашифрованы и безопасны.
Протокол SSL расположен между протоколом TCP/IP и различными протоколами прикладного уровня, обеспечивая поддержку безопасности при передаче данных. Протокол SSL можно разделить на два уровня: Протокол записи SSL: он построен на основе надежного протокола передачи (например, TCP) и обеспечивает поддержку основных функций, таких как инкапсуляция, сжатие и шифрование данных для протоколов высокого уровня. Протокол SSL Handshake: он построен на протоколе записи SSL и используется взаимодействующими сторонами для аутентификации личности, согласования алгоритмов шифрования и обмена ключами шифрования до начала фактической передачи данных.
TLS: TLS (Transport Layer Security, Transport Layer Security Protocol) используется для обеспечения конфиденциальности и целостности данных между двумя приложениями.
Когда SSL был разработан до версии 3, он зарекомендовал себя как очень хороший безопасный протокол связи, поэтому группа интернет-инженеров IETF в 1999 году переименовала его в TLS (Transport Layer Security), официально стандартизировала его, а номер версии был переименован с 1.0. , поэтому TLS1.0 на самом деле является SSLv3.1. TLS 1.0 — это новый протокол, разработанный IETF (Internet Engineering Task Force, Internet Engineering Task Force). Он основан на спецификации протокола SSL 3.0 и является последующей версией SSL 3.0. Его можно понимать как SSL 3.1 (может быть просто понимается как разные названия одного и того же объекта на разных стадиях). Протокол состоит из двух уровней: TLS Record и TLS Handshake. Нижний уровень — это протокол записи TLS, который находится поверх надежного транспортного протокола (например, TCP). Основная цель TLS — сделать SSL более безопасным и сделать спецификацию протокола более точной и полной.
TLS разработала три версии: 1.1 в 2006 году, 1.2 в 2008 году и 1.3 в 2018 году. Каждая новая версия внимательно следит за развитием криптографии и текущим состоянием Интернета, постоянно повышает безопасность и производительность и становится авторитетным стандартом в области информационной безопасности.
В настоящее время наиболее широко используемым протоколом TLS является версия 1.2, а предыдущие протоколы (TLS1.1/1.0, SSLv3/v2) считались небезопасными.

Зачем использовать HTTPS

Протокол HTTPS в основном предназначен для решения проблем безопасности протокола HTTP.Использование протокола HTTP для передачи сопряжено со следующими рисками:
(1) Риск подслушивания, например, контент связи может быть получен по каналу связи, тем самым похищая пользователя. счет.
(2) Риск фальсификации, например, принудительное размещение спам-рекламы, вызывающее визуальное загрязнение.
(3) Риски выдачи себя за другое лицо, например, выдача себя за другого человека для совершения покупок, в результате чего пользователи теряют деньги.

Принцип HTTPS

HTTPS дополняет SSL/TSL на уровне приложений и сети. HTTP-запрос/ответ обычно можно разделить на шесть этапов: (1) Установить TCP-соединение; (2) Отправить HTTP-запрос; (3) Сервер обрабатывает запрос; (4) Возвращает HTTP-ответ; (5) Выпускает HTTP-запрос. TCP-соединение; (6) Браузер анализирует возвращенные ресурсы и данные. Однако HTTPS добавляет процесс установки SSL-соединения после завершения установки TCP-соединения.После установки безопасного соединения отправляются HTTP-запросы и другие последующие действия. Далее мы сосредоточимся на процессе установления соединения через SSL (здесь TLS 1.2).
Пожалуйста, добавьте описание изображения
(1) После установки TCP-соединения браузер сначала отправит сообщение «Client Hello», которое должно «приветствовать» сервер. Он содержит номер версии клиента, поддерживаемые комплекты шифров и обычный текст со случайным числом (Случайный клиент) для последующей генерации сеансовых ключей .
(2) После того, как сервер получит «Привет клиента», он вернет сообщение «Привет серверу». Проверьте номер версии и введите случайное число (случайный сервер) в виде обычного текста, а затем выберите набор шифров из списка наборов шифров, предоставленного клиентом, в качестве набора шифров , используемого для этой связи (например, алгоритм ECDHE). В то же время, чтобы подтвердить свою личность, сервер также отправляет сертификат (сертификат сервера) клиенту. Поскольку сервер выбрал набор шифров, после сертификата он отправит сообщение «Обмен ключами сервера», которое содержит открытый ключ (параметры сервера) для реализации алгоритма обмена ключами, а также собственную аутентификацию по подписи закрытого ключа.
За этим следует сообщение «Server Hello Done», что означает «приветствие завершено». Это завершает передачу первого сообщения туда и обратно (два TCP-пакета), и в результате клиент и сервер обмениваются тремя частями информации в виде открытого текста: случайные данные клиента, случайные данные сервера и параметры сервера.
(3) После того, как браузер получает сертификат сервера, он начинает подтверждать подлинность сертификата и использует открытый ключ сертификата для проверки подписи. После подтверждения личности сервера браузер генерирует открытый ключ (параметры клиента) на основе выбранного набора шифров, а затем отправляет его на сервер с помощью сообщения «Обмен ключами клиента». Теперь браузер и сервер имеют два параметра алгоритма обмена ключами (параметры клиента, параметры сервера), а затем используют алгоритм набора шифров для вычисления «Pre-Master». Теперь браузер и сервер имеют три случайных числа: Client Random, Server Random и Pre-Master. Используя эти три в качестве исходных материалов, вы можете сгенерировать главный ключ, используемый для шифрования сеанса, называемый «Главный секрет». А поскольку хакер не может получить «Предварительный мастер», он не может получить и главный ключ.
Зачем нам нужны три случайных числа: «Случайный клиент», «Случайный сервер» и «Премастер»? Это происходит главным образом потому, что протокол TLS не доверяет надежности псевдослучайных чисел браузера или сервера. Чтобы гарантировать, что они действительно «полностью случайны» и «непредсказуемы», он смешивает три ненадежных случайных числа, поэтому «случайные» Уровень выше, и безопасность более гарантирована.
Благодаря мастер-ключу и секрету сеанса, полученному на основе главного ключа, рукопожатие почти завершено. Браузер отправляет сообщение «Изменить спецификацию шифрования», а затем отправляет сообщение «Готово», чтобы переварить все ранее отправленные данные, зашифровать их и позволить серверу проверить их.
(4) После получения запроса на проверку браузера сервер выполняет те же действия и отправляет сообщения «Изменить спецификацию шифрования» и «Завершено» соответственно.
(5) После выполнения вышеуказанных операций соединение TSL устанавливается, и следующим шагом является отправка HTTP-запросов и ответов в зашифрованном виде.

Зачем использовать сертификаты

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

Односторонняя аутентификация и двусторонняя аутентификация

Односторонняя аутентификация означает, что клиенту необходимо аутентифицировать сервер.
Принципы двусторонней и односторонней аутентификации в основном одинаковы. Основное отличие состоит в том, что помимо клиента, необходимого для аутентификации сервера, серверу также необходимо аутентифицировать клиента. В каких случаях нам необходимо верифицировать клиента? Например, в некоторых банковских услугах банк потребует от клиента вставить выданный им USB-экран в компьютер или установить какой-либо элемент управления. Это аналогично концепции клиентского сертификата. Люди без этого сертификата не могут пользоваться предоставляемыми услугами. банком.

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

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

Использует ли HTTPS симметричное или асимметричное шифрование?

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

Как облачные сервисы реализуют HTTPS

Для облачных сервисов нет необходимости реализовывать HTTPS в каждом микросервисе, в Интернете также есть много статей о реализации HTTPS для Spring Boot, что вводит в заблуждение. Для облачных сервисов его необходимо реализовать только на входе в сервис.Существует два распространенных сценария реализации: один — статический ресурсоориентированный CDN, а другой — сервисно-ориентированный LB. Конечно, могут быть включены и другие ситуации, такие как брандмауэры. Для получения подробной информации обратитесь к этим двум WIKI: Одна статья поможет вам понять конфигурацию HTTPS в Alibaba Cloud и полнофункциональном HTTPS-решении Tencent Cloud .
Разработчикам и архитекторам необходимо только понимать принципы HTTPS, а когда им необходимо реализовать HTTPS, реализовать конфигурацию HTTPS на соответствующих компонентах в соответствии с существующим дизайном, и эта конфигурация обычно опирается на облачную платформу.

Недостатки HTTPS

Протокол HTTPS имеет следующие недостатки:
(1) Протокол HTTPS имеет несколько рукопожатий, что увеличивает время загрузки страницы почти на 50%.
(2) Кэширование HTTPS-соединений не так эффективно, как HTTP, и увеличивает нагрузку на данные и энергопотребление.
(3) Подача заявки на сертификат SSL стоит денег, и чем мощнее сертификат, тем выше стоимость.
(4) Алгоритмы безопасности, задействованные в SSL, потребляют ресурсы ЦП и большое количество ресурсов сервера.

Разница между HTTP и HTTPS

HTTP — это протокол передачи гипертекста, и информация передается в виде открытого текста, что создает угрозу безопасности. HTTPS устраняет недостатки безопасности HTTP и добавляет протокол безопасности SSL/TLS между сетевыми уровнями TCP и HTTP, чтобы сообщения можно было шифровать и передавать.
Установление HTTP-соединения относительно просто, и передача HTTP-сообщения может осуществляться после трехэтапного установления связи TCP. После трехэтапного установления связи TCP HTTPS все еще необходимо выполнить процесс установления связи SSL/TLS, прежде чем он сможет начать передачу зашифрованного сообщения.
Номер порта HTTP — 80, а номер порта HTTPS — 443.
Протокол HTTPS требует подачи заявки на цифровой сертификат в ЦС (центр сертификации), чтобы гарантировать надежность идентификации сервера.

ссылка

https://blog.csdn.net/hguisu/article/details/8680808 Принцип реализации HTTPS
https://zhuanlan.zhihu.com/p/466239718 Основы собеседования: шестьдесят два вопроса, часто задаваемые в компьютерных сетях
https://zhuanlan .zhihu.com/p/27395037 Сухая информация из серии HTTPS (1): Подробное объяснение принципов HTTPS
https://www.zhihu.com/tardis/zm/art/72616216 Как разобраться в протоколах HTTP и HTTPS за десять минут?
https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3
https://developer.mozilla.org/zh-CN/docs/Web/Security/Transport_Layer_SecurityTransport Layer Securityhttps
://www.cnblogs.com/huansky /p/13977181.html HTTPS простым языком (подробная версия)
https://zhuanlan.zhihu.com/p/43789231 Досконально разобраться в принципе шифрования HTTPS
https://zhuanlan.zhihu.com/p/96494976 Знаете, Использует ли HTTPS симметричное или асимметричное шифрование?
https://www.jianshu.com/p/918d9f517749 Симметричное шифрование и асимметричное шифрование в https
https://zhuanlan.zhihu.com/p/162082184 Симметричное или асимметричное — что используется в https?
https://cloud.tencent.com/document/product/400/6813Tencent Cloud реализует полнофункциональное решение HTTPS
https://help.aliyun.com/practice_detail/444367 Эта статья поможет вам понять конфигурацию HTTPS в облаке Alibaba.

рекомендация

отblog.csdn.net/wangxufa/article/details/133355754