HTTPS

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
HTTPS
Название

HyperText Transfer Protocol Secure

Уровень (по модели OSI)

Прикладной

Семейство

TCP/IP

Создан в

2000 г.

Порт/ID

443/TCP

Назначение протокола

Безопасное соединение с сервером

Спецификация

RFC 2818

Основные реализации (клиенты)

веб-браузеры

Основные реализации (серверы)

Apache, nginx, IIS
(см. также список веб-серверов)

HTTP
Постоянное соединение · HTTP pipelining · Сжатие[en] · HTTPS · HTTP/2
Методы
OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT · PATCH
Заголовки
Cookie · ETag · Referer
HTTP location
Do Not Track[en]
X-Forwarded-For[en]
Коды состояния
1xx: Informational
2xx: Success
3xx: Redirection
4xx: Client Error (404 Not Found)
5xx: Server Error

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

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

Принцип работы[править | править код]

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

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

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

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

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

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

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

Идентификация в HTTPS[править | править код]

Идентификация сервера[править | править код]

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

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

Идентификация клиента[править | править код]

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

Уязвимости HTTPS[править | править код]

Совместное использование HTTP и HTTPS[править | править код]

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

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

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

Человек посередине. HTTPS[править | править код]

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

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

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

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

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

См. также[править | править код]

Примечания[править | править код]

  1. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Проверено 25 декабря 2017.
  2. Walls Colin. Embedded software. — Newnes, 2005. — P. 344. — ISBN 0-7506-7954-9.
  3. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Проверено 25 декабря 2017.
  4. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Проверено 25 декабря 2017.
  5. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Проверено 25 декабря 2017.
  6. 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. Tim Dierks <tim@dierks.org>. The Transport Layer Security (TLS) Protocol Version 1.2 (англ.). tools.ietf.org. Проверено 25 декабря 2017.
  10. W. M. Shbair, T. Cholez, A. Goichot, I. Chrisment Efficiently bypassing SNI-based HTTPS filtering // 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM). — May 2015. — С. 990–995. — DOI:10.1109/INM.2015.7140423.
  11. HTTPS usage statistics on top websites. statoperator.com. Проверено 28 июня 2016.
  12. Статистика российского интернета runfo.ru (рус.). www.runfo.ru. Проверено 16 февраля 2017.
  13. Solo, David, Housley, Russell, Ford, Warwick. Certificate and CRL Profile (англ.). tools.ietf.org. Проверено 22 декабря 2017.
  14. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Проверено 22 декабря 2017.
  15. Tim Dierks <tim@dierks.org>. The Transport Layer Security (TLS) Protocol Version 1.2 (англ.). tools.ietf.org. Проверено 22 декабря 2017.
  16. How to Deploy HTTPS Correctly (англ.), Electronic Frontier Foundation (15 November 2010). Проверено 23 декабря 2017.
  17. 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.
  18. 1 2 Callegati et al, 2009, с. 78.

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