HTTPS

Протокол передачи гипертекста Secure (HTTPS) - это расширение протокола передачи гипертекста (HTTP). Он используется для безопасной связи по компьютерной сети и широко используется в Интернете. В HTTPS протокол связи шифруется с использованием Transport Layer Security (TLS) или, ранее, Secure Sockets Layer (SSL). Поэтому протокол также называют HTTP over TLS[3] или HTTP over SSL.

Основными мотивами использования HTTPS являются аутентификация веб-сайта, к которому осуществляется доступ, а также защита конфиденциальности и целостности передаваемых данных во время их передачи. Он защищает от атак "человек посередине", а двунаправленное шифрование сообщений между клиентом и сервером защищает их от подслушивания и фальсификации.[4][5] Аспект аутентификации HTTPS требует, чтобы доверенная третья сторона подписывала цифровые сертификаты на стороне сервера. Исторически это была дорогостоящая операция, а это означало, что полностью аутентифицированные HTTPS-соединения обычно можно было найти только в защищенных службах платежных транзакций и других защищенных корпоративных информационных системах во Всемирной паутине. В 2016 году кампания Фонда Electronic Frontier Foundation при поддержке разработчиков веб-браузеров привела к тому, что протокол стал более распространенным.[6] HTTPS в настоящее время используется веб-пользователями чаще, чем оригинальный небезопасный HTTP, в первую очередь для защиты подлинности страниц на всех типах веб-сайтов; защиты учетных записей; а также для обеспечения конфиденциальности сообщений пользователей, идентификации и просмотра веб-страниц.

Обзор

Дополнительная информация: Безопасность транспортного уровня

Схема Uniform Resource Identifier (URI) HTTPS имеет идентичный синтаксис использования со схемой HTTP. Однако HTTPS сигнализирует браузеру использовать дополнительный уровень шифрования SSL/TLS для защиты трафика. SSL/TLS особенно подходит для HTTP, так как он может обеспечить некоторую защиту, даже если аутентифицирована только одна сторона связи. Это относится к HTTP-транзакциям через Интернет, где обычно аутентифицируется только сервер (клиент проверяет сертификат сервера).

HTTPS создает безопасный канал в небезопасной сети. Это обеспечивает разумную защиту от подслушивающих устройств и атак "человек посередине" при условии использования адекватных наборов шифров и проверки сертификата сервера.

Поскольку HTTPS полностью заменяет HTTP поверх TLS, весь базовый протокол HTTP может быть зашифрован. Это включает в себя URL-адрес запроса (какая конкретная веб-страница была запрошена), параметры запроса, заголовки и файлы cookie (которые часто содержат идентифицирующую информацию о пользователе). Однако, поскольку адреса веб-сайтов и номера портов обязательно являются частью базовых протоколов TCP/IP, HTTPS не может защитить их раскрытие. На практике это означает, что даже на правильно настроенном веб-сервере подслушивающие устройства могут вывести IP-адрес и номер порта веб-сервера, а иногда даже доменное имя (например, www.example.org, но не остальная часть URL-адреса), с которым общается пользователь, а также объем передаваемых данных и продолжительность общения, но не содержание общения.

Веб-браузеры знают, как доверять HTTPS-сайтам на основе центров сертификации, которые предустановлены в их программном обеспечении. Таким образом, создатели веб-браузеров доверяют центрам сертификации предоставлять действительные сертификаты. Таким образом, пользователь должен доверять HTTPS-соединению с веб-сайтом тогда и только тогда, когда все нижеперечисленное верно:

• Пользователь верит, что программное обеспечение браузера правильно реализует HTTPS с правильно предустановленными центрами сертификации.
• Пользователь доверяет центру сертификации ручаться только за законные веб-сайты.
• Веб-сайт предоставляет действительный сертификат, что означает, что он был подписан доверенным органом.
• Сертификат правильно идентифицирует веб-сайт (например, когда браузер посещает "https://example.com", полученный сертификат надлежащим образом для "example.com" а не какая-то другая сущность).
• Пользователь верит, что уровень шифрования протокола (SSL/TLS) достаточно защищен от подслушивающих устройств.

HTTPS особенно важен в небезопасных сетях и сетях, которые могут быть подвержены несанкционированному доступу. Небезопасные сети, такие как общедоступные точки доступа Wi-Fi, позволяют любому пользователю одной локальной сети перехватывать пакеты и обнаруживать конфиденциальную информацию, не защищенную HTTPS. Кроме того, в некоторых бесплатных и платных сетях WLAN наблюдалось вмешательство в работу веб-страниц путем внедрения пакетов для показа собственной рекламы на других веб-сайтах. Эта практика может быть злонамеренно использована многими способами, например, путем внедрения вредоносных программ на веб-страницы и кражи личной информации пользователей.

HTTPS также важен для соединений по сети Tor, поскольку вредоносные узлы Tor могут в противном случае повредить или изменить содержимое, проходящее через них небезопасным образом, и внедрить вредоносное ПО в соединение. Это одна из причин, почему Electronic Frontier Foundation и проект Tor начали разработку HTTPS Everywhere[4], который включен в Tor Browser[8].

По мере того как появляется все больше информации о глобальной массовой слежке и преступниках, крадущих личную информацию, использование HTTPS-безопасности на всех веб-сайтах становится все более важным, независимо от типа используемого интернет-соединения.[9][10] Несмотря на то, что метаданные об отдельных страницах, посещаемых пользователем, могут не считаться конфиденциальными, при агрегировании они могут многое рассказать о пользователе и поставить под угрозу его конфиденциальность..

Развертывание HTTPS также позволяет использовать HTTP/2 (или его предшественник, ныне устаревший протокол SPDY), который представляет собой новое поколение HTTP, предназначенное для сокращения времени загрузки страницы, ее размера и задержки.

Рекомендуется использовать HTTP Strict Transport Security (HSTS) с HTTPS для защиты пользователей от атак man-in-the-middle, особенно SSL-зачистки.

HTTPS не следует путать с редко используемым безопасным HTTP (S-HTTP), указанным в RFC 2660.

Использование на веб-сайтах

По состоянию на апрель 2018 года, 33,2% сайтов Alexa top 1,000,000 используют HTTPS по умолчанию, 57,1% из 137 971 самых популярных сайтов Интернета имеют безопасную реализацию HTTPS,[16] и 70% загрузки страниц (измеренных телеметрией Firefox) используют HTTPS.]

Интеграция с браузером

Большинство браузеров отображают предупреждение, если они получают недействительный сертификат. Старые браузеры при подключении к сайту с недействительным сертификатом представляли пользователю диалоговое окно с вопросом, хотят ли они продолжить работу. Более новые браузеры отображают предупреждение по всему окну. Более новые браузеры также заметно отображают информацию о безопасности сайта в адресной строке. Расширенные сертификаты проверки показывают юридическое лицо в информации сертификата. Большинство браузеров также отображают предупреждение пользователю при посещении сайта, содержащего смесь зашифрованного и незашифрованного контента. Кроме того, многие веб-фильтры возвращают предупреждение о безопасности при посещении запрещенных веб-сайтов.

Фонд Electronic Frontier Foundation, полагая, что "В идеальном мире каждый веб-запрос может быть по умолчанию HTTPS", предоставил надстройку под названием HTTPS Everywhere для Mozilla Firefox, Google Chrome, Chromium и Android, которая включает HTTPS по умолчанию для сотен часто используемых веб-сайтов.

Принуждение веб-браузера загружать только HTTPS-контент поддерживалось в Firefox начиная с версии 83. Начиная с версии 94, Google Chrome может "всегда использовать безопасные соединения", если он включен в настройках браузера.

Безопасность

Основная статья: Безопасность транспортного уровня § Безопасность

Безопасность HTTPS аналогична безопасности базового протокола TLS, который обычно использует долгосрочные открытые и закрытые ключи для генерации краткосрочного сеансового ключа, который затем используется для шифрования потока данных между клиентом и сервером. Сертификаты X. 509 используются для аутентификации сервера (а иногда и клиента). Как следствие, центры сертификации и сертификаты открытых ключей необходимы для проверки связи между сертификатом и его владельцем, а также для создания, подписания и администрирования действительности сертификатов. Хотя это может быть более выгодным, чем проверке личности через сеть доверия, в 2013 массовой слежки, раскрытия обратил внимание на сертификат органами как потенциальное слабое место, позволяющее человек-в-середине атак. важным в этом контексте является прямая секретность, которая гарантирует, что зашифрованные сообщения, записанные в прошлом, не может быть получен и расшифрован должен долгосрочный секретные ключи или пароли будут скомпрометированы в будущем. Не все веб-серверы обеспечивают прямую секретность.

Чтобы HTTPS был эффективным, сайт должен быть полностью размещен по протоколу HTTPS. Если часть содержимого сайта загружается по протоколу HTTP (например, скрипты или изображения) или если только определенная страница, содержащая конфиденциальную информацию, например страница входа в систему, загружается по протоколу HTTPS, в то время как остальная часть сайта загружается по обычному протоколу HTTP, пользователь будет уязвим. к атакам и слежке. Кроме того, файлы cookie на сайте, обслуживаемом по протоколу HTTPS, должны иметь включенный атрибут secure. На сайте, содержащем конфиденциальную информацию, пользователь и сеанс будут подвергаться воздействию каждый раз, когда доступ к этому сайту осуществляется по протоколу HTTP вместо HTTPS.

Технические

Отличие от HTTP

URL-адреса HTTPS начинаются с "https://" и по умолчанию используют порт 443, тогда как URL-адреса HTTP начинаются с "http://" и по умолчанию используют порт 80.

HTTP не шифруется и поэтому уязвим для атак типа "человек посередине" и "подслушивание", которые могут позволить злоумышленникам получить доступ к учетным записям веб-сайтов и конфиденциальной информации, а также изменить веб-страницы для внедрения вредоносных программ или рекламы. HTTPS предназначен для противостояния таким атакам и считается защищенным от них (за исключением реализаций HTTPS, использующих устаревшие версии SSL).

Сетевые уровни

HTTP работает на самом высоком уровне модели TCP/IP—прикладном уровне; как и протокол безопасности TLS (работающий как нижний подуровень того же уровня), который шифрует HTTP-сообщение перед передачей и расшифровывает сообщение по прибытии. Строго говоря, HTTPS не является отдельным протоколом, а относится к использованию обычного HTTP через зашифрованное соединение SSL/TLS.

HTTPS шифрует все содержимое сообщения, включая заголовки HTTP и данные запроса/ответа. За исключением возможной криптографической атаки CCA, описанной в разделе "Ограничения" ниже, злоумышленник должен в лучшем случае обнаружить, что между двумя сторонами происходит соединение, а также их доменные имена и IP-адреса.

Настройка сервера

Чтобы подготовить веб-сервер к принятию HTTPS-соединений, администратор должен создать сертификат открытого ключа для веб-сервера. Этот сертификат должен быть подписан доверенным центром сертификации, чтобы веб-браузер мог принять его без предупреждения. Центр удостоверяет, что владелец сертификата является оператором веб-сервера, который его предоставляет. Веб - браузеры обычно распространяются со списком подписывающих сертификатов основных центров сертификации, чтобы они могли проверять подписанные ими сертификаты.

Получение сертификатов

Существует ряд коммерческих центров сертификации, предлагающих платные сертификаты SSL/TLS различных типов, включая расширенные сертификаты проверки.

Let's Encrypt, запущенная в апреле 2016 года, предоставляет бесплатный и автоматизированный сервис, который доставляет базовые сертификаты SSL/TLS на веб-сайты. По данным Electronic Frontier Foundation, Let's Encrypt сделает переход с HTTP на HTTPS "таким же простым, как выдача одной команды или нажатие одной кнопки". Большинство веб-хостингов и облачных провайдеров теперь используют Let's Encrypt, предоставляя своим клиентам бесплатные сертификаты.

Использование в качестве контроля доступа

Система также может использоваться для аутентификации клиентов, чтобы ограничить доступ к веб-серверу авторизованным пользователям. Для этого администратор сайта обычно создает сертификат для каждого пользователя, который пользователь загружает в свой браузер. Обычно сертификат содержит имя и адрес электронной почты авторизованного пользователя и автоматически проверяется сервером при каждом подключении для проверки личности пользователя, потенциально даже не требуя пароля.

В случае компрометации секретного (закрытого) ключа

Важным свойством в этом контексте является совершенная форвардная секретность (PFS). Обладание одним из долгосрочных асимметричных секретных ключей, используемых для установления сеанса HTTPS, не должно облегчать получение краткосрочного ключа сеанса для последующей расшифровки разговора, даже в более позднее время. Обмен ключами Диффи–Хеллмана (DHE) и эллиптическая кривая обмена ключами Диффи–Хеллмана (ECDHE) являются в 2013 году единственными известными схемами, обладающими этим свойством. В 2013 году только 30% сеансов браузеров Firefox, Opera и Chromium использовали его, а почти 0% сеансов Safari и Microsoft Internet Explorer от Apple. TLS 1.3, опубликованный в августе 2018 года, отказался от поддержки шифров без прямой секретности. По состоянию на февраль 2020 % опрошенных веб-серверов поддерживают ту или иную форму прямой секретности, а 52,1% будут использовать прямую секретность в большинстве браузеров.

Отзыв сертификата

Сертификат может быть отозван до истечения срока его действия, например, из-за нарушения секретности закрытого ключа. Более новые версии популярных браузеров, таких как Firefox, Opera, и Internet Explorer в Windows Vista, реализуют протокол состояния онлайн-сертификата (OCSP), чтобы убедиться, что это не так. Браузер отправляет серийный номер сертификата центру сертификации или его делегату через OCSP (Online Certificate Status Protocol), и центр сертификации отвечает, сообщая браузеру, является ли сертификат все еще действительным или нет. CRL, чтобы сообщить людям, что эти сертификаты аннулированы. CRL больше не требуются CA/Browser forum, тем не менее, они все еще широко используются CAs. Большинство статусов отзыва в Интернете исчезают вскоре после истечения срока действия сертификатов.

Ограничения

Шифрование SSL (Secure Sockets Layer) и TLS (Transport Layer Security) может быть настроено в двух режимах: простом и взаимном. В простом режиме аутентификация выполняется только сервером. Взаимная версия требует, чтобы пользователь установил персональный сертификат клиента в веб - браузере для аутентификации пользователя. В любом случае уровень защиты зависит от правильности реализации программного обеспечения и используемых криптографических алгоритмов.

Протокол SSL/TLS не запретить индексирование сайта с помощью веб-сканер, а в некоторых случаях Ури зашифрованного ресурса можно вывести, зная только перехваченные запрос-ответ размер. это позволяет злоумышленнику получить доступ к открытым текстом (общедоступных статическое содержимое), а зашифрованный текст (зашифрованную версию статического содержимого), что позволяет криптографические атаки.

Поскольку TLS работает на уровне протокола ниже уровня HTTP и не знает протоколов более высокого уровня, серверы TLS могут строго представлять только один сертификат для определенного адреса и комбинации портов.[38] В прошлом это означало, что использовать виртуальный хостинг на основе имен с HTTPS было невозможно. Существует решение под названием Server Name Indication (SNI), которое отправляет имя хоста на сервер перед шифрованием соединения, хотя многие старые браузеры не поддерживают это расширение. Поддержка SNI доступна начиная с Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 и Internet Explorer 7 в Windows Vista.

С архитектурной точки зрения:

• Соединение SSL/TLS управляется первой передней машиной, которая инициирует соединение TLS. Если по каким-либо причинам (маршрутизация, оптимизация трафика и т.д.) Эта передняя машина не является сервером приложений и ей приходится расшифровывать данные, необходимо найти решения для распространения информации аутентификации пользователя или сертификата на сервер приложений, который должен знать, кто будет подключен.
• Для SSL/TLS с взаимной аутентификацией сеанс SSL/TLS управляется первым сервером, инициирующим соединение. В ситуациях, когда шифрование должно распространяться по цепочке серверов, управление тайм-аутом сеанса становится чрезвычайно сложным для реализации.
• Безопасность максимальна при взаимном SSL/TLS, но на стороне клиента нет никакого способа правильно завершить соединение SSL/TLS и отключить пользователя, кроме как дождаться истечения срока действия сеанса сервера или закрыть все связанные клиентские приложения.

Сложный тип атаки man-in-the-middle, называемый SSL stripping, был представлен на конференции Blackhat 2009 года. Этот тип атаки разрушает безопасность, обеспечиваемую HTTPS, изменяя https:ссылку на http:ссылку, используя тот факт, что немногие интернет-пользователи фактически вводят "https" в интерфейс своего браузера: они попадают на защищенный сайт, нажав на ссылку, и таким образом обманываются, думая, что они используют HTTPS когда на самом деле они используют HTTP. Затем злоумышленник общается с клиентом в открытом виде[42]. Это побудило к разработке контрмеры в HTTP под названием HTTP Strict Transport Security.

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

Тот факт, что большинство современных веб-сайтов, включая Google, Yahoo! и Amazon, используют HTTPS, вызывает проблемы у многих пользователей, пытающихся получить доступ к общедоступным точкам доступа Wi-Fi, поскольку страница входа в горячую точку Wi-Fi не загружается, если пользователь пытается открыть ресурс HTTPS. Несколько веб-сайтов, таких как neverssl.com и nonhttps.com, гарантируют, что они всегда будут оставаться доступными по HTTP. История

Netscape Communications создала HTTPS в 1994 году для своего веб-браузера Netscape Navigator. Первоначально HTTPS использовался с протоколом SSL. Когда SSL превратился в Transport Layer Security (TLS), HTTPS был официально определен RFC 2818 в мае 2000 года. В феврале 2018 года Google объявила, что ее браузер Chrome будет отмечать HTTP-сайты как "Небезопасные" после июля 2018 года. Этот шаг был направлен на то, чтобы побудить владельцев веб-сайтов внедрить HTTPS, чтобы сделать Всемирную паутину более безопасной.

См. также

• Bullrun (decryption program) – секретная антишифровальная программа, управляемая Агентством национальной безопасности США
• Компьютерная безопасность
• HSTS
• Оппортунистическое шифрование
• Станнель

Пруф

datatracker.ietf.org/doc/html/rfc2818

• datatracker.ietf.org/doc/html/rfc5246
• datatracker.ietf.org/doc/html/rfc6101
• howhttps.works/
• istlsfastyet.com/