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 использует 443TCP-порт (для незащищённого 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].

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

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

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

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

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

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

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

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

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

• SSL
• OpenSSL
• TLS
• SSH
• HSTS
• SPDY
• SCTP
• Let's Encrypt

• 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.
• F. Callegati, W. Cerroni, M. Ramilli. Man-in-the-Middle Attack to the HTTPS Protocol // IEEE Security Privacy. — 2009. — Январь (т. 7,вып. 1). —С. 78—81. —ISSN1540-7993. —doi:10.1109/MSP.2009.12.
• 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). — 2015. — Май. —doi:10.1109/INM.2015.7140423.

• Появились в 2000 году
• Протоколы прикладного уровня
• Протокол HTTP
• Криптография

• Википедия:Cite web (не указан язык)
• Страницы, использующие волшебные ссылки ISBN
• ПРО:ИТ:Статьи по алфавиту
• ПРО:ИТ:Последняя правка: в прошлом году
• Страницы, использующие волшебные ссылки RFC