HTTPS

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 9 maj 2022; kontroller kräver 5 redigeringar .
HTTPS
namn HyperText Transfer Protocol Secure
Nivå (enligt OSI-modellen ) Applicerad
Familj TCP/IP
Skapad i 2000
Port/ID 443/ TCP
Syftet med protokollet Säker anslutning till servern
Specifikation RFC 2818
Huvudsakliga implementeringar (klienter) webbläsare
Kärnimplementationer ( servrar ) Apache , nginx , IIS
 Mediafiler på Wikimedia Commons

HTTPS (förkortning från engelska  HyperText Transfer Protocol Secure ) är en förlängning av HTTP-protokollet för att stödja kryptering för att öka säkerheten. Data i HTTPS-protokollet överförs över de kryptografiska protokollen TLS eller SSL som förlades 2015 [1] . Till skillnad från HTTP med TCP- port 80 har HTTPS som standard TCP-port 443 [2] .

Protokollet utvecklades av Netscape Communications för webbläsaren Netscape Navigator 1994 [3] .

Hur det fungerar

HTTPS är inte ett separat protokoll. Detta är vanlig HTTP som körs över de krypterade transportmekanismerna SSL och TLS [4] . Det ger skydd mot snifferattacker och man-in-the-middle-attacker , förutsatt att krypteringsverktyg används och servercertifikatet är validerat och pålitligt [5] .

Som standard använder HTTPS URL TCP- port 443 (för osäkrad HTTP - 80) [ 2] . För att förbereda en webbserver för att hantera https-anslutningar måste en administratör skaffa och installera ett offentligt och privat nyckelcertifikat för den webbservern på systemet. TLS använder både ett asymmetriskt krypteringsschema (för att generera en delad hemlig nyckel) och ett symmetriskt krypteringsschema (för att utbyta data krypterad med en delad nyckel). Det offentliga nyckelcertifikatet bekräftar att den givna offentliga nyckeln tillhör ägaren av webbplatsen. Det publika nyckelcertifikatet och den publika nyckeln i sig skickas till klienten när en anslutning upprättas; den privata nyckeln används för att dekryptera meddelanden från klienten [6] .

Det är möjligt att skapa ett sådant certifikat utan att kontakta en certifikatutfärdare . Sådana certifikat är signerade av samma certifikat och kallas självsignerade ( självsignerade ). Utan att verifiera certifikatet på något annat sätt (som att ringa ägaren och kontrollera certifikatets kontrollsumma), är denna användning av HTTPS mottaglig för en man-i- mitten-attack [7] .

Detta system kan också användas för klientautentisering för att säkerställa att endast behöriga användare kan komma åt servern . För att göra detta skapar administratören vanligtvis certifikat för varje användare och laddar upp dem till varje användares webbläsare. Alla certifikat signerade av organisationer som servern litar på kommer också att accepteras. Ett sådant certifikat innehåller vanligtvis namnet och e-postadressen till den auktoriserade användaren, som kontrolleras på varje anslutning för att verifiera användarens identitet utan att ange ett lösenord [8] .

HTTPS använder en nyckellängd på 40, 56, 128 eller 256 bitar för kryptering. Vissa äldre versioner av webbläsare använder en 40-bitars nyckellängd (ett exempel på detta är IE - versioner före 4.0), på grund av exportrestriktioner i USA. En nyckellängd på 40 bitar är inte säker. Många moderna webbplatser kräver användning av nya versioner av webbläsare som stöder 128-bitars kryptering för att ge en tillräcklig säkerhetsnivå. Kryptering med en nyckellängd på 128 bitar gör det mycket svårare att gissa lösenord och komma åt personlig information [6] .

Traditionellt kan bara en HTTPS-webbplats köras på en IP-adress. Flera HTTPS-webbplatser med olika certifikat använder en TLS-tillägg som kallas Server Name Indication (SNI) [9] .

Den 17 juli 2017 använder 22,67 % av Alexas topp 1 000 000 webbplatser HTTPS som standard [10] . HTTPS används av 4,04 % av det totala antalet registrerade ryska domäner [11] .

HTTPS-autentisering

Serveridentifiering

HTTP/ TLS -förfrågningar genereras genom avreferensering av URI :n så att värdnamnet är känt för klienten. I början av kommunikationen skickar servern sitt certifikat till klienten så att klienten kan identifiera det. Detta förhindrar en man-i-mitten-attack. Certifikatet anger serverns URI. Förhandlingen av värdnamnet och de data som anges i certifikatet sker i enlighet med protokollet RFC2459 [12] .

Om servernamnet inte stämmer överens med det som anges i certifikatet, rapporterar användarprogram, såsom webbläsare, detta till användaren. I grund och botten ger webbläsare användaren valet att fortsätta med en osäker anslutning eller avsluta den [13] .

Klientidentifiering

Servern har vanligtvis inte tillräcklig information om klienten för att identifiera den. För att ge ökad säkerhet för anslutningen används dock den så kallade tvåvägsautentiseringen. I det här fallet begär servern, efter att ha bekräftat sitt certifikat av klienten, också ett certifikat. Således liknar klientautentiseringsschemat serverautentisering [14] .

HTTPS-sårbarheter

Dela HTTP och HTTPS

När webbplatser använder blandade funktioner av HTTP och HTTPS kan detta leda till ett informationshot mot användaren. Till exempel, om huvudsidorna på en webbplats laddas med HTTPS, och CSS och JavaScript laddas över HTTP, kan en angripare vid tidpunkten för inläsning av den senare ladda sin kod och hämta HTML-sidans data. Många webbplatser, trots sådana sårbarheter, laddar ner innehåll via tredjepartstjänster som inte stöder HTTPS. HSTS - mekanismen förhindrar sådana sårbarheter genom att tvinga fram en HTTPS-anslutning även där HTTP används som standard [15] .

Attacker med trafikanalys

Sårbarheter relaterade till trafikanalys har upptäckts i HTTPS. En trafiksniffrattack är en typ av attack som härleder egenskaperna hos en kanals säkra data genom att mäta storleken på trafiken och den tid det tar att skicka meddelanden. Trafikanalys är möjlig eftersom SSL/TLS-kryptering ändrar innehållet i trafiken, men har minimal inverkan på trafikens storlek och transittid. I maj 2010 upptäckte forskare vid Microsoft Research och Indiana University att detaljerad, känslig användardata kunde härledas från sekundära data såsom paketstorlekar. Trafikanalysatorn kunde få tag på användarens sjukdomshistoria, mediciner som använts och transaktioner utförda av användaren, familjeinkomstdata etc. Allt detta gjordes trots användningen av HTTPS i flera moderna webbapplikationer inom området sjukvård, beskattning och andra [16] .

Mäklarattack

En "man-in-the-middle-attack" utnyttjar att HTTPS-servern skickar ett offentligt nyckelcertifikat till webbläsaren . Om detta certifikat inte är tillförlitligt kommer överföringskanalen att vara sårbar för attacker från en angripare. Denna attack ersätter det ursprungliga certifikatet som autentiserar HTTPS-servern med ett modifierat certifikat. Attacken lyckas om användaren försummar att dubbelkolla certifikatet när webbläsaren skickar varningen. Detta är särskilt vanligt bland användare, som ofta stöter på självsignerade certifikat vid åtkomst till webbplatser inom en privat organisations nätverk [17] .

På fig. 1 visar en situation där en angripare är en gateway mellan en klient som utför en säker transaktion och en server. Således passerar all klienttrafik genom angriparen och han kan omdirigera den efter eget gottfinnande. Följande steg tas här:

  1. Angripare bäddar in mellan klient och server
  2. Vidarebefordrar alla meddelanden från klienten till servern oförändrat
  3. Avlyssning av meddelanden från servern som skickas till standardgatewayen
  4. Skapa ett självsignerat certifikat och ersätta det med ett servercertifikat
  5. Skickar ett falskt certifikat till klienten
  6. När klienten validerar certifikatet kommer säkra anslutningar att upprättas: mellan angriparen och servern, och en annan mellan angriparen och klienten.

Som ett resultat av en sådan attack tror klienten och servern att de gör en säker anslutning, men angriparen har nu även den privata nyckeln och kan dekryptera vilket meddelande som helst i kanalen [17] .

Se även

Anteckningar

  1. ↑ Yaroslav Ryabov. SSL-certifikat är olika . Kaspersky Daily (24 april 2018). "Den [SSL] hade flera versioner, men alla kritiserades någon gång på grund av förekomsten av säkerhetsproblem. Som ett resultat släpptes versionen som används nu - den döptes om till TLS (Transport Layer Security). Namnet SSL fångade dock bättre, och den nya versionen av protokollet kallas fortfarande ofta så. Hämtad 19 mars 2020. Arkiverad från originalet 14 april 2020.
  2. ↑ 1 2 E. Rescorla. HTTP över  TLS . tools.ietf.org. Hämtad 25 december 2017. Arkiverad från originalet 31 oktober 2018.
  3. ↑ Walls, Colin. Inbäddad programvara  (neopr.) . - Newnes, 2005. - S. 344. - ISBN 0-7506-7954-9 . Arkiverad 9 februari 2019 på Wayback Machine
  4. ↑ E. Rescorla. HTTP över  TLS . tools.ietf.org. Hämtad 25 december 2017. Arkiverad från originalet 31 oktober 2018.
  5. ↑ E. Rescorla. HTTP över  TLS . tools.ietf.org. Hämtad 25 december 2017. Arkiverad från originalet 31 oktober 2018.
  6. ↑ 1 2 Tim Dierks <[email protected]>. Transport Layer Security (TLS) Protocol Version  1.2 . tools.ietf.org. Datum för åtkomst: 25 december 2017. Arkiverad från originalet 24 december 2017.
  7. ↑ E. Rescorla. HTTP över  TLS . tools.ietf.org. Hämtad 25 december 2017. Arkiverad från originalet 31 oktober 2018.
  8. ↑ Aboba, Bernard, Simon, Dan. PPP EAP TLS Authentication  Protocol . buildbot.tools.ietf.org. Hämtad 25 december 2017. Arkiverad från originalet 1 oktober 2020.
  9. ↑ Shbair et al, 2015 , s. 990–995.
  10. ↑ HTTPS-användningsstatistik på toppwebbplatser (nedlänk) . statoperator.com. Hämtad 28 juni 2016. Arkiverad från originalet 9 februari 2019. 
  11. ↑ Statistik för det ryska Internet runfo.ru . www.runfo.ru Datum för åtkomst: 16 februari 2017. Arkiverad från originalet 17 februari 2017.
  12. ↑ Solo, David, Housley, Russell, Ford, Warwick. Certifikat och CRL-profil  . tools.ietf.org. Hämtad 22 december 2017. Arkiverad från originalet 7 juli 2017.
  13. ↑ E. Rescorla. HTTP över  TLS . tools.ietf.org. Hämtad 22 december 2017. Arkiverad från originalet 31 oktober 2018.
  14. ↑ Tim Dierks <[email protected]>. Transport Layer Security (TLS) Protocol Version  1.2 . tools.ietf.org. Datum för åtkomst: 22 december 2017. Arkiverad från originalet 24 december 2017.
  15. ↑ Hur man distribuerar HTTPS korrekt  , Electronic Frontier Foundation (  15 november 2010). Arkiverad från originalet den 10 oktober 2018. Hämtad 23 december 2017.
  16. ↑ Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Sidokanalläckor i webbapplikationer: en verklighet idag, en utmaning i morgon  //  Microsoft Research. — 2010-05-01. Arkiverad från originalet den 16 mars 2022.
  17. ↑ 12 Callegati et al, 2009 , sid. 78.

Litteratur

  Gå till Wikidata-objektet  Ordböcker och uppslagsverk
 URI- scheman
Officiell
inofficiell
 http
Allmänna begrepp
Metoder
Titlar
Statuskoder