imported>EyeBot: автоматическая отмена правки участника 81.195.180.121 - R:1 ORES: 0.9447

2026-03-04T06:35:30Z

автоматическая отмена правки участника 81.195.180.121 - R:1 ORES: 0.9447

Новая страница

{{Карточка протокола
|Аббр = HTTPS
|Название = Hyper Text Transfer Protocol Secure
|Уровень = Прикладной
|Семейство = [[стек протоколов TCP/IP|TCP/IP]]
|Создан = [[2000 год]]у
|Порт = 443/[[TCP]]
|Назначение = Безопасное соединение с сервером
|Спецификация = RFC 2818
|Клиенты = [[браузер|веб-браузеры]]
|Серверы = [[Apache HTTP Server|Apache]], [[nginx]], [[IIS]]
}}
'''HTTPS''' (аббр. от {{lang-en|Hyper Text Transfer Protocol Secure}}) — расширение [[Протокол передачи данных|протокола]] [[HTTP]] для поддержки [[шифрование|шифрования]] в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов [[TLS]] или устаревшего в 2015 году [[SSL]]<ref>{{Cite web|url=https://www.kaspersky.ru/blog/certificates-are-different/20227/|title=SSL-сертификаты бывают разные|author=Ярослава Рябова|website=Kaspersky Daily|quote=У него [SSL] было несколько версий, но все они в какой-то момент подвергались критике из-за наличия проблем с безопасностью. В итоге была выпущена та версия, которая используется сейчас — ее переименовали в TLS (англ. Transport Layer Security). Однако название SSL прижилось лучше, и новую версию протокола до сих пор часто называют так.|date=2018-04-24|publisher=|access-date=2020-03-19|archive-date=2020-04-14|archive-url=https://web.archive.org/web/20200414020604/https://www.kaspersky.ru/blog/certificates-are-different/20227/|url-status=live}}</ref>. В отличие от HTTP с [[TCP]]-[[Порт (TCP/IP)|портом]] 80, для HTTPS по умолчанию используется TCP-порт 443<ref name="автоссылка1">{{Cite web|url=https://tools.ietf.org/html/rfc2818#section-2.3|title=HTTP Over TLS|author=E. Rescorla|publisher=tools.ietf.org|lang=en|access-date=2017-12-25|archive-date=2018-10-31|archive-url=https://web.archive.org/web/20181031095731/https://tools.ietf.org/html/rfc2818#section-2.3|url-status=live}}</ref>.

Протокол был разработан компанией [[Netscape Communications]] для браузера [[Netscape Navigator]] в 1994 году<ref>{{книга |ссылка=https://books.google.com/books?id=FLvsis4_QhEC&pg=PA344 |заглавие=Embedded software |год=2005 |страницы=344 |isbn=0-7506-7954-9 |издательство=Newnes |ref=Walls |язык= |автор=Walls, Colin |archive-date=2023-04-02 |archive-url=https://web.archive.org/web/20230402155024/https://books.google.com/books?id=FLvsis4_QhEC&pg=PA344 }}</ref>.

== Принцип работы ==
HTTPS не является отдельным протоколом. Это обычный [[HTTP]], работающий через шифрованные транспортные механизмы [[SSL]] и [[TLS]]<ref>{{Cite web|url=https://tools.ietf.org/html/rfc2818#section-2|title=HTTP Over TLS|author=E. Rescorla|publisher=tools.ietf.org|lang=en|access-date=2017-12-25|archive-date=2018-10-31|archive-url=https://web.archive.org/web/20181031095731/https://tools.ietf.org/html/rfc2818#section-2|url-status=live}}</ref>. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения — от [[анализатор трафика|снифферских]] атак и атак типа [[человек посередине|man-in-the-middle]], при условии, что будут использоваться шифрующие средства и ''сертификат сервера проверен и ему доверяют''<ref>{{Cite web|url=https://tools.ietf.org/html/rfc2818#section-3.1|title=HTTP Over TLS|author=E. Rescorla|publisher=tools.ietf.org|lang=en|access-date=2017-12-25|archive-date=2018-10-31|archive-url=https://web.archive.org/web/20181031095731/https://tools.ietf.org/html/rfc2818#section-3.1|url-status=live}}</ref>.

По умолчанию HTTPS URL использует 443 [[TCP]]-[[Порт (TCP/IP)|порт]] (для незащищённого HTTP — 80)<ref name="автоссылка1" />. Чтобы подготовить веб-сервер для обработки https-соединений, администратор должен получить и установить в систему сертификат открытого и закрытого ключа для этого веб-сервера. В TLS используется как [[Криптосистема с открытым ключом|асимметричная схема шифрования]] (для выработки общего секретного ключа), так и [[Симметричное шифрование|симметричная]] (для обмена данными, зашифрованными общим ключом). Сертификат открытого ключа подтверждает принадлежность данного открытого ключа владельцу сайта. Сертификат открытого ключа и сам открытый ключ посылаются клиенту при установлении соединения; закрытый ключ используется для расшифровки сообщений от клиента<ref name="автоссылка2">{{Cite web|url=https://tools.ietf.org/html/rfc5246|title=The Transport Layer Security (TLS) Protocol Version 1.2|author=Tim Dierks <>|publisher=tools.ietf.org|lang=en|access-date=2017-12-25|archive-date=2017-12-24|archive-url=https://web.archive.org/web/20171224222709/https://tools.ietf.org/html/rfc5246|url-status=live}}</ref>.

Существует возможность создать такой сертификат, не обращаясь в [[центр сертификации]]. Подписываются такие сертификаты этим же сертификатом и называются [[Самозаверенный сертификат|самоподписанными]] ({{lang-en2|self-signed}}). Без проверки сертификата каким-то другим способом (например, звонок владельцу и проверка контрольной суммы сертификата) такое использование HTTPS подвержено [[Атака посредника|атаке посредника]]<ref>{{Cite web|url=https://tools.ietf.org/html/rfc2818|title=HTTP Over TLS|author=E. Rescorla|publisher=tools.ietf.org|lang=en|access-date=2017-12-25|archive-date=2018-10-31|archive-url=https://web.archive.org/web/20181031095731/https://tools.ietf.org/html/rfc2818|url-status=live}}</ref>.

Эта система также может использоваться для аутентификации клиента, чтобы обеспечить доступ к серверу только [[Авторизованный пользователь|авторизованным пользователям]]. Для этого администратор обычно создаёт сертификаты для каждого пользователя и загружает их в браузер каждого пользователя. Также будут приниматься все сертификаты, подписанные организациями, которым доверяет сервер. Такой сертификат обычно содержит имя и адрес электронной почты авторизованного пользователя, которые проверяются при каждом соединении, чтобы проверить личность пользователя без ввода пароля<ref>{{Cite web|url=https://buildbot.tools.ietf.org/html/rfc2716|title=PPP EAP TLS Authentication Protocol|author=Aboba, Bernard, Simon, Dan|publisher=buildbot.tools.ietf.org|lang=en|access-date=2017-12-25|archive-date=2020-10-01|archive-url=https://web.archive.org/web/20201001135456/http://buildbot.tools.ietf.org/html/rfc2716|url-status=live}}</ref>.

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

Традиционно на одном IP-адресе может работать только один HTTPS-сайт. Для работы нескольких HTTPS-сайтов с различными сертификатами применяется расширение TLS под названием [[Server Name Indication]] (SNI){{sfn|Shbair et al|2015|pp=990–995}}.

На 17 июля 2017 года 22,67 % сайтов из списка «[[Alexa Internet|Alexa]] top 1,000,000» используют протокол HTTPS по умолчанию<ref name="StatOperator">{{cite web|url=https://statoperator.com/research/https-usage-statistics-on-top-websites/|title=HTTPS usage statistics on top websites|author=|website=|date=|publisher=statoperator.com|access-date=2016-06-28|archive-date=2019-02-09|archive-url=https://web.archive.org/web/20190209055130/https://statoperator.com/research/https-usage-statistics-on-top-websites/|url-status=dead}}</ref>. HTTPS используется на 4,04 % от общего числа зарегистрированных российских доменов<ref>{{Cite web|url=https://www.runfo.ru/statistika-rossijskogo-interneta|title=Статистика российского интернета runfo.ru|publisher=www.runfo.ru|lang=ru|access-date=2017-02-16|archive-date=2017-02-17|archive-url=https://web.archive.org/web/20170217071726/https://www.runfo.ru/statistika-rossijskogo-interneta|url-status=live}}</ref>.

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

=== Идентификация сервера ===
HTTP/[[TLS]]-запросы генерируются путём разыменования [[URI]], вследствие чего имя хоста становится известно клиенту. В начале общения сервер посылает клиенту свой сертификат, чтобы клиент идентифицировал его. Это позволяет предотвратить атаку посредника. В сертификате указывается URI сервера. Согласование имени хоста и данных, указанных в сертификате, происходит в соответствии с протоколом RFC2459<ref>{{Cite web|url=https://tools.ietf.org/html/rfc2459|title=Certificate and CRL Profile|author=Solo, David, Housley, Russell, Ford, Warwick|publisher=tools.ietf.org|lang=en|access-date=2017-12-22|archive-date=2017-07-07|archive-url=https://web.archive.org/web/20170707150516/https://tools.ietf.org/html//rfc2459|url-status=live}}</ref>.

Если имя сервера не совпадает с указанным в сертификате, то пользовательские программы, например браузеры, сообщают об этом пользователю. В основном, браузеры предоставляют пользователю выбор: продолжить незащищённое соединение или прервать его<ref>{{Cite web|url=https://tools.ietf.org/html/rfc2818#section-3.1|title=HTTP Over TLS|author=E. Rescorla|publisher=tools.ietf.org|lang=en|access-date=2017-12-22|archive-date=2018-10-31|archive-url=https://web.archive.org/web/20181031095731/https://tools.ietf.org/html/rfc2818#section-3.1|url-status=live}}</ref>.

=== Идентификация клиента ===
Обычно сервер не располагает информацией о клиенте, достаточной для его идентификации. Однако для обеспечения повышенной защищённости соединения используется так называемая «two-way authentication». При этом сервер после подтверждения его сертификата клиентом также запрашивает сертификат. Таким образом, схема подтверждения клиента аналогична идентификации сервера<ref>{{Cite web|url=https://tools.ietf.org/html/rfc5246#section-7.4.6|title=The Transport Layer Security (TLS) Protocol Version 1.2|author=Tim Dierks <>|publisher=tools.ietf.org|lang=en|access-date=2017-12-22|archive-date=2017-12-24|archive-url=https://web.archive.org/web/20171224222709/https://tools.ietf.org/html/rfc5246#section-7.4.6|url-status=live}}</ref>.

=== Совместное использование HTTP и HTTPS ===
Когда сайты используют смешанную функциональность HTTP и HTTPS, это потенциально приводит к информационной угрозе для пользователя. Например, если основные страницы некоторого сайта загружаются, используя HTTPS, а [[CSS]] и [[JavaScript]] загружаются по HTTP, то злоумышленник в момент загрузки последних может подгрузить свой код и получить данные HTML-страницы. Многие сайты, несмотря на такие уязвимости, загружают контент через сторонние сервисы, которые не поддерживают HTTPS. Механизм [[HSTS]] позволяет предотвратить подобные уязвимости, заставляя принудительно использовать HTTPS-соединение даже там, где по умолчанию используется HTTP<ref name="автоссылка3">{{Cite news|title=How to Deploy HTTPS Correctly|url=https://www.eff.org/https-everywhere/deploying-https|work=Electronic Frontier Foundation|date=2010-11-15|access-date=2017-12-23|language=en|archive-date=2018-10-10|archive-url=https://web.archive.org/web/20181010233702/https://www.eff.org/https-everywhere/deploying-https}}</ref>.

=== Атаки с использованием анализа трафика ===
{{main|Атака с использованием анализа трафика}}
В HTTPS были обнаружены уязвимости, связанные с анализом трафика. Атака с анализом трафика — это тип атаки, при которой выводятся свойства защищённых данных канала путём измерения размера трафика и времени передачи сообщений в нём. Анализ трафика возможен, поскольку шифрование SSL/TLS изменяет содержимое трафика, но оказывает минимальное влияние на размер и время прохождения трафика. В мае 2010 года исследователи из Microsoft Research и Университета Индианы обнаружили, что подробные конфиденциальные пользовательские данные могут быть получены из второстепенных данных, таких, например, как размеры пакетов. Анализатор трафика смог заполучить историю болезней, данные об использовавшихся медикаментах и проведённых операциях пользователя, данные о семейном доходе и пр. Всё это было произведено несмотря на использование HTTPS в нескольких современных веб-приложениях в сфере здравоохранения, налогообложения и других<ref name="автоссылка4">{{Статья|автор=Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang|заглавие=Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow|ссылка=https://www.microsoft.com/en-us/research/publication/side-channel-leaks-in-web-applications-a-reality-today-a-challenge-tomorrow/?from=https://research.microsoft.com/pubs/119060/WebAppSideChannel-final.pdf|язык=en-us|издание=Microsoft Research|год=2010-05-01|archive-date=2022-03-16|archive-url=https://web.archive.org/web/20220316030359/https://www.microsoft.com/en-us/research/publication/side-channel-leaks-in-web-applications-a-reality-today-a-challenge-tomorrow/?from=https%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F119060%2FWebAppSideChannel-final.pdf}}</ref>.[[Файл:Mim8989.png|thumb|Рис.1 Стандартная конфигурация сети. Пользователь на хосте клиента (CH) хочет осуществить безопасную транзакцию, но уязвим для атаки «человек в середине».|428x428пкс]]

=== Атака посредника ===
{{main|Атака посредника}}При атаке посредника используется то, что сервер HTTPS отправляет сертификат с открытым ключом в [[браузер]]. Если этот сертификат не заслуживает доверия, то канал передачи будет уязвимым для атаки злоумышленника. Такая атака заменяет оригинальный сертификат, удостоверяющий HTTPS-сервер, модифицированным сертификатом. Атака проходит успешно, если пользователь пренебрегает двойной проверкой сертификата, когда браузер отправляет предупреждение. Это особенно распространено среди пользователей, которые часто сталкиваются с [[Самозаверенный сертификат|самозаверенными сертификатами]] при доступе к сайтам внутри [[Интранет|сети частных организаций]]{{sfn|Callegati et al|2009|с=78}}.

На рис. 1 представлена ситуация, когда злоумышленник является шлюзом между клиентом, осуществляющим безопасную транзакцию, и сервером. Таким образом через злоумышленника проходит весь трафик клиента и он может перенаправить его по своему усмотрению. Здесь делаются следующие шаги:
# Злоумышленник встраивается между клиентом и сервером;
# Пересылает все сообщения от клиента серверу без изменений;
# Перехват сообщений от сервера, посланных по [[Шлюз по умолчанию|шлюзу по умолчанию]];
# Создание самозаверенного сертификата и подмена им сертификата сервера;
# Отправление ложного сертификата клиенту;
# Когда клиент подтвердит сертификат, будут установлены защищённые соединения: между злоумышленником и сервером и другое — между злоумышленником и клиентом.

В итоге такой атаки клиент и сервер думают, что осуществляют безопасное соединение, однако злоумышленник теперь также имеет закрытый ключ и может расшифровать любое сообщение в канале{{sfn|Callegati et al|2009|с=78}}.

== См. также ==
* [[SSL]]
* [[OpenSSL]]
* [[TLS]]
* [[SSH]]
* [[HSTS]]
* [[SPDY]]
* [[SCTP]]
* [[Let's Encrypt]]

== Примечания ==
{{примечания|33em}}

== Литература ==
* {{Статья
|автор = Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang
|заглавие = Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow
|ссылка = https://www.microsoft.com/en-us/research/publication/side-channel-leaks-in-web-applications-a-reality-today-a-challenge-tomorrow/?from=https://research.microsoft.com/pubs/119060/WebAppSideChannel-final.pdf
|язык = en-us
|издание = Microsoft Research
|год = 2010-05-01
|ref = Shuo Chen et al
}}
* {{Статья
|автор = F. Callegati, W. Cerroni, M. Ramilli
|заглавие = Man-in-the-Middle Attack to the HTTPS Protocol
|ссылка = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4768661
|издание = IEEE Security Privacy
|год = 2009
|месяц = January
|том = 7
|выпуск = 1
|страницы = 78—81
|issn = 1540-7993
|doi = 10.1109/MSP.2009.12
|ref = Callegati et al
}}
* {{Статья|автор=W. M. Shbair, T. Cholez, A. Goichot, I. Chrisment|заглавие=Efficiently bypassing SNI-based HTTPS filtering|ссылка=http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7140423|издание=2015 IFIP/IEEE International Symposium on Integrated Network Management (IM)|месяц=May |год=2015|страницы=|doi=10.1109/INM.2015.7140423|ref =Shbair et al}}

{{Внешние ссылки}}

{{URI scheme}}
{{IPstack}}
{{HTTP}}

[[Категория:Протоколы прикладного уровня]]
[[Категория:Протокол HTTP]]
[[Категория:Криптография]]

HTTPS - История изменений

imported>EyeBot: автоматическая отмена правки участника 81.195.180.121 - R:1 ORES: 0.9447