HTTPS

Материал из Википедии — свободной энциклопедии
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 14 сентября 2023 года; проверки требуют 16 правок.
Перейти к навигации Перейти к поиску
HTTPS
Название Hyper Text Transfer Protocol Secure
Уровень (по модели OSI) Прикладной
Семейство TCP/IP
Создан в 2000 года
Порт/ID 443/TCP
Назначение протокола Безопасное соединение с сервером
Спецификация RFC 2818
Основные реализации (клиенты) веб-браузеры
Основные реализации (серверы) Apache, nginx, IIS
Логотип Викисклада Медиафайлы на Викискладе

HTTPS (аббр. от англ. Hyper Text Transfer Protocol Secure) — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL[1]. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443[2].

Протокол был разработан компанией Netscape Communications для браузера Netscape Navigator в 1994 году[3].

Принцип работы

[править | править код]

HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS[4]. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения — от снифферских атак и атак типа man-in-the-middle, при условии, что будут использоваться шифрующие средства и сертификат сервера проверен и ему доверяют[5].

По умолчанию HTTPS URL использует 443 TCP-порт (для незащищённого HTTP — 80)[2]. Чтобы подготовить веб-сервер для обработки https-соединений, администратор должен получить и установить в систему сертификат открытого и закрытого ключа для этого веб-сервера. В TLS используется как асимметричная схема шифрования (для выработки общего секретного ключа), так и симметричная (для обмена данными, зашифрованными общим ключом). Сертификат открытого ключа подтверждает принадлежность данного открытого ключа владельцу сайта. Сертификат открытого ключа и сам открытый ключ посылаются клиенту при установлении соединения; закрытый ключ используется для расшифровки сообщений от клиента[6].

Существует возможность создать такой сертификат, не обращаясь в центр сертификации. Подписываются такие сертификаты этим же сертификатом и называются самоподписанными (self-signed). Без проверки сертификата каким-то другим способом (например, звонок владельцу и проверка контрольной суммы сертификата) такое использование HTTPS подвержено атаке посредника[7].

Эта система также может использоваться для аутентификации клиента, чтобы обеспечить доступ к серверу только авторизованным пользователям. Для этого администратор обычно создаёт сертификаты для каждого пользователя и загружает их в браузер каждого пользователя. Также будут приниматься все сертификаты, подписанные организациями, которым доверяет сервер. Такой сертификат обычно содержит имя и адрес электронной почты авторизованного пользователя, которые проверяются при каждом соединении, чтобы проверить личность пользователя без ввода пароля[8].

В HTTPS для шифрования используется длина ключа 40, 56, 128 или 256 бит. Некоторые старые версии браузеров используют длину ключа 40 бит (пример тому — IE версий до 4.0), что связано с экспортными ограничениями в США. Длина ключа 40 бит не является надёжной. Многие современные сайты требуют использования новых версий браузеров, поддерживающих шифрование с длиной ключа 128 бит, с целью обеспечить достаточный уровень безопасности. Шифрование с длиной ключа 128 бит значительно затрудняет подбор паролей и доступ к личной информации[6].

Традиционно на одном IP-адресе может работать только один HTTPS-сайт. Для работы нескольких HTTPS-сайтов с различными сертификатами применяется расширение TLS под названием Server Name Indication (SNI)[9].

На 17 июля 2017 года 22,67 % сайтов из списка «Alexa top 1,000,000» используют протокол HTTPS по умолчанию[10]. HTTPS используется на 4,04 % от общего числа зарегистрированных российских доменов[11].

Идентификация в HTTPS

[править | править код]

Идентификация сервера

[править | править код]

HTTP/TLS-запросы генерируются путём разыменования URI, вследствие чего имя хоста становится известно клиенту. В начале общения сервер посылает клиенту свой сертификат, чтобы клиент идентифицировал его. Это позволяет предотвратить атаку посредника. В сертификате указывается URI сервера. Согласование имени хоста и данных, указанных в сертификате, происходит в соответствии с протоколом RFC2459[12].

Если имя сервера не совпадает с указанным в сертификате, то пользовательские программы, например браузеры, сообщают об этом пользователю. В основном, браузеры предоставляют пользователю выбор: продолжить незащищённое соединение или прервать его[13].

Идентификация клиента

[править | править код]

Обычно сервер не располагает информацией о клиенте, достаточной для его идентификации. Однако для обеспечения повышенной защищённости соединения используется так называемая "two-way authentication". При этом сервер после подтверждения его сертификата клиентом также запрашивает сертификат. Таким образом, схема подтверждения клиента аналогична идентификации сервера[14].

Совместное использование HTTP и HTTPS

[править | править код]

Когда сайты используют смешанную функциональность HTTP и HTTPS, это потенциально приводит к информационной угрозе для пользователя. Например, если основные страницы некоторого сайта загружаются, используя HTTPS, а CSS и JavaScript загружаются по HTTP, то злоумышленник в момент загрузки последних может подгрузить свой код и получить данные HTML-страницы. Многие сайты, несмотря на такие уязвимости, загружают контент через сторонние сервисы, которые не поддерживают HTTPS. Механизм HSTS позволяет предотвратить подобные уязвимости, заставляя принудительно использовать HTTPS-соединение даже там, где по умолчанию используется HTTP[15].

Атаки с использованием анализа трафика

[править | править код]
Основная статья: Атака с использованием анализа трафика

В HTTPS были обнаружены уязвимости, связанные с анализом трафика. Атака с анализом трафика — это тип атаки, при которой выводятся свойства защищённых данных канала путём измерения размера трафика и времени передачи сообщений в нём. Анализ трафика возможен, поскольку шифрование SSL/TLS изменяет содержимое трафика, но оказывает минимальное влияние на размер и время прохождения трафика. В мае 2010 года исследователи из Microsoft Research и Университета Индианы обнаружили, что подробные конфиденциальные пользовательские данные могут быть получены из второстепенных данных, таких, например, как размеры пакетов. Анализатор трафика смог заполучить историю болезней, данные об использовавшихся медикаментах и проведённых операциях пользователя, данные о семейном доходе и пр. Всё это было произведено несмотря на использование HTTPS в нескольких современных веб-приложениях в сфере здравоохранения, налогообложения и других[16].

Рис.1 Стандартная конфигурация сети. Пользователь на хосте клиента (CH) хочет осуществить безопасную транзакцию, но уязвим для атаки «человек в середине».

Атака посредника

[править | править код]
Основная статья: Атака посредника

При атаке посредника используется то, что сервер HTTPS отправляет сертификат с открытым ключом в браузер. Если этот сертификат не заслуживает доверия, то канал передачи будет уязвимым для атаки злоумышленника. Такая атака заменяет оригинальный сертификат, удостоверяющий HTTPS-сервер, модифицированным сертификатом. Атака проходит успешно, если пользователь пренебрегает двойной проверкой сертификата, когда браузер отправляет предупреждение. Это особенно распространено среди пользователей, которые часто сталкиваются с самозаверенными сертификатами при доступе к сайтам внутри сети частных организаций[17].

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

  1. Злоумышленник встраивается между клиентом и сервером;
  2. Пересылает все сообщения от клиента серверу без изменений;
  3. Перехват сообщений от сервера, посланных по шлюзу по умолчанию;
  4. Создание самозаверенного сертификата и подмена им сертификата сервера;
  5. Отправление ложного сертификата клиенту;
  6. Когда клиент подтвердит сертификат, будут установлены защищённые соединения: между злоумышленником и сервером и другое — между злоумышленником и клиентом.

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

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ Ярослава Рябова. SSL-сертификаты бывают разные. Kaspersky Daily (24 апреля 2018). — «У него [SSL] было несколько версий, но все они в какой-то момент подвергались критике из-за наличия проблем с безопасностью. В итоге была выпущена та версия, которая используется сейчас — ее переименовали в TLS (англ. Transport Layer Security). Однако название SSL прижилось лучше, и новую версию протокола до сих пор часто называют так.» Дата обращения: 19 марта 2020. Архивировано 14 апреля 2020 года.
  2. ↑ 1 2 E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. Архивировано 31 октября 2018 года.
  3. ↑ Walls, Colin. Embedded software (неопр.). — Newnes, 2005. — С. 344. — ISBN 0-7506-7954-9. Архивировано 2 апреля 2023 года.
  4. ↑ E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. Архивировано 31 октября 2018 года.
  5. ↑ E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. Архивировано 31 октября 2018 года.
  6. ↑ 1 2 Tim Dierks <tim@dierks.org>. The Transport Layer Security (TLS) Protocol Version 1.2 (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. Архивировано 24 декабря 2017 года.
  7. ↑ E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. Архивировано 31 октября 2018 года.
  8. ↑ Aboba, Bernard, Simon, Dan. PPP EAP TLS Authentication Protocol (англ.). buildbot.tools.ietf.org. Дата обращения: 25 декабря 2017. Архивировано 1 октября 2020 года.
  9. ↑ Shbair et al, 2015, pp. 990–995.
  10. ↑ HTTPS usage statistics on top websites. statoperator.com. Дата обращения: 28 июня 2016. Архивировано из оригинала 9 февраля 2019 года.
  11. ↑ Статистика российского интернета runfo.ru. www.runfo.ru. Дата обращения: 16 февраля 2017. Архивировано 17 февраля 2017 года.
  12. ↑ Solo, David, Housley, Russell, Ford, Warwick. Certificate and CRL Profile (англ.). tools.ietf.org. Дата обращения: 22 декабря 2017. Архивировано 7 июля 2017 года.
  13. ↑ E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 22 декабря 2017. Архивировано 31 октября 2018 года.
  14. ↑ Tim Dierks <tim@dierks.org>. The Transport Layer Security (TLS) Protocol Version 1.2 (англ.). tools.ietf.org. Дата обращения: 22 декабря 2017. Архивировано 24 декабря 2017 года.
  15. ↑ "How to Deploy HTTPS Correctly". Electronic Frontier Foundation (англ.). 2010-11-15. Архивировано 10 октября 2018. Дата обращения: 23 декабря 2017.
  16. ↑ Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow (англ.) // Microsoft Research. — 2010-05-01. Архивировано 16 марта 2022 года.
  17. ↑ 1 2 Callegati et al, 2009, с. 78.

Литература

[править | править код]
Источник — https://ru.wikipedia.org/w/index.php?title=HTTPS&oldid=140973280