Страница защищена ожидающими изменениями
Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

Обзор [ править ]

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 с правильно установленными центрами сертификации.
  • Пользователь доверяет центру сертификации ручаться только за легитимные веб-сайты.
  • Веб-сайт предоставляет действующий сертификат, что означает, что он был подписан доверенным центром.
  • Сертификат правильно идентифицирует веб-сайт (например, когда браузер посещает « https://example.com », полученный сертификат предназначен для «example.com», а не для какой-либо другой сущности).
  • Пользователь верит, что уровень шифрования протокола (SSL / TLS) достаточно защищен от перехвата.

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

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

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

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

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

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

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

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

Интеграция с браузером [ править ]

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

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

Безопасность [ править ]

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

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

Технические [ править ]

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

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

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

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

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

Сертификат может быть отозван до истечения срока его действия, например, из-за нарушения секретности закрытого ключа. Более новые версии популярных браузеров, таких как Firefox , [28] Opera , [29] и Internet Explorer в Windows Vista [30], реализуют протокол онлайн-статуса сертификата (OCSP), чтобы убедиться, что это не так. Браузер отправляет серийный номер сертификата центру сертификации или его представителю через OCSP (Online Certificate Status Protocol), и центр отвечает, сообщая браузеру, действителен ли сертификат или нет. [31] ЦС также может выдавать CRL. чтобы сообщить людям, что эти сертификаты отозваны.

Ограничения [ править ]

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

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

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

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

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

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

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

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

История [ править ]

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

См. Также [ править ]

  • Bullrun (программа дешифрования)  - секретная программа защиты от шифрования, управляемая Агентством национальной безопасности США.
  • Компьютерная безопасность
  • HSTS
  • HTTPsec
  • Мокси Марлинспайк
  • Оппортунистическое шифрование
  • Stunnel

Ссылки [ править ]

  1. ^ «Защитите свой сайт с помощью HTTPS» . Служба поддержки Google . Google Inc. Архивировано 01 марта 2015 года . Проверено 20 октября 2018 .
  2. ^ "Что такое HTTPS?" . Comodo CA Limited . Архивировано 12 февраля 2015 года . Проверено 20 октября 2018 . Защищенный протокол передачи гипертекста (HTTPS) - это безопасная версия HTTP [...]
  3. ^ Сетевая рабочая группа (май 2000 г.). «HTTP через TLS» . Инженерная группа Интернета. Архивировано 31 октября 2018 года . Проверено 20 октября 2018 .
  4. ^ a b c "Часто задаваемые вопросы о HTTPS везде" . 2016-11-08. Архивировано 14 ноября 2018 года . Проверено 20 октября 2018 .
  5. ^ «Статистика использования протокола https по умолчанию для веб-сайтов, июль 2019 г.» . w3techs.com . Архивировано 1 августа 2019 года . Проверено 20 июля 2019 .
  6. ^ «Шифрование Интернета» . Фонд электронных границ . Архивировано 18 ноября 2019 года . Проверено 19 ноября 2019 .
  7. ^ «HTTP, HTTPS, SSL через TLS» . Ноябрь 2019. Архивировано 13 декабря 2019 года . Проверено 19 ноября 2019 .
  8. ^ "Hotel Wifi JavaScript Injection" . JustInsomnia . 2012-04-03. Архивировано 18 ноября 2018 года . Проверено 20 октября 2018 .
  9. ^ The Tor Project, Inc. "Что такое Tor Browser?" . TorProject.org . Архивировано 17 июля 2013 года . Проверено 30 мая 2012 .
  10. ^ Кенигсбург, Эйтан; Пант, Раджив; Квочко, Елена (13.11.2014). «Использование HTTPS» . Нью-Йорк Таймс . Архивировано 8 января 2019 года . Проверено 20 октября 2018 .
  11. Галлахер, Кевин (12 сентября 2014 г.). «Через пятнадцать месяцев после разоблачений АНБ, почему больше новостных организаций не используют HTTPS?» . Фонд свободы прессы. Архивировано 10 августа 2018 года . Проверено 20 октября 2018 .
  12. ^ «HTTPS как сигнал ранжирования» . Центральный блог Google для веб-мастеров . Google Inc., 6 августа 2014 г. Архивировано 17 октября 2018 года . Проверено 20 октября 2018 . Вы можете защитить свой сайт с помощью HTTPS (безопасный протокол передачи гипертекста) [...]
  13. ^ Grigorik, Илья; Фар, Пьер (2014-06-26). «Google I / O 2014 - HTTPS везде» . Разработчики Google. Архивировано 20 ноября 2018 года . Проверено 20 октября 2018 .
  14. ^ a b c «Как правильно развернуть HTTPS» . 2010-11-15. Архивировано 10 октября 2018 года . Проверено 20 октября 2018 .
  15. ^ «Строгая безопасность транспорта HTTP» . Сеть разработчиков Mozilla . Архивировано 19 октября 2018 года . Проверено 20 октября 2018 .
  16. ^ «Статистика использования HTTPS на 1 млн самых популярных веб-сайтов» . StatOperator.com . Архивировано 9 февраля 2019 года . Проверено 20 октября 2018 .
  17. ^ «Qualys SSL Labs - SSL Pulse» . www.ssllabs.com . 2018-04-03. Архивировано 02 декабря 2017 года . Проверено 20 октября 2018 .
  18. ^ «Давайте зашифровать статистику» . LetsEncrypt.org . Архивировано 19 октября 2018 года . Проверено 20 октября 2018 .
  19. ^ Экерсли, Питер (2010-06-17). «Зашифруйте Интернет с помощью расширения HTTPS Everywhere для Firefox» . Блог EFF . Архивировано 25 ноября 2018 года . Проверено 20 октября 2018 .
  20. ^ "HTTPS везде" . EFF проекты . 2011-10-07. Архивировано 05 июня 2011 года . Проверено 20 октября 2018 .
  21. ^ Сингел, Райан (24 марта 2010 г.). «Устройство правоохранительных органов подрывает SSL» . Проводной . Архивировано 17 января 2019 года . Проверено 20 октября 2018 .
  22. Перейти ↑ Schoen, Seth (24-03-2010). «Новое исследование предполагает, что правительства могут подделывать сертификаты SSL» . ЭФФ . Архивировано 4 января 2016 года . Проверено 20 октября 2018 .
  23. ^ a b Дункан, Роберт (25.06.2013). «SSL: сегодня перехвачено, завтра расшифровано» . Неткрафт . Архивировано 6 октября 2018 года . Проверено 20 октября 2018 .
  24. ^ Cimpanu, Каталин (2016-04-12). «Let's Encrypt, запущенный сегодня, в настоящее время защищает 3,8 миллиона доменов» . Новости Софтпедии. Архивировано 9 февраля 2019 года . Проверено 20 октября 2018 .
  25. ^ Кернер, Шон Майкл (2014-11-18). «Let's Encrypt стремится улучшить безопасность в Интернете» . eWeek.com . Quinstreet Enterprise . Проверено 20 октября 2018 .
  26. ^ Eckersley, Питер (2014-11-18). «Запуск в 2015 году: центр сертификации для шифрования всей сети» . Electronic Frontier Foundation . Архивировано 18 ноября 2018 года . Проверено 20 октября 2018 .
  27. ^ Qualys SSL Labs . «Импульс SSL» . Архивировано из оригинала (3 февраля 2019) 15 февраля 2019 года . Проверено 25 февраля 2019 .
  28. ^ «Политика конфиденциальности Mozilla Firefox» . Mozilla Foundation . 2009-04-27. Архивировано 18 октября 2018 года . Проверено 20 октября 2018 .
  29. ^ "Opera 8 запущена по FTP" . Софтпедия . 2005-04-19. Архивировано 9 февраля 2019 года . Проверено 20 октября 2018 .
  30. ^ Лоуренс, Эрик (31.01.2006). «Улучшения безопасности HTTPS в Internet Explorer 7» . MSDN . Архивировано 20 октября 2018 года . Проверено 20 октября 2018 .
  31. ^ Майерс, Майкл; Анкни, Рич; Мальпани, Амбариш; Гальперин, Слава; Адамс, Карлайл (1999-06-20). «Протокол статуса онлайн-сертификатов - OCSP» . Инженерная группа Интернета . Архивировано 25 августа 2011 года . Проверено 20 октября 2018 .
  32. ^ «Управление сертификатами клиентов на устройствах Chrome - Справка Chrome для бизнеса и образования» . support.google.com . Архивировано 9 февраля 2019 года . Проверено 20 октября 2018 .
  33. ^ Пусеп, Станислав (2008-07-31). "Пиратская бухта без SSL" (PDF) . Архивировано (PDF) из оригинала 20.06.2018 . Проверено 20 октября 2018 .
  34. ^ «Сильное шифрование SSL / TLS: часто задаваемые вопросы» . apache.org . Архивировано 19 октября 2018 года . Проверено 20 октября 2018 .
  35. ^ Лоуренс, Эрик (2005-10-22). «Предстоящие улучшения HTTPS в Internet Explorer 7 Beta 2» . Microsoft . Архивировано 20 сентября 2018 года . Проверено 20 октября 2018 .
  36. ^ «Индикация имени сервера (SNI)» . внутри головы Эбрагима . 21 февраля 2006 г. Архивировано 10 августа 2018 года . Проверено 20 октября 2018 .
  37. ^ Пьер, Жюльен (2001-12-19). «Браузерная поддержка указания имени TLS-сервера» . Bugzilla . Mozilla Foundation. Архивировано 8 октября 2018 года . Проверено 20 октября 2018 .
  38. ^ "sslstrip 0.9" . Архивировано 20 июня 2018 года . Проверено 20 октября 2018 .
  39. ^ Шуо Чен; Руи Ван; Сяофэн Ван; Кехуан Чжан (20.05.2010). «Утечки из побочного канала в веб-приложениях: реальность сегодня, вызов завтра» . Microsoft Research . IEEE Symposium on Security & Privacy 2010. Архивировано 22 июля 2018 года . Проверено 20 октября 2018 .
  40. ^ Guaay, Мэтью (2017-09-21). «Как заставить открыть страницу входа в публичную сеть Wi-Fi» . Архивировано 10 августа 2018 года . Проверено 20 октября 2018 .
  41. ^ "NeverSSL" . Архивировано 01 сентября 2018 года . Проверено 20 октября 2018 .
  42. ^ "веб-сайт, отличный от https" . Архивировано 17 октября 2018 года . Проверено 20 октября 2018 .
  43. Перейти ↑ Walls, Colin (2005). Встроенное программное обеспечение: The Works . Newnes. п. 344. ISBN 0-7506-7954-9. Архивировано 9 февраля 2019 года . Проверено 20 октября 2018 .
  44. ^ "Безопасная сеть никуда не денется" . Блог Chromium . Архивировано 24 апреля 2019 года . Проверено 22 апреля 2019 .

Внешние ссылки [ править ]

  • RFC 2818: HTTP через TLS
  • RFC 5246: Протокол безопасности транспортного уровня 1.2
  • RFC 6101: протокол SSL версии 3.0
  • Как работает HTTPS ... в комиксе!