stringtranslate.com

HTTPS

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

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

Обзор

URL-адрес , начинающийся со схемы HTTPS и метки доменного имени WWW

Схема унифицированного идентификатора ресурса (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), с которым общается пользователь, а также объем переданных данных и продолжительность общения, но не его содержание. [4]

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

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

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

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

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

Рекомендуется использовать HTTP Strict Transport Security (HSTS) с HTTPS для защиты пользователей от атак типа «человек посередине», особенно от взлома SSL . [13] [14]

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

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

По состоянию на апрель 2018 года 33,2% из 1 000 000 веб-сайтов Alexa используют HTTPS по умолчанию [15] и 70% загрузок страниц (измеренных Firefox Telemetry) используют HTTPS. [16] По состоянию на декабрь 2022 года 58,4% из 135 422 самых популярных веб-сайтов Интернета имеют безопасную реализацию HTTPS, [17] Однако, несмотря на выпуск TLS 1.3 в 2018 году, его принятие было медленным, и многие по-прежнему остаются на старом протоколе TLS 1.2. [18]

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

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

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

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

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

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

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

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

Технический

Отличие от 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 года, [27] предоставляет бесплатный и автоматизированный сервис, который предоставляет базовые сертификаты SSL/TLS для веб-сайтов. [28] По данным Electronic Frontier Foundation , Let's Encrypt сделает переключение с HTTP на HTTPS «таким же простым, как ввод одной команды или нажатие одной кнопки». [29] Большинство веб-хостингов и облачных провайдеров теперь используют Let's Encrypt, предоставляя своим клиентам бесплатные сертификаты.

Использовать как контроль доступа

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

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

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

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

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

Ограничения

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

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

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

Изощренный тип атаки типа «человек посередине» , называемый SSL stripping, был представлен на конференции Blackhat 2009 года . Этот тип атаки нарушает безопасность, предоставляемую HTTPS, изменяя https:ссылку на http:ссылку, используя тот факт, что лишь немногие пользователи Интернета на самом деле вводят «https» в интерфейс своего браузера: они попадают на защищенный сайт, нажимая на ссылку, и, таким образом, обманываются, думая, что используют HTTPS, когда на самом деле используют HTTP. Затем злоумышленник открыто общается с клиентом. [44] Это побудило разработать контрмеру в HTTP, называемую HTTP Strict Transport Security . [ требуется цитата ]

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

Тот факт, что большинство современных веб-сайтов, включая Google, Yahoo! и Amazon, используют HTTPS, создает проблемы для многих пользователей, пытающихся получить доступ к общественным точкам доступа Wi-Fi, поскольку страница входа в точку доступа Wi-Fi на портале Captive не загружается, если пользователь пытается открыть ресурс HTTPS. [46] Несколько веб-сайтов, таких как NeverSSL, [47] гарантируют, что они всегда будут доступны по HTTP. [48]

История

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

Смотрите также

Ссылки

  1. ^ "Защитите свой сайт с помощью HTTPS". Поддержка Google . Google Inc. Архивировано из оригинала 1 марта 2015 г. Получено 20 октября 2018 г.
  2. ^ "Что такое HTTPS?". Comodo CA Limited . Архивировано из оригинала 12 февраля 2015 г. Получено 20 октября 2018 г. Hyper Text Transfer Protocol Secure (HTTPS) — это защищенная версия HTTP [...]{{cite web}}: CS1 maint: неподходящий URL ( ссылка )
  3. ^ "https URI Scheme". Семантика HTTP. IETF . Июнь 2022. раздел 4.2.2. doi : 10.17487/RFC9110 . RFC 9110.
  4. ^ abc "HTTPS Everywhere FAQ". 8 ноября 2016 г. Архивировано из оригинала 14 ноября 2018 г. Получено 20 октября 2018 г.
  5. ^ "Статистика использования протокола по умолчанию https для веб-сайтов, июль 2019 г.". w3techs.com . Архивировано из оригинала 1 августа 2019 г. . Получено 20 июля 2019 г. .
  6. ^ "Encrypting the Web". Electronic Frontier Foundation . Архивировано из оригинала 18 ноября 2019 года . Получено 19 ноября 2019 года .
  7. ^ "Hotel Wifi JavaScript Injection". JustInsomnia . 3 апреля 2012 г. Архивировано из оригинала 18 ноября 2018 г. Получено 20 октября 2018 г.
  8. ^ The Tor Project, Inc. "Что такое Tor Browser?". TorProject.org . Архивировано из оригинала 17 июля 2013 г. Получено 30 мая 2012 г.
  9. ^ Konigsburg, Eitan; Pant, Rajiv; Kvochko, Elena (13 ноября 2014 г.). «Embracing HTTPS». The New York Times . Архивировано из оригинала 8 января 2019 г. . Получено 20 октября 2018 г. .
  10. ^ Галлахер, Кевин (12 сентября 2014 г.). «Спустя пятнадцать месяцев после разоблачений АНБ, почему больше новостных организаций не используют HTTPS?». Freedom of the Press Foundation. Архивировано из оригинала 10 августа 2018 г. . Получено 20 октября 2018 г. .
  11. ^ "HTTPS как сигнал ранжирования". Блог Google Webmaster Central . Google Inc. 6 августа 2014 г. Архивировано из оригинала 17 октября 2018 г. Получено 20 октября 2018 г. Вы можете сделать свой сайт безопасным с помощью HTTPS (Hypertext Transfer Protocol Secure) [...]
  12. ^ Григорик, Илья; Фар, Пьер (26 июня 2014 г.). «Google I/O 2014 — HTTPS Everywhere». Разработчики Google. Архивировано из оригинала 20 ноября 2018 г. Получено 20 октября 2018 г.
  13. ^ abc "Как правильно развернуть HTTPS". 15 ноября 2010 г. Архивировано из оригинала 10 октября 2018 г. Получено 20 октября 2018 г.
  14. ^ "HTTP Strict Transport Security". Mozilla Developer Network . Архивировано из оригинала 19 октября 2018 г. Получено 20 октября 2018 г.
  15. ^ "Статистика использования HTTPS на 1 млн. лучших веб-сайтов". StatOperator.com . Архивировано из оригинала 9 февраля 2019 г. . Получено 20 октября 2018 г. .
  16. ^ "Let's Encrypt Stats". LetsEncrypt.org . Архивировано из оригинала 19 октября 2018 г. Получено 20 октября 2018 г.
  17. ^ "Qualys SSL Labs - SSL Pulse". www.ssllabs.com . 4 декабря 2022 г. Архивировано из оригинала 7 декабря 2022 г. Получено 7 декабря 2022 г..
  18. ^ "TLS 1.3: Медленное внедрение более надежного веб-шифрования расширяет возможности плохих парней". Help Net Security . 6 апреля 2020 г. Архивировано из оригинала 24 мая 2022 г. Получено 23 мая 2022 г.
  19. ^ Экерсли, Питер (17 июня 2010 г.). «Зашифруйте Интернет с помощью расширения HTTPS Everywhere Firefox». Блог EFF . Архивировано из оригинала 25 ноября 2018 г. Получено 20 октября 2018 г.
  20. ^ "HTTPS Everywhere". Проекты EFF . 7 октября 2011 г. Архивировано из оригинала 5 июня 2011 г. Получено 20 октября 2018 г.
  21. ^ "HTTPS-Only Mode in Firefox". Архивировано из оригинала 12 ноября 2021 г. Получено 12 ноября 2021 г.
  22. ^ "Управление безопасностью и защитой Chrome - Android - Справка Google Chrome". support.google.com . Архивировано из оригинала 7 марта 2022 г. . Получено 7 марта 2022 г. .
  23. ^ "Hands on Chrome's HTTPS-First Mode". Techdows . 19 июля 2021 г. Архивировано из оригинала 7 марта 2022 г. Получено 7 марта 2022 г.
  24. ^ Singel, Ryan (24 марта 2010 г.). «Law Enforcement Appliance Subverts SSL». Wired . Архивировано из оригинала 17 января 2019 г. Получено 20 октября 2018 г.
  25. ^ Шен, Сет (24 марта 2010 г.). «Новые исследования предполагают, что правительства могут подделывать SSL-сертификаты». EFF . Архивировано из оригинала 4 января 2016 г. Получено 20 октября 2018 г.
  26. ^ ab Duncan, Robert (25 июня 2013 г.). "SSL: перехвачено сегодня, расшифровано завтра". Netcraft . Архивировано из оригинала 6 октября 2018 г. . Получено 20 октября 2018 г. .
  27. ^ Cimpanu, Catalin (12 апреля 2016 г.). «Let's Encrypt запущен сегодня, в настоящее время защищает 3,8 миллиона доменов». Softpedia News. Архивировано из оригинала 9 февраля 2019 г. Получено 20 октября 2018 г.
  28. ^ Кернер, Шон Майкл (18 ноября 2014 г.). «Let's Encrypt Effort Aims to Improve Internet Security». eWeek.com . Quinstreet Enterprise. Архивировано из оригинала 2 апреля 2023 г. Получено 20 октября 2018 г.
  29. ^ Экерсли, Питер (18 ноября 2014 г.). «Запуск в 2015 г.: центр сертификации для шифрования всей сети». Electronic Frontier Foundation . Архивировано из оригинала 18 ноября 2018 г. Получено 20 октября 2018 г.
  30. ^ Qualys SSL Labs . "SSL Pulse". Архивировано из оригинала (3 февраля 2019) 15 февраля 2019. Получено 25 февраля 2019 .
  31. ^ "Qualys SSL Labs - SSL Pulse". www.ssllabs.com . Получено 4 сентября 2023 г. .
  32. ^ "Политика конфиденциальности Mozilla Firefox". Mozilla Foundation . 27 апреля 2009 г. Архивировано из оригинала 18 октября 2018 г. Получено 20 октября 2018 г.
  33. ^ "Opera 8 запущена на FTP". Softpedia . 19 апреля 2005 г. Архивировано из оригинала 9 февраля 2019 г. Получено 20 октября 2018 г.
  34. ^ Лоуренс, Эрик (31 января 2006 г.). «Улучшения безопасности HTTPS в Internet Explorer 7». Microsoft Docs . Архивировано из оригинала 24 октября 2021 г. Получено 24 октября 2021 г.
  35. ^ Майерс, Майкл; Анкни, Рич; Малпани, Амбариш; Гальперин, Слава; Адамс, Карлайл (20 июня 1999 г.). "Протокол статуса сертификата в сети – OCSP". Internet Engineering Task Force . doi :10.17487/RFC2560. Архивировано из оригинала 25 августа 2011 г. . Получено 20 октября 2018 г. .
  36. ^ "Baseline Requirements". Форум CAB. 4 сентября 2013 г. Архивировано из оригинала 20 октября 2014 г. Получено 1 ноября 2021 г.
  37. ^ Коржицкий, Н.; Карлссон, Н. (30 марта 2021 г.). «Статусы отзыва в Интернете». Пассивное и активное измерение . Конспект лекций по информатике. Том 12671. С. 175–191. arXiv : 2102.04288 . doi :10.1007/978-3-030-72582-2_11. ISBN 978-3-030-72581-5.
  38. ^ «Управление клиентскими сертификатами на устройствах Chrome – Справка по Chrome для бизнеса и образования». support.google.com . Архивировано из оригинала 9 февраля 2019 г. . Получено 20 октября 2018 г. .
  39. ^ Пусеп, Станислав (31 июля 2008 г.). "The Pirate Bay un-SSL" (PDF) . Архивировано (PDF) из оригинала 20 июня 2018 г. . Получено 20 октября 2018 г. .
  40. ^ "SSL/TLS Strong Encryption: FAQ". apache.org . Архивировано из оригинала 19 октября 2018 г. Получено 20 октября 2018 г.
  41. ^ Лоуренс, Эрик (22 октября 2005 г.). «Предстоящие улучшения HTTPS в Internet Explorer 7 Beta 2». Microsoft . Архивировано из оригинала 20 сентября 2018 г. . Получено 20 октября 2018 г. .
  42. ^ "Server Name Indication (SNI)". inside aebrahim's head . 21 февраля 2006 г. Архивировано из оригинала 10 августа 2018 г. Получено 20 октября 2018 г.
  43. ^ Пьер, Жюльен (19 декабря 2001 г.). «Поддержка браузера для указания имени сервера TLS». Bugzilla . Mozilla Foundation. Архивировано из оригинала 8 октября 2018 г. . Получено 20 октября 2018 г. .
  44. ^ "sslstrip 0.9". Архивировано из оригинала 20 июня 2018 г. Получено 20 октября 2018 г.
  45. ^ Шуо Чэнь; Руй Ван; Сяофэн Ван; Кэхуань Чжан (20 мая 2010 г.). «Утечки по сторонним каналам в веб-приложениях: реальность сегодня, вызов завтра». Microsoft Research . Симпозиум IEEE по безопасности и конфиденциальности 2010. Архивировано из оригинала 22 июля 2018 г. Получено 20 октября 2018 г.
  46. ^ Guaay, Matthew (21 сентября 2017 г.). «Как принудительно открыть страницу входа в публичную сеть Wi-Fi». Архивировано из оригинала 10 августа 2018 г. Получено 20 октября 2018 г.
  47. ^ «NeverSSL».
  48. ^ "NeverSSL". Архивировано из оригинала 1 сентября 2018 года . Получено 20 октября 2018 года .
  49. ^ Уоллс, Колин (2005). Встроенное программное обеспечение: Работы. Newnes. стр. 344. ISBN 0-7506-7954-9. Архивировано из оригинала 9 февраля 2019 . Получено 20 октября 2018 .
  50. ^ "Безопасный веб здесь, чтобы остаться". Блог Chromium . Архивировано из оригинала 24 апреля 2019 года . Получено 22 апреля 2019 года .

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

На Викискладе есть медиафайлы по теме HTTPS .