✖


Jump to content

HTTPS

Страница защищена ожидающими изменениями
(Перенаправлено с защищенного сервера )

Набор интернет-протоколов
Прикладной уровень
Транспортный уровень
Интернет-слой
Слой связи
HTTP
Методы запроса
Поля заголовка
Коды статуса ответа
Методы безопасного контроля доступа
Уязвимости безопасности

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

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

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

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

[ редактировать ]

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

Сравнение различных типов 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, должен быть включен атрибут Secure . На сайте, на котором есть конфиденциальная информация, пользователь и сеанс будут доступны каждый раз, когда доступ к этому сайту осуществляется по протоколу HTTP вместо HTTPS. [13]

Технический

[ редактировать ]

Отличие от HTTP

[ редактировать ]

HTTPS URL-адреса начинаются с «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] Опера , [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/TLS управляется первым фронтальным компьютером, который инициирует соединение TLS. Если по каким-либо причинам (маршрутизация, оптимизация трафика и т. д.) эта передняя машина не является сервером приложений и ей приходится расшифровывать данные, необходимо найти решение для распространения информации или сертификата аутентификации пользователя на сервер приложений, который должен знать, кто будет подключен. [ нужна ссылка ]
  • Для SSL/TLS с взаимной аутентификацией сеанс SSL/TLS управляется первым сервером, который инициирует соединение. В ситуациях, когда шифрование необходимо распространять по связанным серверам, реализовать управление таймаутом сеанса становится чрезвычайно сложно. [ нужна ссылка ]
  • Безопасность максимальна при взаимном SSL/TLS, но на стороне клиента нет способа правильно завершить соединение SSL/TLS и отключить пользователя, кроме как дождавшись истечения сеанса сервера или закрыв все связанные клиентские приложения. [ нужна ссылка ]

Сложный тип атаки «человек посередине», называемый удалением 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, [47] гарантировать, что они всегда будут доступны по HTTP. [48]

История

[ редактировать ]
Основная статья: Безопасность транспортного уровня § История и развитие

Компания Netscape Communications создала HTTPS в 1994 году для своего веб-браузера Netscape Navigator . [49] Первоначально HTTPS использовался с протоколом SSL . Когда SSL превратился в Transport Layer Security (TLS), HTTPS был официально определен в RFC 2818 в мае 2000 года. В феврале 2018 года Google объявил, что после июля 2018 года его браузер Chrome будет помечать HTTP-сайты как «незащищенные». [50] Этот шаг был направлен на то, чтобы побудить владельцев веб-сайтов внедрить 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. ^ «Схема URI https» . HTTP-семантика . IETF . Июнь 2022. сек. 4.2.2. дои : 10.17487/RFC9110 . РФК 9110 .
  4. ^ Перейти обратно: а б с «Часто задаваемые вопросы по 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. ^ Перейти обратно: а б с «Как правильно развернуть 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 Labs — 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-First в 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 Labs — SSL Pulse» . www.ssllabs.com . Проверено 4 сентября 2023 г.
  32. ^ «Политика конфиденциальности Mozilla Firefox» . Фонд Мозилла . 27 апреля 2009 г. Архивировано из оригинала 18 октября 2018 г. . Проверено 20 октября 2018 г.
  33. ^ «Опера 8 запущена по FTP» . Софтпедия . 19 апреля 2005 г. Архивировано из оригинала 9 февраля 2019 г. . Проверено 20 октября 2018 г.
  34. ^ Лоуренс, Эрик (31 января 2006 г.). «Улучшения безопасности HTTPS в Internet Explorer 7» . Документы Майкрософт . Архивировано из оригинала 24 октября 2021 года . Проверено 24 октября 2021 г.
  35. ^ Майерс, Майкл; Анкни, Рич; Мальпани, Амбариш; Гальперин, Слава; Адамс, Карлайл (20 июня 1999 г.). «Протокол статуса онлайн-сертификата – OCSP» . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC2560 . Архивировано из оригинала 25 августа 2011 года . Проверено 20 октября 2018 г.
  36. ^ «Основные требования» . КАБ Форум. 4 сентября 2013 года. Архивировано из оригинала 20 октября 2014 года . Проверено 1 ноября 2021 г.
  37. ^ Коржицкий Н.; Карлссон, Н. (30 марта 2021 г.). «Статусы отзыва в Интернете». Пассивное и активное измерение . Конспекты лекций по информатике. Том. 12671. стр. 175–191. arXiv : 2102.04288 . дои : 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 г.). «Пиратская бухта без 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» .
  48. ^ «НикогдаSSL» . Архивировано из оригинала 1 сентября 2018 года . Проверено 20 октября 2018 г.
  49. ^ Уоллс, Колин (2005). Встроенное программное обеспечение: работа . Ньюнес. п. 344. ИСБН  0-7506-7954-9 . Архивировано из оригинала 9 февраля 2019 года . Проверено 20 октября 2018 г.
  50. ^ «Безопасная сеть никуда не денется» . Блог Хрома . Архивировано из оригинала 24 апреля 2019 года . Проверено 22 апреля 2019 г.
[ редактировать ]
Викискладе есть медиафайлы, связанные с HTTPS .
  • RFC 8446 : Протокол безопасности транспортного уровня (TLS) версии 1.3.
Retrieved from "https://en.wikipedia.org/w/index.php?title=HTTPS&oldid=1238377953"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: b5a9c65ce922ddd5289b762012c0f192__1722689160
URL1:https://arc.ask3.ru/arc/aa/b5/92/b5a9c65ce922ddd5289b762012c0f192.html
Заголовок, (Title) документа по адресу, URL1:
HTTPS - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)