HTTPS

Материал из Википедии — свободной энциклопедии
Это старая версия этой страницы, сохранённая Skirienko (обсуждение | вклад) в 14:00, 19 марта 2021 (откат правок Timakodyrov (обс.) к версии InternetArchiveBot). Она может серьёзно отличаться от текущей версии.
Перейти к навигации Перейти к поиску
HTTPS
Название HyperText Transfer Protocol Secure
Уровень (по модели OSI) Прикладной
Семейство TCP/IP
Создан в 2000
Порт/ID 443/TCP
Назначение протокола Безопасное соединение с сервером
Спецификация RFC 2818
Основные реализации (клиенты) веб-браузеры
Основные реализации (серверы) Apache, nginx, IIS
(см. также список веб-серверов)
Логотип Викисклада Медиафайлы на Викискладе

HTTPS (аббр. от англ. HyperText 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].

Уязвимости HTTPS

Совместное использование 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 прижилось лучше, и новую версию протокола до сих пор часто называют так.»
  2. ↑ 1 2 E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017.
  3. ↑ Walls, Colin. Embedded software (неопр.). — Newnes, 2005. — С. 344. — ISBN 0-7506-7954-9.
  4. ↑ E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017.
  5. ↑ E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017.
  6. ↑ 1 2 Tim Dierks <tim@dierks.org>. The Transport Layer Security (TLS) Protocol Version 1.2 (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017.
  7. ↑ E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017.
  8. ↑ Aboba, Bernard, Simon, Dan. PPP EAP TLS Authentication Protocol (англ.). buildbot.tools.ietf.org. Дата обращения: 25 декабря 2017.
  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.
  12. ↑ Solo, David, Housley, Russell, Ford, Warwick. Certificate and CRL Profile (англ.). tools.ietf.org. Дата обращения: 22 декабря 2017.
  13. ↑ E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 22 декабря 2017.
  14. ↑ Tim Dierks <tim@dierks.org>. The Transport Layer Security (TLS) Protocol Version 1.2 (англ.). tools.ietf.org. Дата обращения: 22 декабря 2017.
  15. ↑ "How to Deploy HTTPS Correctly". Electronic Frontier Foundation (англ.). 2010-11-15. Дата обращения: 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.
  17. ↑ 1 2 Callegati et al, 2009, с. 78.

Литература

Источник — https://ru.wikipedia.org/w/index.php?title=HTTPS&oldid=113062420