Действительно ли я знаю разницу между http и https?

Каждый раз, когда я видел вопрос типа «Разница между http и https?», я сам думал над ответом, как будто я просто знал, что https более безопасен, чем http, но почему он более безопасен, но я не могу вроде бы сказать почему, или Сказал много деталей не понятно. Чтобы прояснить и систематически понять знания, связанные с http, я некоторое время назад читал волну "Иллюстрированный HTTP". Я должен сказать, что эта книга действительно проста для понимания, и я узнал много знаний, которые не были очистить перед (протокол, сообщения, коды состояния, поля заголовков, аутентификация, кэширование ресурсов и веб-атаки). Если вы хотите узнать больше о http, вы также можете прочитать «Авторитетное руководство по HTTP».

HTTP

HTTP, полное название протокола передачи гипертекста, представляет собой протокол передачи данных, который определяет правила взаимной связи между клиентом и веб-сервером и передает документы Всемирной паутины через Интернет. Его уникальные особенности:

Без сохранения состояния, каждый запрос будет закрыт после окончания, каждый запрос независим, его выполнение и результаты не связаны напрямую с предыдущим запросом и последующими запросами, на него не повлияет предыдущий ответ на запрос Прямо влияет и не повлияет напрямую последующий ответ на запрос; сервер не сохраняет состояние клиента, и клиент каждый раз должен приводить свое состояние на запрос к серверу, так же, как "жизнь как в первый раз", например, пользователю Если нужно запросить некоторые данные, вам нужно разрешение на вход в систему. После входа пользователя в систему выполняется запрос. В результате, поскольку http не имеет состояния, когда пользователь хочет запросить часть данных в следующий раз, ему нужно снова войти в систему. Это раздражает, поэтому вам нужно, чтобы сеанс и файлы cookie использовались для управления состоянием.
Передача открытого текста (незашифрованное сообщение), почему бы не зашифровать сообщение, является недостатком, это связано с тем, что в соответствии с рабочим механизмом семейства протоколов TCP / IP содержимое сообщения может быть просмотрено на всех линиях связи. В какой бы точке мира сервер не общался с клиентом, некоторые сетевые устройства, оптические кабели, компьютеры и т.д. на этой линии связи не могут быть личной собственностью, поэтому нельзя исключать злонамеренного подглядывания в определенном звене. . Даже если сообщение было зашифровано, содержимое сообщения можно отследить, как и незашифрованное сообщение. Это просто означает, что если сообщение зашифровано, люди могут быть не в состоянии расшифровать значение информации сообщения, но сама информация зашифрованного сообщения все равно будет был замечен.
Личности общающихся сторон не проверяются, поэтому возможен спуфинг. Запросы и ответы в протоколе HTTP не подтверждают взаимодействующие стороны. Другими словами, существуют такие проблемы, как «является ли сервер хостом, который действительно указан в URI в запросе на отправку, и действительно ли возвращенный ответ возвращается клиенту, который фактически сделал запрос» и так далее. При общении по HTTP-протоколу, поскольку нет этапа обработки для подтверждения взаимодействующей стороны, любой может инициировать запрос. Кроме того, пока сервер получает запрос, независимо от того, кто является другой стороной, он вернет ответ (но он ограничен только IP-адресом и номером порта отправителя. При условии, что доступ ограничен веб-сервером, независимо от того, кто отправил запрос, ответ будет возвращен, поэтому, если сторона связи не будет подтверждена, будут следующие скрытые опасности: 1. Невозможно определить соответствует ли запрос, отправленный на целевой веб-сервер, серверу, который действительно намеревается вернуть ответ. Это может быть замаскированный веб-сервер 2. Невозможно определить, является ли клиент, которому возвращается ответ, тем, который получил ответ в соответствии с реальным намерением. Это может быть замаскированный клиент 3. Невозможно определить, есть ли у общающейся стороны права доступа. Поскольку некоторые веб-серверы хранят важную информацию, они хотят дать разрешение на общение только определенным пользователям; 4. Невозможно определить, откуда и от кого поступил запрос; 5. Даже если это бессмысленный запрос, он будет принят в полный. Невозможно предотвратить DoS-атаки (отказ в обслуживании, атаки типа «отказ в обслуживании») при массовых запросах.
Невозможно доказать целостность сообщения. Таким образом, после отправки запроса или ответа до этого времени до получения другого, даже если содержимое запроса или ответа было подделано, нет способа узнать; другими словами, нет способа подтвердить запрос, отправленный / получен, и в ответ, пожалуйста Запрос / ответ одинаково до и после.

HTTPS

HTTPS, полное название Hyper Text Transfer Protocol Secure, по сравнению с http, есть еще один безопасный, то есть TLS (SSL), безопасный уровень сокетов. И https, и http относятся к прикладному уровню и основаны на протоколе TCP (и UDP), но они совершенно разные. Порт, используемый для TCP, — 80, а порт, используемый для https — 443.

HTTPS не является новым протоколом на уровне приложений. Только часть интерфейса связи HTTP заменена протоколами SSL (Secure Socket Layer) и TLS (Transport Layer Security). Обычно HTTP связывается напрямую с TCP. При использовании SSL он развивался для связи сначала с SSL, а затем для связи с SSL и TCP. Короче говоря, так называемый HTTPS — это на самом деле HTTP в оболочке протокола SSL.

Проблемы, решаемые HTTPS:

Проблема доверия хозяину.. Сервер, использующий https, должен быть авторизован ЦС (центр цифровой сертификации — это сторонняя организация, которой доверяют как клиент, так и сервер). С точки зрения) подайте заявку на сертификат, подтверждающий тип использования сервера, сертификат имеет подпись ЦС, клиент может знать, что доступ к серверу безопасен. В настоящее время в основном все веб-сайты или системы, такие как интернет-магазины и онлайн-банкинг, а также ключевые части приложений используют https, и клиенты доверяют хосту, доверяя сертификату, чтобы обеспечить безопасность.
Утечка и фальсификация данных во время связи При использовании протокола https вся связь между сервером и клиентом шифруется. У клиента и сервера есть своя пара асимметричных ключей, один из которых называется закрытым ключом, а другой — открытым ключом.Как следует из названия, закрытый ключ не может быть использован кем-либо еще. могут быть выпущены по желанию и доступны для всех. В методе шифрования с открытым ключом сторона, отправляющая зашифрованный текст, использует открытый ключ другой стороны для обработки шифрования, а другая сторона использует свой собственный закрытый ключ для расшифровки зашифрованной информации после получения зашифрованной информации. Таким образом, нет необходимости отправлять закрытый ключ для расшифровки, и не нужно беспокоиться о том, что ключ будет подслушан и украден злоумышленником. Чрезвычайно сложно восстановить исходное сообщение на основе зашифрованного текста и открытого ключа, потому что процесс расшифровки вычисляет дискретные логарифмы, что сделать непросто. Сделав шаг назад, если можно быстро разложить очень большое целое число, то все еще есть надежда на взлом пароля. Но это нереально с современными технологиями.

Проще говоря: HTTP + аутентификация + шифрование + защита целостности = HTTPS.

HTTPS Communication Stages

Шаг 1: Клиент инициирует связь SSL, отправляя сообщение Client Hello. Сообщение содержит указанную версию SSL, поддерживаемую клиентом, и список компонентов шифрования (Cipher Suite) (используемый алгоритм шифрования, длину ключа и т. д.).
Шаг 2: Когда сервер сможет взаимодействовать с SSL, он ответит сообщением Server Hello. Как и клиент, версия SSL и компоненты шифрования включены в сообщение. Содержимое криптографических компонентов сервера фильтруется из полученных криптографических компонентов на стороне клиента.
Шаг 3: Затем сервер отправляет сообщение сертификата. Сообщение содержит сертификат открытого ключа.
Шаг 4: Наконец, сервер отправляет сообщение Server Hello Done, чтобы уведомить клиента о том, что начальная фаза согласования подтверждения SSL завершена.
Шаг 5: После первого рукопожатия SSL клиент отвечает сообщением об обмене ключами клиента. Сообщение содержит случайную шифровальную строку под названием Pre-mastersecret, используемую для шифрования связи. Сообщение было зашифровано открытым ключом с шага 3.
Шаг 6: Затем клиент продолжает отправлять сообщение Change Cipher Spec. Это сообщение подскажет серверу, что связь после этого сообщения будет зашифрована секретным ключом Pre-master.
Шаг 7: Клиент отправляет сообщение Finished. Это сообщение содержит общее значение проверки всех сообщений, подключенных до сих пор. Будет ли согласование рукопожатия успешным или нет, зависит от того, сможет ли сервер правильно расшифровать сообщение.
Шаг 8: Сервер также отправляет сообщение Change Cipher Spec.
Шаг 9: Сервер также отправляет сообщение Finished.
Шаг 10: После завершения обмена сообщениями Finished между сервером и клиентом устанавливается SSL-соединение. Конечно, связь защищена SSL. Отсюда начинается связь протокола прикладного уровня, то есть отправляется HTTP-запрос.
Шаг 11: Связь протокола прикладного уровня, то есть отправка HTTP-ответа.
Шаг 12: Окончательно отключен клиентом. При отключении отправить сообщение close_notify. На приведенном выше рисунке сделаны некоторые упущения.После этого шага отправляется сообщение TCP FIN, чтобы закрыть связь с TCP.

Ниже представлена иллюстрация всего процесса. На схеме показан весь процесс установления соединения HTTPS с использованием только сертификата открытого ключа на стороне сервера (сертификат сервера).

Технология шифрования HTTPS

Дилемма шифрования с общим ключом

Шифрование и дешифрование одним и тем же ключом называется шифрованием с общим ключом (Common key Encryption). криптосистема), также известная как шифрование с симметричным ключом. При шифровании с помощью общего ключа ключ также должен быть отправлен другой стороне. Но как может Безопасный трансфер? При пересылке ключей в Интернете, если связь контролируется, то ключ Он может попасть в руки злоумышленников, и при этом потерять смысл шифрования. Также должны Постарайтесь надежно сохранить полученный ключ. То есть есть риск быть подслушанным при отправке ключа, если он не будет отправлен, другая сторона не сможет его расшифровать. Кроме того, если ключ может быть доставлен безопасно, то данные также могут быть доставлены безопасно, тогда шифрование теряет смысл.
Шифрование с открытым ключом с использованием двух ключей

Метод шифрования с открытым ключом хорошо решает проблему шифрования с общим ключом. Шифрование с открытым ключом использует пару асимметричных ключей. Один из них называется закрытым ключом, а другой — открытым ключом. Как следует из названия, закрытый ключ не может быть известен никому другому, в то время как открытый ключ может быть выпущен по желанию и доступен любому. В методе шифрования с открытым ключом сторона, отправляющая зашифрованный текст, использует открытый ключ другой стороны для обработки шифрования, а другая сторона использует свой собственный закрытый ключ для расшифровки зашифрованной информации после получения зашифрованной информации. Таким образом, нет необходимости отправлять закрытый ключ для расшифровки, и не нужно беспокоиться о том, что ключ будет подслушан и украден злоумышленником. Кроме того, чрезвычайно сложно восстановить исходное сообщение на основе зашифрованного текста и открытого ключа, потому что процесс расшифровки вычисляет дискретный логарифм, что сделать непросто. Сделав шаг назад, если можно быстро разложить очень большое целое число, то все еще есть надежда на взлом пароля. Но это нереально с современными технологиями.
HTTPS использует гибридный механизм шифрования.

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

Проблемы с HTTPS

Достаточно ли безопасен HTTPS? В мире нет абсолютной безопасности. Например, уязвимость Heartbleed в 2014 году охватила весь мир, и многие веб-сайты оказались под угрозой сердечного кровотечения, включая такие веб-сайты, как Yahoo и stackoverflow. Но в целом HTTPS относительно безопасен для большинства людей, по крайней мере, более безопасен, чем HTTP.
Еще одна проблема с HTTPS заключается в том, что при использовании SSL меняется скорость его обработки.медленный

Есть два типа медленного SSL. Во-первых, связь медленная. Другой означает, что скорость обработки низкая из-за большого потребления ресурсов, таких как ЦП и память.

Загрузка сети может быть от 2 до 100 раз медленнее по сравнению с использованием HTTP. В дополнение к соединению с TCP и отправке HTTP-запроса/ответа также требуется связь SSL, поэтому общий трафик обработки неизбежно увеличится.
Другое дело, что SSL должен быть зашифрован. И сервер, и клиент должны выполнять операции шифрования и дешифрования. В результате он потребляет больше аппаратных ресурсов сервера и клиента, чем HTTP, что приводит к увеличению нагрузки. -Фундаментального решения проблемы замедления нет, мы будем использовать аппаратный ускоритель SSL (выделенный сервер), чтобы решить эту проблему. Аппаратное обеспечение предназначено для связи SSL, и по сравнению с программным обеспечением оно может повысить скорость вычислений SSL в несколько раз. Используйте ускоритель SSL только для обработки SSL, чтобы разделить нагрузку.

Почему бы не использовать HTTPS постоянно?

Потому что зашифрованная связь потребляет больше ресурсов ЦП и памяти, чем передача обычного текста. Если каждое общение будет зашифровано, оно будет потреблять много ресурсов, а при его равномерном распределении по компьютеру количество запросов, которые можно обработать, непременно соответственно уменьшится. Поэтому, если это неконфиденциальная информация, используйте HTTP-связь и используйте HTTPS для шифрования связи только в том случае, если она содержит конфиденциальные данные, такие как личная информация. Особенно когда те веб-сайты с большим трафиком зашифрованы, нагрузку, которую они несут, нельзя недооценивать. При шифровании шифруется не все, а только то, что требует сокрытия информации для экономии ресурсов.
Хотите сэкономить на покупке сертификатов также является одной из причин. Для связи по протоколу HTTPS требуется сертификат. Используемый сертификат должен быть приобретен в центре сертификации (ЦС). Цены на сертификаты могут незначительно отличаться в зависимости от центра сертификации. Сервисы, для которых приобретение сертификата экономически невыгодно, а также некоторые личные веб-сайты могут использовать для связи только протокол HTTP.

Справочная литература

«Иллюстрированный HTTP»

Полное руководство по HTTP