HTTPS

A HTTPS (rövidítés az angol  HyperText Transfer Protocol Secure szóból ) a HTTP protokoll kiterjesztése , amely támogatja a titkosítást a biztonság növelése érdekében. A HTTPS protokollban lévő adatok továbbítása a 2015-ben elavult TLS vagy SSL kriptográfiai protokollokon keresztül történik [1] . A 80 - as TCP - porttal rendelkező HTTP-vel ellentétben a HTTPS alapértelmezés szerint a 443-as TCP-portot használja [2] .

A protokollt a Netscape Communications fejlesztette ki a Netscape Navigator böngészőhöz 1994-ben [3] .

Hogyan működik

A HTTPS nem különálló protokoll. Ez egy egyszerű HTTP, amely az SSL és TLS titkosított átviteli mechanizmusain fut [4] . Védelmet nyújt a szippantó támadások és a köztes támadások ellen , feltéve, hogy titkosítási eszközöket használnak, és a szervertanúsítvány érvényes és megbízható [5] .

Alapértelmezés szerint a HTTPS URL a 443-as TCP - portot használja (a nem biztonságos HTTP-80-hoz) [ 2] . Ahhoz, hogy egy webszervert felkészítsen a https-kapcsolatok kezelésére, a rendszergazdának be kell szereznie és telepítenie kell egy nyilvános és privát kulcsú tanúsítványt az adott webszerverhez a rendszeren. A TLS aszimmetrikus titkosítási sémát (megosztott titkos kulcs létrehozására) és szimmetrikus titkosítási sémát (megosztott kulccsal titkosított adatok cseréjére) egyaránt használ. A nyilvános kulcs tanúsítványa megerősíti, hogy az adott nyilvános kulcs a webhely tulajdonosához tartozik. A nyilvános kulcs tanúsítványát és magát a nyilvános kulcsot a rendszer elküldi az ügyfélnek, amikor a kapcsolat létrejön; a privát kulcs a klienstől érkező üzenetek visszafejtésére szolgál [6] .

Létrehozhat ilyen tanúsítványt anélkül, hogy kapcsolatba lépne a tanúsító hatósággal . Az ilyen tanúsítványokat ugyanaz a tanúsítvány írja alá, és önaláírtnak ( self -signed ) nevezzük. A tanúsítvány más módon történő ellenőrzése nélkül (például a tulajdonos felhívása és a tanúsítvány ellenőrző összegének ellenőrzése) ez a HTTPS-használat érzékeny a középső támadásra [7] .

Ez a rendszer kliens hitelesítésre is használható, hogy csak az arra jogosult felhasználók férhessenek hozzá a szerverhez . Ehhez az adminisztrátor általában minden felhasználó számára létrehoz egy tanúsítványt, és feltölti azokat minden felhasználó böngészőjébe. Minden olyan tanúsítványt is elfogadunk, amelyet olyan szervezetek írnak alá, amelyekben a szerver megbízik. Az ilyen tanúsítványok jellemzően a jogosult felhasználó nevét és e-mail címét tartalmazzák, amelyeket minden csatlakozáskor ellenőrzi a felhasználó személyazonosságának ellenőrzése jelszó megadása nélkül [8] .

A HTTPS 40, 56, 128 vagy 256 bites kulcshosszt használ a titkosításhoz. A böngészők egyes régebbi verziói 40 bites kulcshosszt használnak (példa erre az IE 4.0 előtti verziói), az Egyesült Államokban érvényes exportkorlátozások miatt. A 40 bites kulcs nem biztonságos. Sok modern webhely megköveteli a 128 bites titkosítást támogató böngészők új verzióinak használatát a megfelelő szintű biztonság érdekében. A 128 bites kulcshosszúságú titkosítás sokkal nehezebbé teszi a jelszavak kitalálását és a személyes adatok elérését [6] .

Hagyományosan csak egy HTTPS-webhely futhat egy IP-címen. Több különböző tanúsítvánnyal rendelkező HTTPS-webhely a Server Name Indication (SNI) nevű TLS-bővítményt használja [9] .

2017. július 17-én az Alexa top 1 000 000 webhelyének 22,67%-a alapértelmezés szerint HTTPS-t használ [10] . A HTTPS-t az összes regisztrált orosz domain 4,04%-a használja [11] .

HTTPS hitelesítés

Szerver azonosítás

A HTTP/ TLS kérések az URI hivatkozásának megszüntetésével jönnek létre, így a gazdanevet ismeri az ügyfél. A kommunikáció kezdetén a szerver elküldi a tanúsítványát a kliensnek, hogy a kliens azonosítani tudja. Ez megakadályozza a „man-in-the-middle” támadást. A tanúsítvány a kiszolgáló URI-jét határozza meg. A hosztnév és a tanúsítványban megadott adatok egyeztetése az RFC2459 [12] protokoll szerint történik .

Ha a kiszolgáló neve nem egyezik a tanúsítványban megadottal, akkor a felhasználói programok, például a böngészők jelentik ezt a felhasználónak. Alapvetően a böngészők választási lehetőséget adnak a felhasználónak, hogy folytatja-e a nem biztonságos kapcsolatot, vagy megszakítja azt [13] .

Ügyfél azonosítása

A szerver általában nem rendelkezik elegendő információval a kliensről az azonosításhoz. A kapcsolat fokozott biztonsága érdekében azonban az úgynevezett kétirányú hitelesítést alkalmazzák. Ebben az esetben a szerver, miután a kliens visszaigazolta a tanúsítványát, szintén tanúsítványt kér. Így a kliens hitelesítési séma hasonló a szerver hitelesítéshez [14] .

HTTPS sebezhetőségek

HTTP és HTTPS megosztása

Ha a webhelyek HTTP és HTTPS vegyes funkcionalitását használják, az információs fenyegetést jelenthet a felhasználó számára. Például, ha egy webhely fő oldalai HTTPS-sel, a CSS és a JavaScript pedig HTTP-n keresztül töltődnek be, akkor a támadó az utóbbi betöltésekor betöltheti a kódját, és megkaphatja a HTML-oldal adatait. Sok webhely az ilyen sérülékenységek ellenére olyan harmadik féltől származó szolgáltatásokon keresztül tölt le tartalmat, amelyek nem támogatják a HTTPS-t. A HSTS- mechanizmus megakadályozza az ilyen sérülékenységeket azáltal, hogy kényszeríti a HTTPS-kapcsolat használatát még akkor is, ha alapértelmezés szerint a HTTP-t használják [15] .

Forgalomelemzést használó támadások

A HTTPS-ben forgalomelemzéssel kapcsolatos sebezhetőségeket fedeztek fel. A forgalomszimuláló támadás egy olyan támadás, amely a forgalom méretének és az üzenetküldéshez szükséges idő mérésével következtet a csatorna biztonságos adatainak tulajdonságaira. A forgalomelemzés azért lehetséges, mert az SSL/TLS titkosítás megváltoztatja a forgalom tartalmát, de minimális hatással van a forgalom méretére és átviteli idejére. 2010 májusában a Microsoft Research és az Indiana Egyetem kutatói felfedezték, hogy részletes, érzékeny felhasználói adatok származhatnak másodlagos adatokból, például csomagméretekből. A forgalomelemző képes volt leolvasni a felhasználó kórtörténetét, a felhasználó által használt gyógyszereket és végrehajtott tranzakciókat, a családi jövedelmi adatokat stb. Mindez annak ellenére történt, hogy számos modern webalkalmazásban HTTPS-t használnak az egészségügy, adózás területén és mások [16] .

Brókertámadás

A "közepes támadás" azt használja ki, hogy a HTTPS-kiszolgáló nyilvános kulcsú tanúsítványt küld a böngészőnek . Ha ez a tanúsítvány nem megbízható, akkor az átviteli csatorna sebezhető lesz a támadó támadásaival szemben. Ez a támadás a HTTPS-kiszolgálót hitelesítő eredeti tanúsítványt egy módosított tanúsítvánnyal helyettesíti. A támadás akkor sikeres, ha a felhasználó figyelmen kívül hagyja a tanúsítvány kétszeri ellenőrzését, amikor a böngésző elküldi a figyelmeztetést. Ez különösen gyakori a felhasználók körében, akik gyakran találkoznak önaláírt tanúsítványokkal , amikor hozzáférnek egy magánszervezet hálózatán belüli webhelyekhez [17] .

ábrán. Az 1. ábra egy olyan helyzetet mutat be, amikor a támadó átjáró a biztonságos tranzakciót végrehajtó kliens és a szerver között. Így az összes ügyfélforgalom áthalad a támadón, és azt saját belátása szerint átirányíthatja. Itt a következő lépéseket hajtják végre:

1. A támadó beágyaz a kliens és a szerver közé
2. Az összes üzenetet változatlanul továbbítja a klienstől a szerver felé
3. A kiszolgálótól az alapértelmezett átjárónak küldött üzenetek elfogása
4. Önaláírt tanúsítvány létrehozása és cseréje szervertanúsítványra
5. Hamis tanúsítvány küldése az ügyfélnek
6. Amikor az ügyfél érvényesíti a tanúsítványt, biztonságos kapcsolatok jönnek létre: a támadó és a kiszolgáló között, valamint egy másik a támadó és az ügyfél között.

Egy ilyen támadás eredményeként a kliens és a szerver azt hiszi, hogy biztonságos kapcsolatot létesítenek, de a támadó már rendelkezik a privát kulccsal is, és a csatornán lévő bármely üzenetet vissza tudja fejteni [17] .

Lásd még

• SSL
• OpenSSL
• TLS
• SSH
• HSTS
• SPDY
• SCTP
• Titkosítsuk

Jegyzetek

1. ↑ Jaroszlav Rjabov. Az SSL-tanúsítványok eltérőek . Kaspersky Daily (2018. április 24.). „Az [SSL-nek] több verziója is volt, de mindegyiket kritizálták valamikor a biztonsági problémák miatt. Ennek eredményeként megjelent a most használt verzió – átnevezték TLS-re (Transport Layer Security). Az SSL név azonban jobban megfogott, és a protokoll új verzióját továbbra is gyakran így hívják. Letöltve: 2020. március 19. Az eredetiből archiválva : 2020. április 14. (határozatlan)
2. ↑ 1 2 E. Rescorla. HTTP  TLS-en keresztül . tools.ietf.org. Letöltve: 2017. december 25. Az eredetiből archiválva : 2018. október 31..
3. ↑ Falak, Colin. Beágyazott szoftver  (neopr.) . - Newnes, 2005. - P. 344. - ISBN 0-7506-7954-9 . Archiválva : 2019. február 9. a Wayback Machine -nél
4. ↑ E. Rescorla. HTTP  TLS-en keresztül . tools.ietf.org. Letöltve: 2017. december 25. Az eredetiből archiválva : 2018. október 31..
5. ↑ E. Rescorla. HTTP  TLS-en keresztül . tools.ietf.org. Letöltve: 2017. december 25. Az eredetiből archiválva : 2018. október 31..
6. ↑ 1 2 Tim Dierks <[email protected]>. A Transport Layer Security (TLS) protokoll  1.2- es verziója . tools.ietf.org. Hozzáférés dátuma: 2017. december 25. Az eredetiből archiválva : 2017. december 24.
7. ↑ E. Rescorla. HTTP  TLS-en keresztül . tools.ietf.org. Letöltve: 2017. december 25. Az eredetiből archiválva : 2018. október 31..
8. ↑ Aboba, Bernard, Simon, Dan. PPP EAP TLS hitelesítési  protokoll . buildbot.tools.ietf.org. Letöltve: 2017. december 25. Az eredetiből archiválva : 2020. október 1..
9. ↑ Shbair et al, 2015 , pp. 990–995.
10. ↑ HTTPS-használati statisztikák a legnépszerűbb webhelyeken (lefelé mutató link) . statoperator.com. Letöltve: 2016. június 28. Az eredetiből archiválva : 2019. február 9.. (határozatlan) 
11. ↑ Az orosz internet statisztikái runfo.ru . www.runfo.ru Hozzáférés időpontja: 2017. február 16. Az eredetiből archiválva : 2017. február 17. (Orosz)
12. ↑ Solo, David, Housley, Russell, Ford, Warwick. Tanúsítvány és CRL-profil  . tools.ietf.org. Letöltve: 2017. december 22. Az eredetiből archiválva : 2017. július 7.
13. ↑ E. Rescorla. HTTP  TLS-en keresztül . tools.ietf.org. Letöltve: 2017. december 22. Az eredetiből archiválva : 2018. október 31..
14. ↑ Tim Dierks <[email protected]>. A Transport Layer Security (TLS) protokoll  1.2- es verziója . tools.ietf.org. Hozzáférés időpontja: 2017. december 22. Az eredetiből archiválva : 2017. december 24.
15. ↑ A HTTPS helyes telepítése  , Electronic Frontier Foundation (  2010. november 15.). Az eredetiből archiválva: 2018. október 10. Letöltve: 2017. december 23.
16. ↑ Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Oldalcsatorna-szivárgás a webalkalmazásokban: valóság ma, kihívás holnap  //  Microsoft Research. — 2010-05-01. Archiválva az eredetiből 2022. március 16-án.
17. ↑ 12 Callegati et al, 2009 , p. 78.

Irodalom

• Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Oldalcsatorna-szivárgás a webalkalmazásokban: valóság ma, kihívás holnap  //  Microsoft Research. — 2010-05-01.
• F. Callegati, W. Cerroni, M. Ramilli. Man-in-the-Middle Attack to the HTTPS Protocol  // IEEE Security Privacy. - 2009. - január ( 7. évf. 1. szám ). - S. 78-81 . — ISSN 1540-7993 . - doi : 10.1109/MSP.2009.12 .
• W. M. Shbair, T. Cholez, A. Goichot, I. Chrisment. Az SNI-alapú HTTPS-szűrés hatékony megkerülése  // 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM). - 2015. - május. - doi : 10.1109/INM.2015.7140423 .

Szótárak és enciklopédiák	Nagy norvég