HTTPS: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
(Показать все непатрулированные изменения)
[непроверенная версия][непроверенная версия]
← Предыдущая правка
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
Нет описания правки
Метки: через визуальный редактор с мобильного устройства из мобильной версии через расширенный мобильный режим
м откат правок 176.59.2.230 по запросу MBH
Метка: откат
 
(не показано 5 промежуточных версий 4 участников)
Строка 28: Строка 28:
Традиционно на одном IP-адресе может работать только один HTTPS-сайт. Для работы нескольких HTTPS-сайтов с различными сертификатами применяется расширение TLS под названием [[Server Name Indication]] (SNI){{sfn|Shbair et al|2015|pp=990–995}}.
Традиционно на одном 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|accessdate=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/|deadlink=yes}}</ref>. HTTPS используется на 4,04 % от общего числа зарегистрированных российских доменов<ref>{{Cite web|url=https://www.runfo.ru/statistika-rossijskogo-interneta|title=Статистика российского интернета runfo.ru|publisher=www.runfo.ru|lang=ru|accessdate=2017-02-16|archive-date=2017-02-17|archive-url=https://web.archive.org/web/20170217071726/https://www.runfo.ru/statistika-rossijskogo-interneta|deadlink=no}}</ref>.
На 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|accessdate=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/|deadlink=yes}}</ref>. HTTPS используется на 4,04 % от общего числа зарегистрированных российских доменов<ref>{{Cite web|url=https://www.runfo.ru/statistika-rossijskogo-interneta|title=Статистика российского интернета runfo.ru|publisher=www.runfo.ru|lang=ru|accessdate=2017-02-16|archive-date=2017-02-17|archive-url=https://web.archive.org/web/20170217071726/https://www.runfo.ru/statistika-rossijskogo-interneta|deadlink=no}}</ref>.


== Идентификация в HTTPS ==
== Идентификация в 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|accessdate=2017-12-22|archive-date=2017-07-07|archive-url=https://web.archive.org/web/20170707150516/https://tools.ietf.org/html//rfc2459|deadlink=no}}</ref>.
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|accessdate=2017-12-22|archive-date=2017-07-07|archive-url=https://web.archive.org/web/20170707150516/https://tools.ietf.org/html//rfc2459|deadlink=no}}</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|accessdate=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|deadlink=no}}</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|accessdate=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|deadlink=no}}</ref>.
Строка 41: Строка 41:


=== Совместное использование HTTP и HTTPS ===
=== Совместное использование 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|accessdate=2017-12-23|language=en|archivedate=2018-10-10|archiveurl=https://web.archive.org/web/20181010233702/https://www.eff.org/https-everywhere/deploying-https}}</ref>.
Когда сайты используют смешанную функциональность 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|accessdate=2017-12-23|language=en|archivedate=2018-10-10|archiveurl=https://web.archive.org/web/20181010233702/https://www.eff.org/https-everywhere/deploying-https}}</ref>.


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

Текущая версия от 15:07, 1 октября 2024

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].

Совместное использование 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=140516892