HTTPS (полное название: безопасный протокол передачи гипертекста, безопасный протокол передачи гипертекста) — это защищенный канал HTTP, просто безопасная версия HTTP. В этой статье мы подробно расскажем о его принципе.
Зачем нужен https
Причина использования https на самом деле очень проста, потому что http небезопасен.
Когда мы отправляем относительно конфиденциальные данные (такие как ваша банковская карта, удостоверение личности) на сервер, если мы используем http для связи. Тогда безопасность не будет гарантирована.
Во-первых, в процессе передачи данные могут быть перехвачены посредником, после чего данные будут украдены посредником.
Во-вторых, после того, как данные получены посредником, посредник может изменить или заменить данные, а затем отправить их на сервер.
Наконец, после получения сервером данных он не может определить, были ли данные изменены или заменены, конечно, если сервер не может судить о том, что данные действительно исходят от клиента.
Подводя итог, http имеет три недостатка:
Конфиденциальность сообщений не может быть гарантирована
Целостность и точность сообщения не могут быть гарантированы
Надежность источника не может быть гарантирована
https был создан для решения вышеуказанных проблем.
Базовые концепты
Чтобы решить проблемы, существующие в http, https принимает некоторые технологии шифрования и дешифрования, цифровой сертификат и цифровую подпись. Давайте сначала познакомимся с основными понятиями этих технологий.
Симметричное и асимметричное шифрование
Для обеспечения конфиденциальности сообщения требуется шифрование и дешифрование. Текущие основные алгоритмы шифрования и дешифрования делятся на симметричное шифрование и асимметричное шифрование.
1. Симметричное шифрование (шифрование с общим ключом): клиент и сервер совместно используют ключ для шифрования и расшифровки сообщений.Этот метод называется симметричным шифрованием. Клиент и сервер согласовывают ключ шифрования. Клиент использует ключ для шифрования сообщения перед отправкой сообщения, а после отправки на сервер сервер использует ключ для расшифровки сообщения, чтобы получить сообщение.
Преимущества симметричного шифрования:
Симметричное шифрование решает проблему конфиденциальности сообщений в http
Недостатки симметричного шифрования:
Симметричное шифрование обеспечивает конфиденциальность сообщений, но поскольку клиент и сервер используют общий ключ, этот ключ особенно уязвим для утечек.
Поскольку риск утечки ключа высок, трудно гарантировать надежность источника сообщения, целостность и точность сообщения.
2. Асимметричное шифрование (шифрование с открытым ключом). Поскольку при симметричном шифровании ключ очень легко утекает, мы можем использовать метод асимметричного шифрования для решения этой проблемы.
При использовании асимметричного шифрования и клиент, и сервер имеют открытый ключ и закрытый ключ. Открытый ключ может быть открыт для внешнего мира, в то время как закрытый ключ виден только сам по себе.
Сообщения, зашифрованные с помощью открытого ключа, могут быть расшифрованы только с помощью соответствующего закрытого ключа. И наоборот, сообщения, зашифрованные закрытым ключом, могут быть расшифрованы только открытым ключом. Таким образом, клиент шифрует сообщение с помощью открытого ключа сервера перед отправкой сообщения, а сервер расшифровывает его с помощью собственного закрытого ключа после его получения.
Преимущества асимметричного шифрования:
Асимметричное шифрование использует открытый ключ и закрытый ключ, что решает проблему конфиденциальности сообщений в http и снижает риск утечки закрытого ключа.
Поскольку сообщение, зашифрованное с помощью открытого ключа, может быть расшифровано только с помощью соответствующего закрытого ключа, источник сообщения, а также точность и целостность сообщения в значительной степени гарантируются.
Недостатки асимметричного шифрования:
При асимметричном шифровании для шифрования сообщения необходимо использовать открытый ключ получателя, но открытый ключ не хранится в секрете и может быть получен кем угодно, включая посредника. Тогда посредник может сделать две вещи: во-первых, посредник может заменить открытый ключ клиента своим собственным, когда клиент обменивается открытым ключом с сервером. Таким образом, открытый ключ, полученный сервером, будет принадлежать не клиенту, а серверу. Сервер также не может судить о правильности источника открытого ключа. Во-вторых, посредник не может подменить открытый ключ, но он может перехватить сообщение, отправленное клиентом, затем подделать его, а затем зашифровать его открытым ключом сервера и отправить на сервер, сервер получит неправильное сообщение.
Производительность асимметричного шифрования в несколько и даже сотни раз ниже, чем у симметричного шифрования, потребляющего системные ресурсы. Именно из-за этого https объединяет два шифрования.
Цифровые сертификаты и цифровые подписи
Чтобы решить проблему ненадежности источника открытого ключа в асимметричном шифровании. Мы можем решить эту проблему с помощью цифровых сертификатов и цифровых подписей.
1. Заявление на получение цифрового сертификата
На самом деле, есть несколько специализированных органов для выдачи цифровых сертификатов, которые мы называем Центром сертификации ЦС.
Мы (сервер) можем подать заявку на получение цифровых сертификатов от этих ЦС.
Процесс подачи заявки примерно такой:
Сгенерируйте пару ключей локально, а затем обратитесь в ЦС, чтобы подать заявку на получение цифрового сертификата с вашим собственным открытым ключом и другой информацией (например, названием компании или чем-то еще).
После того, как центр сертификации получит информацию, он выберет односторонний алгоритм хеширования (например, обычный MD5) для шифрования информации, а зашифрованная вещь называется дайджестом.
Алгоритм одностороннего хеширования имеет характеристику, что он необратим в одном направлении.Пока исходное содержимое немного изменится, зашифрованные данные будут сильно отличаться (конечно, есть небольшая вероятность, что это будет повторяться. Заинтересованные друзья понимать принцип голубиного гнезда), что предотвращает подделку информации.
После создания дайджеста ЦС также шифрует дайджест своим закрытым ключом.Зашифрованные данные дайджеста называются цифровой подписью.
Наконец, центр сертификации объединит информацию о нашем приложении (включая открытый ключ сервера) с цифровой подписью для создания цифрового сертификата. Затем ЦС передает нам цифровой сертификат.
2. Как работают цифровые сертификаты
После того, как сервер получает цифровой сертификат, сервер отправляет цифровой сертификат клиенту, и клиент должен расшифровать цифровой сертификат с помощью открытого ключа ЦС и проверить действительность цифрового сертификата. Итак, как мы можем получить открытый ключ ЦС? Наши компьютеры и браузеры имеют встроенные корневые сертификаты некоторых центров сертификации, и эти корневые сертификаты содержат открытый ключ ЦС.
Причина, по которой это корневой сертификат, заключается в том, что в реальной жизни центры сертификации являются иерархическими, то есть есть центры сертификации верхнего уровня и центры сертификации следующих подуровней, что представляет собой древовидную структуру. сертификат авторитета верхнего уровня, но не беспокойтесь, открытый ключ корневого сертификата также доступен на дочернем уровне.
Клиент расшифровывает цифровой сертификат с помощью открытого ключа ЦС. Если расшифровка прошла успешно, это означает, что сертификат исходит от законного центра сертификации. После успешной расшифровки клиент получает дайджест.
В это время клиент сгенерирует сводку информации о приложении в соответствии с тем же алгоритмом хеширования, что и ЦС, и сравнит ее с расшифрованной.Если то же самое, содержимое будет полным и не подделанным. Наконец, клиент безопасно получает открытый ключ сервера из сертификата и может связываться с сервером посредством безопасного асимметричного шифрования. Таким же образом сервер может получить открытый ключ клиента.
На следующем рисунке схематично показано общее приложение сертификата и процесс его использования.
принцип https
Благодаря приведенному выше исследованию мы понимаем роль симметричного шифрования и функции асимметричного шифрования, преимущества и недостатки, а также цифровые сертификаты. https не является единой технологией для достижения, но в соответствии с их характеристиками полная интеграция этих технологий будет направлена на достижение максимальной производительности и безопасности. Эту интеграцию технологии мы называем SSL (Secure Scoket Layer Secure Sockets Layer). Таким образом, https — это не новое соглашение, оно просто добавило слой шифрования для http.
создание https
Давайте посмотрим на созданную блок-схему:
Здесь установление https разделено на 6 этапов и 12 процессов. 12 процессов будут объяснены ниже.
1. Клиент начинает связь SSL, отправляя сообщение Client Hello. Сообщение включает указанную версию SSL, поддерживаемую клиентом, и список компонентов шифрования (Cipher Suite) (используемый алгоритм шифрования, длину ключа и т. д.).
2. Когда сервер сможет взаимодействовать с SSL, он ответит сообщением Server Hello. Как и клиент, версия SSL и компоненты шифрования включены в сообщение. Содержимое компонента шифрования сервера фильтруется из полученного компонента шифрования клиента.
3. Сервер отправляет сообщение сертификата. Сообщение содержит сертификат открытого ключа.
4. Наконец, сервер отправляет сообщение Server Hello Done, чтобы уведомить клиента о том, что начальное согласование SSL завершено.
5. После первого рукопожатия SSL клиент отвечает сообщением об обмене ключами клиента. Сообщение содержит случайную строку шифра, называемую предварительным секретом, который используется при шифровании связи. Сообщение было зашифровано открытым ключом на шаге 3.
6. Затем клиент продолжает отправлять сообщение Change Cipher Spec. Это сообщение запросит сервер, и связь после этого сообщения будет зашифрована секретным ключом Pre-master.
7. Клиент отправляет сообщение Finished. Это сообщение содержит общее значение проверки всех сообщений, подключенных до сих пор. Будет ли согласование рукопожатия успешным или нет, зависит от того, сможет ли сервер правильно расшифровать сообщение.
8. Сервер также отправляет сообщение Change Cipher Spec.
9. Сервер также отправляет сообщение Finished
10. После завершения обмена сообщениями между сервером и клиентом устанавливается SSL-соединение. Конечно, связь защищена SSL. Отсюда начинается связь протокола прикладного уровня, то есть отправляется HTTP-запрос.
11. Связь протокола прикладного уровня, т. е. отправка HTTP-ответа.
12. Окончательно отключен клиентом. При отключении отправить сообщение close_notify. На приведенном выше рисунке сделаны некоторые пропуски.После этого шага отправляется сообщение TCP FIN, чтобы закрыть связь с TCP.
Кроме того, в приведенной выше блок-схеме дайджест сообщения, называемый MAC (код аутентификации сообщения), будет прикреплен, когда прикладной уровень отправляет данные. MAC может проверить, был ли пакет подделан, тем самым гарантируя целостность пакета.
Далее я буду использовать диаграмму, чтобы проиллюстрировать это визуально.Это изображение более подробно, чем изображение цифрового сертификата выше (рисунок взят из «Иллюстрированный HTTP»)
После приведенного выше введения мы видим, что https сначала использует цифровые сертификаты, чтобы гарантировать, что открытый ключ на стороне сервера может безопасно и без ошибок достичь клиентской стороны. Затем используйте асимметричное шифрование для безопасной передачи общего ключа и, наконец, используйте общий ключ для безопасного обмена данными.
использование https
HTTPS настолько безопасен, должны ли мы использовать HTTPS для связи в любом сценарии? ответ отрицательный.
1. Хотя https предоставляет канал для безопасной передачи сообщений, шифрование и дешифрование каждого сообщения занимает очень много времени и требует ресурсов системы сообщений. Поэтому, если только в некоторых сценариях с высоким уровнем безопасности, таких как банковские системы и торговые системы, мы не должны использовать https для связи, а в других сценариях, не требующих высокого уровня безопасности, нам фактически не нужно использовать https.
2. Использование https требует использования цифровых сертификатов, но обычно цифровые сертификаты, выданные авторитетными организациями, являются платными, и цена также высока, поэтому для некоторых личных веб-сайтов, особенно студентов, если требования безопасности не высоки, это Также нет необходимости использовать https.
использованная литература
https://www.jianshu.com/p/4932cb1499bf
Tickets.WeChat.QQ.com/Yes/St Qingqi A FH EP…
«Иллюстрированный HTTP»
Если есть способ, но нет искусства, искусство может быть достигнуто; если есть искусство, но нет пути, оно заканчивается на пути; добро пожаловать, чтобы обратить внимание на публичный аккаунт WeChat «Путь Java», используйте путь, чтобы овладеть искусство, и используйте искусство, чтобы знать путь!