HTTPS

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 9. toukokuuta 2022 tarkistetusta versiosta . tarkastukset vaativat 5 muokkausta .
HTTPS
Nimi Hypertext Transfer Protocol Secure
Taso ( OSI-mallin mukaan ) Sovellettu
Perhe TCP/IP
Luotu vuonna 2000
Portti/ID 443/ TCP
Protokollan tarkoitus Suojattu yhteys palvelimeen
Erittely RFC 2818
Tärkeimmät toteutukset (asiakkaat) verkkoselaimet
Ydintoteutukset ( palvelimet ) Apache , nginx , IIS
 Mediatiedostot Wikimedia Commonsissa

HTTPS (lyhenne englanniksi  HyperText Transfer Protocol Secure ) on HTTP-protokollan laajennus , joka tukee salausta turvallisuuden lisäämiseksi. HTTPS-protokollan tiedot siirretään vuonna 2015 vanhentuneiden TLS- tai SSL -salausprotokollien kautta [1] . Toisin kuin HTTP, jossa on TCP - portti 80 , HTTPS käyttää oletuksena TCP-porttia 443 [2] .

Protokollan kehitti Netscape Communications Netscape Navigator -selaimelle vuonna 1994 [3] .

Kuinka se toimii

HTTPS ei ole erillinen protokolla. Tämä on tavallista HTTP:tä, joka toimii salattujen SSL- ja TLS -siirtomekanismien yli [4] . Se tarjoaa suojan sniffer - hyökkäyksiltä ja mies-in-the-middle-hyökkäyksiltä edellyttäen, että käytetään salaustyökaluja ja palvelinvarmenne on validoitu ja luotettava [5] .

Oletusarvoisesti HTTPS-URL käyttää TCP - porttia 443 (suojaamaton HTTP - 80) [ 2] . Jotta verkkopalvelin voidaan valmistella käsittelemään https-yhteyksiä, järjestelmänvalvojan on hankittava ja asennettava julkisen ja yksityisen avaimen varmenne kyseiselle verkkopalvelimelle järjestelmään. TLS käyttää sekä epäsymmetristä salausmenetelmää (jaetun salaisen avaimen luomiseen) että symmetristä salausmenetelmää (jaetulla avaimella salatun tiedon vaihtamiseen). Julkisen avaimen varmenne vahvistaa, että annettu julkinen avain kuuluu sivuston omistajalle. Julkisen avaimen varmenne ja itse julkinen avain lähetetään asiakkaalle, kun yhteys muodostetaan; yksityistä avainta käytetään asiakkaalta tulevien viestien salauksen purkamiseen [6] .

Tällainen varmenne on mahdollista luoda ilman varmenneviranomaisen yhteyttä . Tällaiset varmenteet allekirjoitetaan samalla varmenteella ja niitä kutsutaan itseallekirjoitetuiksi ( itseallekirjoitetuiksi ). Ilman varmenteen tarkistamista jollain muulla tavalla (kuten soittamalla omistajalle ja tarkistamatta varmenteen tarkistussummaa), tämä HTTPS:n käyttö on altis man-in-the-midd- hyökkäykselle [7] .

Tätä järjestelmää voidaan käyttää myös asiakkaan todentamiseen sen varmistamiseksi, että vain valtuutetut käyttäjät voivat käyttää palvelinta . Tätä varten järjestelmänvalvoja yleensä luo varmenteet kullekin käyttäjälle ja lataa ne kunkin käyttäjän selaimeen. Myös kaikki palvelimen luotettavien organisaatioiden allekirjoittamat varmenteet hyväksytään. Tällainen varmenne sisältää tyypillisesti valtuutetun käyttäjän nimen ja sähköpostiosoitteen, jotka tarkistetaan jokaisen yhteyden yhteydessä käyttäjän henkilöllisyyden varmistamiseksi ilman salasanaa [8] .

HTTPS käyttää salaukseen 40, 56, 128 tai 256 bitin avaimen pituutta. Jotkut vanhemmat selainversiot käyttävät 40-bittistä avaimen pituutta (esimerkki tästä ovat 4.0:aa aikaisemmat IE -versiot) Yhdysvaltojen vientirajoitusten vuoksi. 40 bitin avaimen pituus ei ole turvallinen. Monet nykyaikaiset verkkosivustot edellyttävät uusien 128-bittistä salausta tukevien selainversioiden käyttöä riittävän suojaustason takaamiseksi. Salaus avaimen pituudella 128 bittiä vaikeuttaa salasanojen arvaamista ja henkilökohtaisten tietojen käyttöä [6] .

Perinteisesti vain yksi HTTPS-sivusto voi toimia yhdellä IP-osoitteella. Useat HTTPS-sivustot eri varmenteilla käyttävät TLS-laajennusta nimeltä Server Name Indication (SNI) [9] .

17. heinäkuuta 2017 mennessä 22,67 % Alexan 1 000 000 suosituimmasta sivustosta käyttää oletusarvoisesti HTTPS:ää [10] . HTTPS:ää käyttää 4,04 % Venäjän rekisteröityjen verkkotunnuksien kokonaismäärästä [11] .

HTTPS-todennus

Palvelimen tunnistus

HTTP/ TLS -pyynnöt luodaan poistamalla URI -viittaukset, jotta isäntänimi on asiakkaan tiedossa. Viestinnän alussa palvelin lähettää varmenteensa asiakkaalle, jotta asiakas voi tunnistaa sen. Tämä estää mies-keskellä-hyökkäyksen. Varmenne määrittää palvelimen URI:n. Isäntänimen ja varmenteessa määritettyjen tietojen neuvottelu tapahtuu RFC2459 [12] -protokollan mukaisesti .

Jos palvelimen nimi ei vastaa varmenteessa määritettyä, käyttäjäohjelmat, kuten selaimet, ilmoittavat tästä käyttäjälle. Pohjimmiltaan selaimet antavat käyttäjälle mahdollisuuden valita, jatkaako suojaamatonta yhteyttä vai katkaistaanko se [13] .

Asiakkaan tunniste

Tyypillisesti palvelimella ei ole riittävästi tietoa asiakkaasta sen tunnistamiseksi. Yhteyden turvallisuuden parantamiseksi käytetään kuitenkin niin sanottua kaksisuuntaista todennusta. Tässä tapauksessa palvelin pyytää varmennetta myös sen jälkeen, kun asiakas on vahvistanut varmenteensa. Siten asiakkaan todennusmalli on samanlainen kuin palvelimen todennus [14] .

HTTPS-haavoittuvuudet

HTTP:n ja HTTPS:n jakaminen

Kun sivustot käyttävät HTTP:n ja HTTPS:n sekatoimintoja, tämä saattaa aiheuttaa tietouhan käyttäjälle. Jos esimerkiksi sivuston pääsivut ladataan HTTPS:llä ja CSS ja JavaScript ladataan HTTP:n kautta, hyökkääjä voi ladata koodinsa ja saada HTML-sivun tiedot. Monet sivustot lataavat tällaisista haavoittuvuuksista huolimatta sisältöä kolmannen osapuolen palveluiden kautta, jotka eivät tue HTTPS:ää. HSTS - mekanismi estää tällaiset haavoittuvuudet pakottamalla HTTPS-yhteyden käyttöön silloinkin, kun HTTP on oletuksena käytössä [15] .

Hyökkäykset liikenneanalyysin avulla

HTTPS:stä on löydetty liikenneanalyysiin liittyviä haavoittuvuuksia. Liikenteen haistajahyökkäys on eräänlainen hyökkäys, joka päättelee kanavan suojattujen tietojen ominaisuudet mittaamalla liikenteen koon ja viestien lähettämiseen kuluvan ajan. Liikenneanalyysi on mahdollista, koska SSL/TLS-salaus muuttaa liikenteen sisältöä, mutta sillä on minimaalinen vaikutus liikenteen kokoon ja siirtoaikaan. Toukokuussa 2010 Microsoft Researchin ja Indianan yliopiston tutkijat havaitsivat, että yksityiskohtaisia, arkaluontoisia käyttäjätietoja voitiin johtaa toissijaisista tiedoista, kuten pakettien koosta. Liikenneanalysaattorilla saatiin käsiinsä käyttäjän sairaushistoria, käytetyt lääkkeet ja käyttäjän suorittamat tapahtumat, perheen tulotiedot jne. Kaikki tämä tapahtui huolimatta HTTPS:n käytöstä useissa nykyaikaisissa web-sovelluksissa terveydenhuollon, verotuksen alalla ja muut [16] .

Välittäjähyökkäys

"Man-in-the-middle-hyökkäys" hyödyntää sitä, että HTTPS-palvelin lähettää selaimeen julkisen avaimen varmenteen . Jos tämä varmenne ei ole luotettava, lähetyskanava on alttiina hyökkääjän hyökkäyksille. Tämä hyökkäys korvaa alkuperäisen HTTPS-palvelimen todentavan varmenteen muokatulla varmenteella. Hyökkäys onnistuu, jos käyttäjä laiminlyö varmenteen tarkistamisen, kun selain lähettää varoituksen. Tämä on erityisen yleistä käyttäjien keskuudessa, jotka kohtaavat usein itse allekirjoitettuja varmenteita käyttäessään yksityisen organisaation verkon sivustoja [17] .

Kuvassa Kuva 1 näyttää tilanteen, jossa hyökkääjä on yhdyskäytävä suojattua tapahtumaa suorittavan asiakkaan ja palvelimen välillä. Siten kaikki asiakasliikenne kulkee hyökkääjän läpi ja hän voi ohjata sen uudelleen harkintansa mukaan. Tässä suoritetaan seuraavat vaiheet:

  1. Hyökkääjä upottaa asiakkaan ja palvelimen väliin
  2. Välittää kaikki viestit asiakkaalta palvelimelle muuttumattomina
  3. Siepataan palvelimelta oletusyhdyskäytävälle lähetetyt viestit
  4. Luodaan itse allekirjoitettu varmenne ja korvataan se palvelinvarmenteella
  5. Väärän varmenteen lähettäminen asiakkaalle
  6. Kun asiakas vahvistaa varmenteen, suojatut yhteydet luodaan: hyökkääjän ja palvelimen välille ja toinen hyökkääjän ja asiakkaan välille.

Tällaisen hyökkäyksen seurauksena asiakas ja palvelin luulevat muodostavansa suojatun yhteyden, mutta hyökkääjällä on nyt myös yksityinen avain ja hän voi purkaa minkä tahansa kanavan viestin salauksen [17] .

Katso myös

Muistiinpanot

  1. ↑ Jaroslav Ryabov. SSL - varmenteet ovat erilaisia ​​. Kaspersky Daily (24. huhtikuuta 2018). "Sillä [SSL] oli useita versioita, mutta kaikkia niitä kritisoitiin jossain vaiheessa tietoturvaongelmien vuoksi. Tämän seurauksena nyt käytetty versio julkaistiin - se nimettiin uudelleen TLS:ksi (Transport Layer Security). Nimi SSL kuitenkin tarttui paremmin, ja protokollan uutta versiota kutsutaan edelleen usein sellaiseksi. Haettu 19. maaliskuuta 2020. Arkistoitu alkuperäisestä 14. huhtikuuta 2020.
  2. ↑ 1 2 E. Rescorla. HTTP  TLS:n kautta . tools.ietf.org. Haettu 25. joulukuuta 2017. Arkistoitu alkuperäisestä 31. lokakuuta 2018.
  3. ↑ Seinät, Colin. Sulautettu ohjelmisto  (uuspr.) . - Newnes, 2005. - S. 344. - ISBN 0-7506-7954-9 . Arkistoitu 9. helmikuuta 2019 Wayback Machinessa
  4. ↑ E. Rescorla. HTTP  TLS:n kautta . tools.ietf.org. Haettu 25. joulukuuta 2017. Arkistoitu alkuperäisestä 31. lokakuuta 2018.
  5. ↑ E. Rescorla. HTTP  TLS:n kautta . tools.ietf.org. Haettu 25. joulukuuta 2017. Arkistoitu alkuperäisestä 31. lokakuuta 2018.
  6. ↑ 1 2 Tim Dierks <[email protected]>. Transport Layer Security (TLS) -protokollan versio  1.2 . tools.ietf.org. Käyttöpäivä: 25. joulukuuta 2017. Arkistoitu alkuperäisestä 24. joulukuuta 2017.
  7. ↑ E. Rescorla. HTTP  TLS:n kautta . tools.ietf.org. Haettu 25. joulukuuta 2017. Arkistoitu alkuperäisestä 31. lokakuuta 2018.
  8. ↑ Aboba, Bernard, Simon, Dan. PPP EAP TLS Authentication  Protocol . buildbot.tools.ietf.org. Haettu 25. joulukuuta 2017. Arkistoitu alkuperäisestä 1. lokakuuta 2020.
  9. ↑ Shbair et al, 2015 , s. 990–995.
  10. ↑ HTTPS-käyttötilastot suosituimmilla verkkosivustoilla (downlink) . statoperator.com. Haettu 28. kesäkuuta 2016. Arkistoitu alkuperäisestä 9. helmikuuta 2019. 
  11. ↑ Venäjän Internetin tilastot runfo.ru . www.runfo.ru Käyttöpäivä: 16. helmikuuta 2017. Arkistoitu alkuperäisestä 17. helmikuuta 2017.
  12. ↑ Yksin, David, Housley, Russell, Ford, Warwick. Varmenne ja CRL-profiili  . tools.ietf.org. Haettu 22. joulukuuta 2017. Arkistoitu alkuperäisestä 7. heinäkuuta 2017.
  13. ↑ E. Rescorla. HTTP  TLS:n kautta . tools.ietf.org. Haettu 22. joulukuuta 2017. Arkistoitu alkuperäisestä 31. lokakuuta 2018.
  14. ↑ Tim Dierks <[email protected]>. Transport Layer Security (TLS) -protokollan versio  1.2 . tools.ietf.org. Käyttöpäivä: 22. joulukuuta 2017. Arkistoitu alkuperäisestä 24. joulukuuta 2017.
  15. ↑ Kuinka ottaa HTTPS käyttöön oikein  , Electronic Frontier Foundation (  15. marraskuuta 2010). Arkistoitu alkuperäisestä 10. lokakuuta 2018. Haettu 23.12.2017.
  16. ↑ Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Sivukanavavuotoja verkkosovelluksissa: todellisuus tänään, haaste huomenna  //  Microsoft Research. - 2010-05-01. Arkistoitu alkuperäisestä 16. maaliskuuta 2022.
  17. ↑ 12 Callegati et al, 2009 , s. 78.

Kirjallisuus

  Siirry Wikidata-kohteeseen  Sanakirjat ja tietosanakirjat
 URI- järjestelmät
Virallinen
epävirallinen
 http
Yleiset käsitteet
menetelmät
Otsikot
Tilakoodit