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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
(Показать все непатрулированные изменения)
[непроверенная версия][непроверенная версия]
← Предыдущая правкаСледующая правка →
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
м убрал лишнее слово, не влияющее на смысл
м откат правок 176.59.2.230 по запросу MBH
Метка: откат
(не показана 21 промежуточная версия 18 участников)
Строка 13: Строка 13:
'''HTTPS''' (аббр. от {{lang-en|HyperText 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/|deadlink=no}}</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|accessdate=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|deadlink=no}}</ref>.
'''HTTPS''' (аббр. от {{lang-en|HyperText 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/|deadlink=no}}</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|accessdate=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|deadlink=no}}</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 |язык=und |автор=Walls, Colin}}</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 |язык=und |автор=Walls, Colin |archivedate=2023-04-02 |archiveurl=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|accessdate=2017-12-25|archive-date=2018-10-31|archive-url=https://web.archive.org/web/20181031095731/https://tools.ietf.org/html/rfc2818#section-2|deadlink=no}}</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|accessdate=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|deadlink=no}}</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|accessdate=2017-12-25|archive-date=2018-10-31|archive-url=https://web.archive.org/web/20181031095731/https://tools.ietf.org/html/rfc2818#section-2|deadlink=no}}</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|accessdate=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|deadlink=no}}</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 <tim@dierks.org>|publisher=tools.ietf.org|lang=en|accessdate=2017-12-25|archive-date=2017-12-24|archive-url=https://web.archive.org/web/20171224222709/https://tools.ietf.org/html/rfc5246|deadlink=no}}</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 <tim@dierks.org>|publisher=tools.ietf.org|lang=en|accessdate=2017-12-25|archive-date=2017-12-24|archive-url=https://web.archive.org/web/20171224222709/https://tools.ietf.org/html/rfc5246|deadlink=no}}</ref>.
Строка 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>.


=== Идентификация клиента ===
=== Идентификация клиента ===
Обычно сервер не располагает информацией о клиенте, достаточной для его идентификации. Однако для обеспечения повышенной защищённости соединения используется так называемая 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 <tim@dierks.org>|publisher=tools.ietf.org|lang=en|accessdate=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|deadlink=no}}</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 <tim@dierks.org>|publisher=tools.ietf.org|lang=en|accessdate=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|deadlink=no}}</ref>.

== Уязвимости HTTPS ==


=== Совместное использование HTTP и HTTPS ===
=== Совместное использование HTTP и HTTPS ===
Когда сайты используют смешанную функциональность HTTP и HTTPS, это потенциально приводит к информационной угрозе для пользователя. Например, если основные страницы некоторого сайта загружаются, используя HTTPS, а [[CSS]] и [[JavaScript]] загружаются по HTTP, то злоумышленник в момент загрузки последних может подгрузить свой код и получить данные HTML-страницы. Многие сайты, несмотря на такие уязвимости, загружают контент через сторонние сервисы, которые не поддерживают HTTPS. Механизм [[HSTS]] позволяет предотвратить подобные уязвимости, заставляя принудительно использовать HTTPS соединение даже там, где по умолчанию используется HTTP<ref>{{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>.


=== Атаки с использованием анализа трафика ===
=== Атаки с использованием анализа трафика ===
{{main|Атака с использованием анализа трафика}}
{{main|Атака с использованием анализа трафика}}
В HTTPS были обнаружены уязвимости, связанные с анализом трафика. Атака с анализом трафика — это тип атаки, при которой выводятся свойства защищённых данных канала путём измерения размера трафика и времени передачи сообщений в нём. Анализ трафика возможен, поскольку шифрование SSL/TLS изменяет содержимое трафика, но оказывает минимальное влияние на размер и время прохождения трафика. В мае 2010 года исследователи из Microsoft Research и Университета Индианы обнаружили, что подробные конфиденциальные пользовательские данные могут быть получены из второстепенных данных, таких, например, как размеры пакетов. Анализатор трафика смог заполучить историю болезней, данные об использовавшихся медикаментах и проведённых операциях пользователя, данные о семейном доходе и пр. Всё это было произведено несмотря на использование HTTPS в нескольких современных веб-приложениях в сфере здравоохранения, налогообложения и других<ref>{{Статья|автор=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|archivedate=2022-03-16|archiveurl=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>.
В 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|archivedate=2022-03-16|archiveurl=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}}.
[[Файл:Mim8989.png|thumb|Рис.1 Стандартная конфигурация сети. Пользователь на хосте клиента (CH) хочет осуществить безопасную транзакцию, но уязвим для атаки «человек в середине».|428x428пкс]]
⚫
{{main|Атака посредника}}При «атаке посредника» используется то, что сервер HTTPS отправляет сертификат с открытым ключом в [[браузер]]. Если этот сертификат не заслуживает доверия, то канал передачи будет уязвимым для атаки злоумышленника. Такая атака заменяет оригинальный сертификат, удостоверяющий HTTPS-сервер, модифицированным сертификатом. Атака проходит успешно, если пользователь пренебрегает двойной проверкой сертификата, когда браузер отправляет предупреждение. Это особенно распространено среди пользователей, которые часто сталкиваются с [[Самозаверенный сертификат|самозаверенными сертификатами]] при доступе к сайтам внутри [[Интранет|сети частных организаций]]{{sfn|Callegati et al|2009|с=78}}.


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


Строка 64: Строка 61:


== См. также ==
== См. также ==
{{Навигация
|Викиучебник = Защита конфиденциальных данных и анонимность в интернете
}}
* [[SSL]]
* [[SSL]]
* [[OpenSSL]]
* [[OpenSSL]]

Версия от 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