Azərbaycanca AzərbaycancaБеларускі БеларускіDansk DanskDeutsch DeutschEspañola EspañolaFrançais FrançaisIndonesia IndonesiaItaliana Italiana日本語 日本語Қазақ ҚазақLietuvos LietuvosNederlands NederlandsPortuguês PortuguêsРусский Русскийසිංහල සිංහලแบบไทย แบบไทยTürkçe TürkçeУкраїнська Українська中國人 中國人United State United StateAfrikaans Afrikaans
Поддерживать
www.wikidata.ru-ru.nina.az

HTTPS аббр от англ HyperText Transfer Protocol Secure расширение протокола HTTP для поддержки шифрования в целях повышен

HTTPS

HTTPS

HTTPS (аббр. от англ. HyperText Transfer Protocol Secure) — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL. В отличие от HTTP с TCP-(портом) 80, для HTTPS по умолчанию используется TCP-порт 443.

HTTPS
Название HyperText Transfer Protocol Secure
Уровень (по модели OSI) Прикладной
Семейство (TCP/IP)
Создан в 2000
Порт/ID 443/TCP
Назначение протокола Безопасное соединение с сервером
Спецификация RFC 2818
Основные реализации (клиенты) веб-браузеры
Основные реализации (серверы) Apache, nginx, IIS
image Медиафайлы на Викискладе

Протокол был разработан компанией Netscape Communications для браузера Netscape Navigator в 1994 году.

Принцип работы

HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения — от снифферских атак и атак типа man-in-the-middle, при условии, что будут использоваться шифрующие средства и сертификат сервера проверен и ему доверяют.

По умолчанию HTTPS URL использует 443 TCP-(порт) (для незащищённого HTTP — 80). Чтобы подготовить веб-сервер для обработки https-соединений, администратор должен получить и установить в систему сертификат открытого и закрытого ключа для этого веб-сервера. В TLS используется как асимметричная схема шифрования (для выработки общего секретного ключа), так и симметричная (для обмена данными, зашифрованными общим ключом). Сертификат открытого ключа подтверждает принадлежность данного открытого ключа владельцу сайта. Сертификат открытого ключа и сам открытый ключ посылаются клиенту при установлении соединения; закрытый ключ используется для расшифровки сообщений от клиента.

Существует возможность создать такой сертификат, не обращаясь в центр сертификации. Подписываются такие сертификаты этим же сертификатом и называются самоподписанными (self-signed). Без проверки сертификата каким-то другим способом (например, звонок владельцу и проверка контрольной суммы сертификата) такое использование HTTPS подвержено атаке посредника.

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

В HTTPS для шифрования используется длина ключа 40, 56, 128 или 256 бит. Некоторые старые версии браузеров используют длину ключа 40 бит (пример тому — IE версий до 4.0), что связано с экспортными ограничениями в США. Длина ключа 40 бит не является надёжной. Многие современные сайты требуют использования новых версий браузеров, поддерживающих шифрование с длиной ключа 128 бит, с целью обеспечить достаточный уровень безопасности. Шифрование с длиной ключа 128 бит значительно затрудняет подбор паролей и доступ к личной информации.

Традиционно на одном IP-адресе может работать только один HTTPS-сайт. Для работы нескольких HTTPS-сайтов с различными сертификатами применяется расширение TLS под названием Server Name Indication (SNI).

На 17 июля 2017 года, 22,67 % сайтов из списка «Alexa top 1,000,000» используют протокол HTTPS по умолчанию. HTTPS используется на 4,04 % от общего числа зарегистрированных российских доменов.

Идентификация в HTTPS

Идентификация сервера

HTTP/TLS запросы генерируются путём разыменования URI, вследствие чего имя хоста становится известно клиенту. В начале общения, сервер посылает клиенту свой сертификат, чтобы клиент идентифицировал его. Это позволяет предотвратить атаку посредника. В сертификате указывается URI сервера. Согласование имени хоста и данных, указанных в сертификате, происходит в соответствии с протоколом RFC2459.

Если имя сервера не совпадает с указанным в сертификате, то пользовательские программы, например браузеры, сообщают об этом пользователю. В основном, браузеры предоставляют пользователю выбор: продолжить незащищённое соединение или прервать его.

Идентификация клиента

Обычно сервер не располагает информацией о клиенте, достаточной для его идентификации. Однако для обеспечения повышенной защищённости соединения используется так называемая "two-way authentication". При этом сервер после подтверждения его сертификата клиентом также запрашивает сертификат. Таким образом, схема подтверждения клиента аналогична идентификации сервера.

Совместное использование HTTP и HTTPS

Когда сайты используют смешанную функциональность HTTP и HTTPS, это потенциально приводит к информационной угрозе для пользователя. Например, если основные страницы некоторого сайта загружаются, используя HTTPS, а CSS и JavaScript загружаются по HTTP, то злоумышленник в момент загрузки последних может подгрузить свой код и получить данные HTML-страницы. Многие сайты, несмотря на такие уязвимости, загружают контент через сторонние сервисы, которые не поддерживают HTTPS. Механизм HSTS позволяет предотвратить подобные уязвимости, заставляя принудительно использовать HTTPS соединение даже там, где по умолчанию используется HTTP.

Атаки с использованием анализа трафика

Основная статья: Атака с использованием анализа трафика

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

image
Рис.1 Стандартная конфигурация сети. Пользователь на хосте клиента (CH) хочет осуществить безопасную транзакцию, но уязвим для атаки «человек в середине».

Атака посредника

Основная статья: Атака посредника

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

На рис. 1 представлена ситуация, когда злоумышленник является шлюзом между клиентом, осуществляющим безопасную транзакцию, и сервером. Таким образом через злоумышленника проходит весь трафик клиента и он может перенаправить его по своему усмотрению. Здесь делаются следующие шаги:

  1. Злоумышленник встраивается между клиентом и сервером;
  2. Пересылает все сообщения от клиента серверу без изменений;
  3. Перехват сообщений от сервера, посланных по шлюзу по умолчанию;
  4. Создание самозаверенного сертификата и подмена им сертификата сервера;
  5. Отправление ложного сертификата клиенту;
  6. Когда клиент подтвердит сертификат, будут установлены защищённые соединения: между злоумышленником и сервером и другое — между злоумышленником и клиентом.

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

См. также

Примечания

  1. Ярослава Рябова. SSL-сертификаты бывают разные. Kaspersky Daily (24 апреля 2018). — «У него [SSL] было несколько версий, но все они в какой-то момент подвергались критике из-за наличия проблем с безопасностью. В итоге была выпущена та версия, которая используется сейчас — ее переименовали в TLS (англ. Transport Layer Security). Однако название SSL прижилось лучше, и новую версию протокола до сих пор часто называют так.» Дата обращения: 19 марта 2020. 14 апреля 2020 года.
  2. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. 31 октября 2018 года.
  3. Walls, Colin. Embedded software (неопр.). — Newnes, 2005. — С. 344. — . 2 апреля 2023 года.
  4. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. 31 октября 2018 года.
  5. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. 31 октября 2018 года.
  6. Tim Dierks <tim@dierks.org>. The Transport Layer Security (TLS) Protocol Version 1.2 (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. 24 декабря 2017 года.
  7. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 25 декабря 2017. 31 октября 2018 года.
  8. Aboba, Bernard, Simon, Dan. PPP EAP TLS Authentication Protocol (англ.). buildbot.tools.ietf.org. Дата обращения: 25 декабря 2017. 1 октября 2020 года.
  9. Shbair et al, 2015, pp. 990–995.
  10. . statoperator.com. Дата обращения: 28 июня 2016. Архивировано из оригинала 9 февраля 2019 года.
  11. Статистика российского интернета runfo.ru. www.runfo.ru. Дата обращения: 16 февраля 2017. 17 февраля 2017 года.
  12. Solo, David, Housley, Russell, Ford, Warwick. Certificate and CRL Profile (англ.). tools.ietf.org. Дата обращения: 22 декабря 2017. 7 июля 2017 года.
  13. E. Rescorla. HTTP Over TLS (англ.). tools.ietf.org. Дата обращения: 22 декабря 2017. 31 октября 2018 года.
  14. Tim Dierks <tim@dierks.org>. The Transport Layer Security (TLS) Protocol Version 1.2 (англ.). tools.ietf.org. Дата обращения: 22 декабря 2017. 24 декабря 2017 года.
  15. "How to Deploy HTTPS Correctly". Electronic Frontier Foundation (англ.). 2010-11-15. 10 октября 2018. Дата обращения: 23 декабря 2017.
  16. Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow (англ.) // Microsoft Research. — 2010-05-01. 16 марта 2022 года.
  17. Callegati et al, 2009, с. 78.

Литература

  • Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow (англ.) // Microsoft Research. — 2010-05-01.
  • F. Callegati, W. Cerroni, M. Ramilli. Man-in-the-Middle Attack to the HTTPS Protocol // IEEE Security Privacy. — 2009. — Январь (т. 7, вып. 1). — С. 78—81. — ISSN 1540-7993. — doi:10.1109/MSP.2009.12.
  • W. M. Shbair, T. Cholez, A. Goichot, I. Chrisment. Efficiently bypassing SNI-based HTTPS filtering // 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM). — 2015. — Май. — doi:10.1109/INM.2015.7140423.

Википедия, чтение, книга, библиотека, поиск, нажмите, истории, книги, статьи, wikipedia, учить, информация, история, скачать, скачать бесплатно, mp3, видео, mp4, 3gp, jpg, jpeg, gif, png, картинка, музыка, песня, фильм, игра, игры, мобильный, телефон, Android, iOS, apple, мобильный телефон, Samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Сеть, компьютер

HTTPS abbr ot angl HyperText Transfer Protocol Secure rasshirenie protokola HTTP dlya podderzhki shifrovaniya v celyah povysheniya bezopasnosti Dannye v protokole HTTPS peredayutsya poverh kriptograficheskih protokolov TLS ili ustarevshego v 2015 godu SSL V otlichie ot HTTP s TCP portom 80 dlya HTTPS po umolchaniyu ispolzuetsya TCP port 443 HTTPSNazvanie HyperText Transfer Protocol SecureUroven po modeli OSI PrikladnojSemejstvo TCP IPSozdan v 2000Port ID 443 TCPNaznachenie protokola Bezopasnoe soedinenie s serveromSpecifikaciya RFC 2818Osnovnye realizacii klienty veb brauzeryOsnovnye realizacii servery Apache nginx IIS Mediafajly na Vikisklade Protokol byl razrabotan kompaniej Netscape Communications dlya brauzera Netscape Navigator v 1994 godu Princip rabotyHTTPS ne yavlyaetsya otdelnym protokolom Eto obychnyj HTTP rabotayushij cherez shifrovannye transportnye mehanizmy SSL i TLS On obespechivaet zashitu ot atak osnovannyh na proslushivanii setevogo soedineniya ot snifferskih atak i atak tipa man in the middle pri uslovii chto budut ispolzovatsya shifruyushie sredstva i sertifikat servera proveren i emu doveryayut Po umolchaniyu HTTPS URL ispolzuet 443 TCP port dlya nezashishyonnogo HTTP 80 Chtoby podgotovit veb server dlya obrabotki https soedinenij administrator dolzhen poluchit i ustanovit v sistemu sertifikat otkrytogo i zakrytogo klyucha dlya etogo veb servera V TLS ispolzuetsya kak asimmetrichnaya shema shifrovaniya dlya vyrabotki obshego sekretnogo klyucha tak i simmetrichnaya dlya obmena dannymi zashifrovannymi obshim klyuchom Sertifikat otkrytogo klyucha podtverzhdaet prinadlezhnost dannogo otkrytogo klyucha vladelcu sajta Sertifikat otkrytogo klyucha i sam otkrytyj klyuch posylayutsya klientu pri ustanovlenii soedineniya zakrytyj klyuch ispolzuetsya dlya rasshifrovki soobshenij ot klienta Sushestvuet vozmozhnost sozdat takoj sertifikat ne obrashayas v centr sertifikacii Podpisyvayutsya takie sertifikaty etim zhe sertifikatom i nazyvayutsya samopodpisannymi self signed Bez proverki sertifikata kakim to drugim sposobom naprimer zvonok vladelcu i proverka kontrolnoj summy sertifikata takoe ispolzovanie HTTPS podverzheno atake posrednika Eta sistema takzhe mozhet ispolzovatsya dlya autentifikacii klienta chtoby obespechit dostup k serveru tolko avtorizovannym polzovatelyam Dlya etogo administrator obychno sozdayot sertifikaty dlya kazhdogo polzovatelya i zagruzhaet ih v brauzer kazhdogo polzovatelya Takzhe budut prinimatsya vse sertifikaty podpisannye organizaciyami kotorym doveryaet server Takoj sertifikat obychno soderzhit imya i adres elektronnoj pochty avtorizovannogo polzovatelya kotorye proveryayutsya pri kazhdom soedinenii chtoby proverit lichnost polzovatelya bez vvoda parolya V HTTPS dlya shifrovaniya ispolzuetsya dlina klyucha 40 56 128 ili 256 bit Nekotorye starye versii brauzerov ispolzuyut dlinu klyucha 40 bit primer tomu IE versij do 4 0 chto svyazano s eksportnymi ogranicheniyami v SShA Dlina klyucha 40 bit ne yavlyaetsya nadyozhnoj Mnogie sovremennye sajty trebuyut ispolzovaniya novyh versij brauzerov podderzhivayushih shifrovanie s dlinoj klyucha 128 bit s celyu obespechit dostatochnyj uroven bezopasnosti Shifrovanie s dlinoj klyucha 128 bit znachitelno zatrudnyaet podbor parolej i dostup k lichnoj informacii Tradicionno na odnom IP adrese mozhet rabotat tolko odin HTTPS sajt Dlya raboty neskolkih HTTPS sajtov s razlichnymi sertifikatami primenyaetsya rasshirenie TLS pod nazvaniem Server Name Indication SNI Na 17 iyulya 2017 goda 22 67 sajtov iz spiska Alexa top 1 000 000 ispolzuyut protokol HTTPS po umolchaniyu HTTPS ispolzuetsya na 4 04 ot obshego chisla zaregistrirovannyh rossijskih domenov Identifikaciya v HTTPSIdentifikaciya servera HTTP TLS zaprosy generiruyutsya putyom razymenovaniya URI vsledstvie chego imya hosta stanovitsya izvestno klientu V nachale obsheniya server posylaet klientu svoj sertifikat chtoby klient identificiroval ego Eto pozvolyaet predotvratit ataku posrednika V sertifikate ukazyvaetsya URI servera Soglasovanie imeni hosta i dannyh ukazannyh v sertifikate proishodit v sootvetstvii s protokolom RFC2459 Esli imya servera ne sovpadaet s ukazannym v sertifikate to polzovatelskie programmy naprimer brauzery soobshayut ob etom polzovatelyu V osnovnom brauzery predostavlyayut polzovatelyu vybor prodolzhit nezashishyonnoe soedinenie ili prervat ego Identifikaciya klienta Obychno server ne raspolagaet informaciej o kliente dostatochnoj dlya ego identifikacii Odnako dlya obespecheniya povyshennoj zashishyonnosti soedineniya ispolzuetsya tak nazyvaemaya two way authentication Pri etom server posle podtverzhdeniya ego sertifikata klientom takzhe zaprashivaet sertifikat Takim obrazom shema podtverzhdeniya klienta analogichna identifikacii servera Sovmestnoe ispolzovanie HTTP i HTTPS Kogda sajty ispolzuyut smeshannuyu funkcionalnost HTTP i HTTPS eto potencialno privodit k informacionnoj ugroze dlya polzovatelya Naprimer esli osnovnye stranicy nekotorogo sajta zagruzhayutsya ispolzuya HTTPS a CSS i JavaScript zagruzhayutsya po HTTP to zloumyshlennik v moment zagruzki poslednih mozhet podgruzit svoj kod i poluchit dannye HTML stranicy Mnogie sajty nesmotrya na takie uyazvimosti zagruzhayut kontent cherez storonnie servisy kotorye ne podderzhivayut HTTPS Mehanizm HSTS pozvolyaet predotvratit podobnye uyazvimosti zastavlyaya prinuditelno ispolzovat HTTPS soedinenie dazhe tam gde po umolchaniyu ispolzuetsya HTTP Ataki s ispolzovaniem analiza trafika Osnovnaya statya Ataka s ispolzovaniem analiza trafika V HTTPS byli obnaruzheny uyazvimosti svyazannye s analizom trafika Ataka s analizom trafika eto tip ataki pri kotoroj vyvodyatsya svojstva zashishyonnyh dannyh kanala putyom izmereniya razmera trafika i vremeni peredachi soobshenij v nyom Analiz trafika vozmozhen poskolku shifrovanie SSL TLS izmenyaet soderzhimoe trafika no okazyvaet minimalnoe vliyanie na razmer i vremya prohozhdeniya trafika V mae 2010 goda issledovateli iz Microsoft Research i Universiteta Indiany obnaruzhili chto podrobnye konfidencialnye polzovatelskie dannye mogut byt polucheny iz vtorostepennyh dannyh takih naprimer kak razmery paketov Analizator trafika smog zapoluchit istoriyu boleznej dannye ob ispolzovavshihsya medikamentah i provedyonnyh operaciyah polzovatelya dannye o semejnom dohode i pr Vsyo eto bylo proizvedeno nesmotrya na ispolzovanie HTTPS v neskolkih sovremennyh veb prilozheniyah v sfere zdravoohraneniya nalogooblozheniya i drugih Ris 1 Standartnaya konfiguraciya seti Polzovatel na hoste klienta CH hochet osushestvit bezopasnuyu tranzakciyu no uyazvim dlya ataki chelovek v seredine Ataka posrednika Osnovnaya statya Ataka posrednika Pri atake posrednika ispolzuetsya to chto server HTTPS otpravlyaet sertifikat s otkrytym klyuchom v brauzer Esli etot sertifikat ne zasluzhivaet doveriya to kanal peredachi budet uyazvimym dlya ataki zloumyshlennika Takaya ataka zamenyaet originalnyj sertifikat udostoveryayushij HTTPS server modificirovannym sertifikatom Ataka prohodit uspeshno esli polzovatel prenebregaet dvojnoj proverkoj sertifikata kogda brauzer otpravlyaet preduprezhdenie Eto osobenno rasprostraneno sredi polzovatelej kotorye chasto stalkivayutsya s samozaverennymi sertifikatami pri dostupe k sajtam vnutri seti chastnyh organizacij Na ris 1 predstavlena situaciya kogda zloumyshlennik yavlyaetsya shlyuzom mezhdu klientom osushestvlyayushim bezopasnuyu tranzakciyu i serverom Takim obrazom cherez zloumyshlennika prohodit ves trafik klienta i on mozhet perenapravit ego po svoemu usmotreniyu Zdes delayutsya sleduyushie shagi Zloumyshlennik vstraivaetsya mezhdu klientom i serverom Peresylaet vse soobsheniya ot klienta serveru bez izmenenij Perehvat soobshenij ot servera poslannyh po shlyuzu po umolchaniyu Sozdanie samozaverennogo sertifikata i podmena im sertifikata servera Otpravlenie lozhnogo sertifikata klientu Kogda klient podtverdit sertifikat budut ustanovleny zashishyonnye soedineniya mezhdu zloumyshlennikom i serverom i drugoe mezhdu zloumyshlennikom i klientom V itoge takoj ataki klient i server dumayut chto osushestvlyayut bezopasnoe soedinenie odnako zloumyshlennik teper takzhe imeet zakrytyj klyuch i mozhet rasshifrovat lyuboe soobshenie v kanale Sm takzheSSL OpenSSL TLS SSH HSTS SPDY SCTP Let s EncryptPrimechaniyaYaroslava Ryabova SSL sertifikaty byvayut raznye neopr Kaspersky Daily 24 aprelya 2018 U nego SSL bylo neskolko versij no vse oni v kakoj to moment podvergalis kritike iz za nalichiya problem s bezopasnostyu V itoge byla vypushena ta versiya kotoraya ispolzuetsya sejchas ee pereimenovali v TLS angl Transport Layer Security Odnako nazvanie SSL prizhilos luchshe i novuyu versiyu protokola do sih por chasto nazyvayut tak Data obrasheniya 19 marta 2020 14 aprelya 2020 goda E Rescorla HTTP Over TLS angl tools ietf org Data obrasheniya 25 dekabrya 2017 31 oktyabrya 2018 goda Walls Colin Embedded software neopr Newnes 2005 S 344 ISBN 0 7506 7954 9 2 aprelya 2023 goda E Rescorla HTTP Over TLS angl tools ietf org Data obrasheniya 25 dekabrya 2017 31 oktyabrya 2018 goda E Rescorla HTTP Over TLS angl tools ietf org Data obrasheniya 25 dekabrya 2017 31 oktyabrya 2018 goda Tim Dierks lt tim dierks org gt The Transport Layer Security TLS Protocol Version 1 2 angl tools ietf org Data obrasheniya 25 dekabrya 2017 24 dekabrya 2017 goda E Rescorla HTTP Over TLS angl tools ietf org Data obrasheniya 25 dekabrya 2017 31 oktyabrya 2018 goda Aboba Bernard Simon Dan PPP EAP TLS Authentication Protocol angl buildbot tools ietf org Data obrasheniya 25 dekabrya 2017 1 oktyabrya 2020 goda Shbair et al 2015 pp 990 995 neopr statoperator com Data obrasheniya 28 iyunya 2016 Arhivirovano iz originala 9 fevralya 2019 goda Statistika rossijskogo interneta runfo ru rus www runfo ru Data obrasheniya 16 fevralya 2017 17 fevralya 2017 goda Solo David Housley Russell Ford Warwick Certificate and CRL Profile angl tools ietf org Data obrasheniya 22 dekabrya 2017 7 iyulya 2017 goda E Rescorla HTTP Over TLS angl tools ietf org Data obrasheniya 22 dekabrya 2017 31 oktyabrya 2018 goda Tim Dierks lt tim dierks org gt The Transport Layer Security TLS Protocol Version 1 2 angl tools ietf org Data obrasheniya 22 dekabrya 2017 24 dekabrya 2017 goda How to Deploy HTTPS Correctly Electronic Frontier Foundation angl 2010 11 15 10 oktyabrya 2018 Data obrasheniya 23 dekabrya 2017 Shuo Chen Rui Wang XiaoFeng Wang Kehuan Zhang Side Channel Leaks in Web Applications a Reality Today a Challenge Tomorrow angl Microsoft Research 2010 05 01 16 marta 2022 goda Callegati et al 2009 s 78 LiteraturaShuo Chen Rui Wang XiaoFeng Wang Kehuan Zhang Side Channel Leaks in Web Applications a Reality Today a Challenge Tomorrow angl Microsoft Research 2010 05 01 F Callegati W Cerroni M Ramilli Man in the Middle Attack to the HTTPS Protocol IEEE Security Privacy 2009 Yanvar t 7 vyp 1 S 78 81 ISSN 1540 7993 doi 10 1109 MSP 2009 12 W M Shbair T Cholez A Goichot I Chrisment Efficiently bypassing SNI based HTTPS filtering 2015 IFIP IEEE International Symposium on Integrated Network Management IM 2015 Maj doi 10 1109 INM 2015 7140423

Дата публикации:
Вершина