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) используют HTTPS. [16] По состоянию на декабрь 2022 года 58,4% из 135 422 самых популярных веб-сайтов в Интернете имеют безопасную реализацию HTTPS. [17] Однако, несмотря на выпуск TLS 1.3 в 2018 году, внедрение шло медленно, и многие все еще используют более старую версию. Протокол TLS 1.2. [18]

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

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

Фонд 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, должен быть включен атрибут Secure . На сайте, на котором есть конфиденциальная информация, пользователь и сеанс будут доступны каждый раз, когда доступ к этому сайту осуществляется по протоколу 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% сеансов Apple Safari и Microsoft Internet Explorer . [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], реализуют протокол статуса онлайн-сертификата (OCSP), чтобы убедиться, что это не так. Браузер отправляет серийный номер сертификата в центр сертификации или его представителю через OCSP (протокол онлайн-статуса сертификата), и центр отвечает, сообщая браузеру, действителен ли сертификат или нет. [35] Центр сертификации может также выдать CRL , чтобы сообщить людям, что эти сертификаты отозваны. CRL больше не требуются форуму CA/Browser, [36] , тем не менее, они по-прежнему широко используются центрами сертификации. Большинство статусов отзыва в Интернете исчезают вскоре после истечения срока действия сертификатов. [37]

Ограничения

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

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

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

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

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

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

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

История

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

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

Рекомендации

  1. ^ «Защитите свой сайт с помощью HTTPS» . Поддержка Google . Google Inc. Архивировано из оригинала 1 марта 2015 года . Проверено 20 октября 2018 г.
  2. ^ «Что такое HTTPS?». Комодо Калифорния Лимитед . Архивировано из оригинала 12 февраля 2015 года . Проверено 20 октября 2018 г. Протокол передачи гипертекста Secure (HTTPS) — это безопасная версия протокола HTTP [...]{{cite web}}: CS1 maint: неподходящий URL ( ссылка )
  3. ^ "Схема https URI" . HTTP-семантика. IETF . Июнь 2022. сек. 4.2.2. дои : 10.17487/RFC9110 . РФК 9110.
  4. ^ abc «Часто задаваемые вопросы по HTTPS повсюду» . 8 ноября 2016 г. Архивировано из оригинала 14 ноября 2018 г. . Проверено 20 октября 2018 г.
  5. ^ «Статистика использования протокола https по умолчанию для веб-сайтов, июль 2019 г.» . w3techs.com . Архивировано из оригинала 1 августа 2019 года . Проверено 20 июля 2019 г.
  6. ^ «Шифрование в Интернете». Фонд электронных границ . Архивировано из оригинала 18 ноября 2019 года . Проверено 19 ноября 2019 г.
  7. ^ «Внедрение JavaScript в Wi-Fi в отеле» . ПростоБессонница . 3 апреля 2012 г. Архивировано из оригинала 18 ноября 2018 г. Проверено 20 октября 2018 г.
  8. ^ Проект Tor, Inc. «Что такое браузер Tor?». TorProject.org . Архивировано из оригинала 17 июля 2013 года . Проверено 30 мая 2012 г.
  9. ^ Кенигсбург, Эйтан; Пант, Раджив; Квочко, Елена (13 ноября 2014 г.). «Принятие HTTPS». Нью-Йорк Таймс . Архивировано из оригинала 8 января 2019 года . Проверено 20 октября 2018 г.
  10. Галлахер, Кевин (12 сентября 2014 г.). «Спустя пятнадцать месяцев после разоблачений АНБ, почему больше новостных организаций не используют HTTPS?». Фонд свободы прессы. Архивировано из оригинала 10 августа 2018 года . Проверено 20 октября 2018 г.
  11. ^ «HTTPS как сигнал ранжирования» . Центральный блог Google для веб-мастеров . Google Inc., 6 августа 2014 г. Архивировано из оригинала 17 октября 2018 г. . Проверено 20 октября 2018 г. Вы можете защитить свой сайт с помощью HTTPS (безопасного протокола передачи гипертекста) [...]
  12. ^ Григорик, Илья; Далеко, Пьер (26 июня 2014 г.). «Google I/O 2014 — HTTPS повсюду». Разработчики Google. Архивировано из оригинала 20 ноября 2018 года . Проверено 20 октября 2018 г.
  13. ^ abc «Как правильно развернуть HTTPS». 15 ноября 2010 г. Архивировано из оригинала 10 октября 2018 г. . Проверено 20 октября 2018 г.
  14. ^ «Строгая транспортная безопасность HTTP» . Сеть разработчиков Mozilla . Архивировано из оригинала 19 октября 2018 года . Проверено 20 октября 2018 г.
  15. ^ «Статистика использования HTTPS на 1 млн лучших веб-сайтов» . StatOperator.com . Архивировано из оригинала 9 февраля 2019 года . Проверено 20 октября 2018 г.
  16. ^ «Давайте зашифруем статистику». LetsEncrypt.org . Архивировано из оригинала 19 октября 2018 года . Проверено 20 октября 2018 г.
  17. ^ «Лаборатория Qualys SSL — SSL Pulse» . www.ssllabs.com . 4 декабря 2022 года. Архивировано из оригинала 7 декабря 2022 года . Проверено 7 декабря 2022 г..
  18. ^ «TLS 1.3: Медленное внедрение более надежного веб-шифрования расширяет возможности злодеев» . Помогите Net Security . 6 апреля 2020 года. Архивировано из оригинала 24 мая 2022 года . Проверено 23 мая 2022 г.
  19. Экерсли, Питер (17 июня 2010 г.). «Зашифруйте Интернет с помощью расширения HTTPS Everywhere Firefox». Блог ЭФФ . Архивировано из оригинала 25 ноября 2018 года . Проверено 20 октября 2018 г.
  20. ^ «HTTPS везде» . Проекты ЭФФ . 7 октября 2011 года. Архивировано из оригинала 5 июня 2011 года . Проверено 20 октября 2018 г.
  21. ^ «Режим только HTTPS в Firefox» . Архивировано из оригинала 12 ноября 2021 года . Проверено 12 ноября 2021 г.
  22. ^ «Управление безопасностью Chrome – Android – Справка Google Chrome» . support.google.com . Архивировано из оригинала 7 марта 2022 года . Проверено 7 марта 2022 г.
  23. ^ «Практическое знакомство с первым режимом HTTPS в Chrome» . Техдоус . 19 июля 2021 года. Архивировано из оригинала 7 марта 2022 года . Проверено 7 марта 2022 г.
  24. Сингел, Райан (24 марта 2010 г.). «Устройство правоохранительных органов подрывает SSL». Проводной . Архивировано из оригинала 17 января 2019 года . Проверено 20 октября 2018 г.
  25. Шон, Сет (24 марта 2010 г.). «Новое исследование предполагает, что правительства могут подделывать сертификаты SSL». ЭФФ . Архивировано из оригинала 4 января 2016 года . Проверено 20 октября 2018 г.
  26. ↑ Аб Дункан, Роберт (25 июня 2013 г.). «SSL: перехвачено сегодня, расшифровано завтра». Неткрафт . Архивировано из оригинала 6 октября 2018 года . Проверено 20 октября 2018 г.
  27. Чимпану, Каталин (12 апреля 2016 г.). «Запущенная сегодня программа Let's Encrypt в настоящее время защищает 3,8 миллиона доменов». Новости Софтпедии. Архивировано из оригинала 9 февраля 2019 года . Проверено 20 октября 2018 г.
  28. Кернер, Шон Майкл (18 ноября 2014 г.). «Давайте зашифруем усилия, направленные на повышение безопасности в Интернете». eWeek.com . Квинстрит Энтерпрайз. Архивировано из оригинала 2 апреля 2023 года . Проверено 20 октября 2018 г.
  29. Экерсли, Питер (18 ноября 2014 г.). «Запуск в 2015 году: центр сертификации для шифрования всей сети». Фонд электронных границ . Архивировано из оригинала 18 ноября 2018 года . Проверено 20 октября 2018 г.
  30. ^ Лаборатории Qualys SSL . «SSL Пульс». Архивировано из оригинала (3 февраля 2019 г.) 15 февраля 2019 г. . Проверено 25 февраля 2019 г.
  31. ^ «Лаборатория Qualys SSL — SSL Pulse» . www.ssllabs.com . Проверено 4 сентября 2023 г.
  32. ^ «Политика конфиденциальности Mozilla Firefox» . Фонд Мозилла . 27 апреля 2009 г. Архивировано из оригинала 18 октября 2018 г. Проверено 20 октября 2018 г.
  33. ^ «Opera 8 запущена на FTP» . Софтпедия . 19 апреля 2005 г. Архивировано из оригинала 9 февраля 2019 г. Проверено 20 октября 2018 г.
  34. Лоуренс, Эрик (31 января 2006 г.). «Улучшения безопасности HTTPS в Internet Explorer 7». Документы Майкрософт . Архивировано из оригинала 24 октября 2021 года . Проверено 24 октября 2021 г.
  35. ^ Майерс, Майкл; Анкни, Рич; Мальпани, Амбариш; Гальперин, Слава; Адамс, Карлайл (20 июня 1999 г.). «Протокол статуса онлайн-сертификата – OCSP». Рабочая группа по интернет-инжинирингу . doi : 10.17487/RFC2560. Архивировано из оригинала 25 августа 2011 года . Проверено 20 октября 2018 г.
  36. ^ «Базовые требования». КАБ Форум. Архивировано из оригинала 20 октября 2014 года . Проверено 1 ноября 2021 г.
  37. ^ Коржицкий, Н.; Карлссон, Н. (30 марта 2021 г.). «Статусы отзыва в Интернете». Пассивное и активное измерение . Конспекты лекций по информатике. Том. 12671. стр. 175–191. дои : 10.1007/978-3-030-72582-2_11. ISBN 978-3-030-72581-5. Проверено 10 января 2024 г.
  38. ^ «Управление клиентскими сертификатами на устройствах Chrome – Справка Chrome для бизнеса и образования» . support.google.com . Архивировано из оригинала 9 февраля 2019 года . Проверено 20 октября 2018 г.
  39. ^ Пусеп, Станислав (31 июля 2008 г.). «Пиратская бухта без SSL» (PDF) . Архивировано (PDF) из оригинала 20 июня 2018 года . Проверено 20 октября 2018 г.
  40. ^ «Надежное шифрование SSL/TLS: часто задаваемые вопросы» . apache.org . Архивировано из оригинала 19 октября 2018 года . Проверено 20 октября 2018 г.
  41. Лоуренс, Эрик (22 октября 2005 г.). «Предстоящие улучшения HTTPS в Internet Explorer 7 Beta 2». Майкрософт . Архивировано из оригинала 20 сентября 2018 года . Проверено 20 октября 2018 г.
  42. ^ «Индикация имени сервера (SNI)» . в голове Эбрагима . 21 февраля 2006 г. Архивировано из оригинала 10 августа 2018 г. Проверено 20 октября 2018 г.
  43. Пьер, Жюльен (19 декабря 2001 г.). «Поддержка браузером указания имени сервера TLS». Багзилла . Фонд Мозилла. Архивировано из оригинала 8 октября 2018 года . Проверено 20 октября 2018 г.
  44. ^ "sslstrip 0.9" . Архивировано из оригинала 20 июня 2018 года . Проверено 20 октября 2018 г.
  45. ^ Шуо Чен; Руй Ван; СяоФэн Ван; Кехуань Чжан (20 мая 2010 г.). «Утечки по боковым каналам в веб-приложениях: реальность сегодня, проблема завтра». Исследования Майкрософт . Симпозиум IEEE по безопасности и конфиденциальности 2010. Архивировано из оригинала 22 июля 2018 года . Проверено 20 октября 2018 г.
  46. Гуай, Мэтью (21 сентября 2017 г.). «Как принудительно открыть страницу входа в общедоступную сеть Wi-Fi». Архивировано из оригинала 10 августа 2018 года . Проверено 20 октября 2018 г.
  47. ^ "НикогдаSSL". Архивировано из оригинала 1 сентября 2018 года . Проверено 20 октября 2018 г.
  48. ^ Уоллс, Колин (2005). Встроенное программное обеспечение: работы. Ньюнес. п. 344. ИСБН 0-7506-7954-9. Архивировано из оригинала 9 февраля 2019 года . Проверено 20 октября 2018 г.
  49. ^ «Безопасная сеть никуда не денется» . Блог Хрома . Архивировано из оригинала 24 апреля 2019 года . Проверено 22 апреля 2019 г.

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