https
A https egy URI-séma, amely biztonságos http kapcsolatot jelöl. Szintaktikailag megegyezik a http sémával, amelyet a HTTP protokollnál használnak, de a https nem önálló protokoll, hanem csak egy URI séma, mely azt jelzi, hogy a HTTP protokollt kell használni a szerver 443-as TCP portján a HTTP és a TCP szintek közé titkosító/autentikáló SSL vagy TLS réteg beiktatásával. (A titkosítatlan HTTP rendszerint a 80-as TCP portot használja.)
A https-t a Netscape fejlesztette ki, hogy a webes kommunikáció titkosítható és autentikálható legyen. Ma széles körben használják ezt a rendszert a weben biztonságilag kritikus kommunikációknál, mint amilyenek például a fizetési tranzakciók és a felhasználói jelszavas bejelentkezések.
Működése
szerkesztésA https nem különálló protokoll, hanem SSL vagy TLS kapcsolat feletti HTTP kommunikációra utal. A https: kezdetű URL-ben megadható TCP port is, de alapértelmezett értéke 443.
Ahhoz, hogy egy webszerver https kéréseket tudjon fogadni, az adminisztrátornak tanúsítványt (angolul public key certificate) kell készítenie.
Kétkulcsos titkosítás
szerkesztésA https alapja a kétkulcsos titkosítás. A kulcspár két összetartozó, nagyon nagy (több száz jegyű) szám. A titkosítandó szöveget az egyik szám segítségével, egy nyilvános eljárással rejtjelezzük. Az így kapott üzenet ugyanazzal az eljárással, de a kulcspár másik tagjának segítségével fejthető csak vissza.
Ha a kulcspár egyik tagját titokban tartjuk, a másik kulcsot nyilvánosságra hozzuk, és valaki egy üzenetet a nyilvános kulcsunkkal rejtjelez, akkor azt csak mi fogjuk tudni elolvasni. A titkosítás mindig a nyilvános kulccsal történik.
A nyilvános kulccsal visszafejthetők lesznek azok az üzenetek, amelyeket mi rejtjeleztünk. A visszafejthetőség igazolja, hogy a titkos üzenetet mi írtuk (hiszen a titkosító kulcsot csak mi ismerjük), ezért ezt az eljárást digitális aláírásnak nevezzük. A digitális aláírás tehát mindig titkos kulccsal történő rejtjelezést jelent.
Tanúsítóhely
szerkesztésHa egy webszerver nyilvános kulcsát le tudjuk kérdezni, és azzal titkosítunk, akkor az üzenetünket csak a webszerver fogja tudni elolvasni. Az üzenet titkosságával tehát már nincs baj, abban viszont még nem lehetünk biztosak, hogy a titkosított üzenetünk ahhoz jutott, akinek szántuk, hiszen titkosító kulcspárt bárki tud csinálni. Más szóval: a webszerver hitelessége még nincs biztosítva.
A hitelesség biztosításának egyik módja a tanúsítvány. Ez egy igazolás arról, hogy a webszerver nyilvános kulcsa hiteles. Az igazolás kiadója egy tanúsítóhely (Certificate Authority), az igazolás hitelességét az ő digitális aláírása biztosítja, valamint az a tény, hogy a tanúsítóhelyet a böngésző írói felvették a böngészőben a hiteles tanúsítóhelyek listájába.
A tanúsítóhelynek tehát hasonló szerepe van a digitális hitelesítésben, mint a közjegyzőnek a papír alapúban. Fontos különbség viszont, hogy a tanúsítóhelyet nem hatóság, hanem a böngésző „nevezi ki”.
Kulcs generálása
szerkesztésA webszerver tulajdonosa generál egy titkosításra alkalmas kulcspárt. Erre számos szoftver van, pl. a nyílt forráskódú openssl. A kulcs hossza a példában 2048 bit.
openssl genrsa -out név.key 2048 # titkos kulcs openssl rsa -in név.key -pubout >név.pub # publikus kulcs
Egy másik nyílt forrású eszköz a certtool. A publikus kulcs a fentihez hasonlóan állítható elő.
certtool -p --bits=2048 --outfile név.key
Tanúsítványkérelem előállítása
szerkesztésA tanúsítványkérelem a szerver adatainak (URL, IP-cím, szervezet neve, stb.) a szerver titkos kulcsával aláírt alakja. A kérelem része a nyilvános kulcs, de nem része a titkos kulcs. A titkos kulcsot egyedül a webszerver tulajdonosa tudja, még a tanúsítóhely sem.
A tanúsítványkérelem előállítása pl. az előbb már említett certtool-lal (de openssl-lel is lehet):
certtool -q --load-privkey név.key --outfile név.csr
A certool felteszi a kérelemhez szükséges kérdéseket, majd megfelelő formában eltárolja kérelmet. A kérelem aláírásához szüksége van a szerver titkos kulcsára.
A kérelem nemcsak egy szerverre, hanem egy egész szervezetre, vagy akár egy egész domainre vonatkozhat.
Tanúsítvány
szerkesztésA tanúsítvány az aláírt tanúsítványkérelem. A kérelem aláírható a szerver (titkos) kulcsával: ez az önmagával aláírt (self-signed) tanúsítvány. Ha ilyen tanúsítványú webszerverre tévedünk, a böngésző figyelmeztet, hogy a tanúsítvány nem megbízható. Csak akkor szabad elfogadni, ha a szerver nyilvános kulcsához megbízható forrásból jutottunk hozzá, nem az internetről.
A megbízható tanúsítványhoz a kérelmet a böngészők által elfogadott tanúsítóhelyek egyikével kell aláíratni. Az így kapható tanúsítványnak biztonsági szempontból két fokozata van:
- Egyszerűsített. A tanúsítóhely igazolja, hogy a tanúsítvány tulajdonosa valóban birtokolja a szervert, de arról nem mond semmit, hogy az-e, akinek állítja magát a tanúsítványban. Előnye, hogy ilyen, a böngészők által is elfogadott tanúsítványt papír nélkül, online is lehet szerezni, akár ingyen is, bár úgy csak rövid lejáratra.
- Kiterjesztett. A regisztráló a kérelem benyújtásakor személyesen, papír alapú dokumentumokkal igazolja, hogy jogosan képviseli a kérelemben megnevezett tulajdonost. A legtöbb bank ilyen tanúsítványt használ, akárcsak a Wikipédia szerverei.
Az aláírás előtt a tanúsítóhely felveszi az adatok közé az érvényesség időintervallumát.
A böngésző ellenőrzi a tanúsítvány aláíróját a saját tanúsítóhely-adatbázisa alapján. Felkeresi a tanúsítóhelyet, és ellenőrzi azt is, hogy időközben visszavonták-e a tanúsítványt. Az ellenőrzés eredménye az URL előtt látható zöld vagy sárga háromszöggel megjelölt lakat formájában. A lakatra kattintva meg lehet nézni a tanúsítványt.
Biztonsági beállítások https protokollban
szerkesztésA https protokoll ugyan jóval biztonságosabb a http-nél, de maradtak benne biztonsági problémák, melyek újabb védekezést igényelnek.
Tanúsítvány visszavonása
szerkesztésA kompromittálódott tanúsítványt vissza kell vonni. A kapcsolatfelvételkor ellenőrizni kell a kapott nyilvános kulcs, a kibocsátó tanúsítóhely és a teljes tanúsítványlánc kulcsainak érvényességét. (Volt már rá példa, hogy tanúsítóhely kompromittálódott.[1][2]) A tanúsítvány érvényességének ellenőrzésére szolgál a Online Certificate Status Protocol(en).
A tanúsítóhely hitelesítése
szerkesztésA tanúsítványnak biztosítania kellene, hogy a böngésző a szándékaink szerinti szerverhez kapcsolódik. Van azonban egy gyenge pont: a tanúsítóhelyek nem kommunikálnak egymással, így elképzelhető, hogy egy másik tanúsítóhelytől egy kalóz tud szerezni egy (majdnem) azonos nevű szervezethez tartozó tanúsítványt egy másik szerverhez. A felhasználók nem fogják észrevenni a tanúsítóhely változását, ha a kalóznak sikerül magára irányítania a kapcsolatot: a böngésző nem figyelmeztet, hiszen ez a tanúsítvány is megbízható.
Ennek elkerülésére a névszerverek rekordtípusai közé felvettek egy új típust CAA(en) betűnévvel, mely megadja az ahhoz a bejegyzéshez tartozó tanúsítóhelyet.
HPKP
szerkesztésA veszély hasonlít a CAA-nál leírtakra, de annál nagyobb. Volt már rá példa, hogy tanúsítóhelyet törtek fel, és adtak ki a nevében hamisított tanúsítványokat.[1][2]
Védekezni úgy lehet, hogy a webszerver elküldi az aktuális tanúsítványának és a tanúsítványkérelmének az ujjlenyomatát (nem hamisítható kivonatát) a kliensnek, amely azt – a HSTS-hez hasonlóan – megjegyzi, és a továbbiakban csak azt a tanúsítványt fogadja el az oldaltól. Ha a tanúsítvány kompromittálódik, a kérelemmel új tanúsítványt szerez, melyet a kliens a korábbi kérelem-ujjlenyomat alapján fogad el.
Az ujjlenyomat használata azért fontos, hogy a tanúsítványkérelmet ne kelljen a szerveren tartani. A kérelmet új, nem az interneten tartott kulccsal célszerű aláírni (arra az esetre, ha a titkos kulcsot a szerverről megszereznék a támadók).
HSTS
szerkesztésA HSTS(en) azt jelenti, hogy a webszerver a https-válaszok fejlécébe olyan információt tesz, ami jelzi a böngészőnek, hogy ehhez a laphoz a fejlécben megadott ideig mindig https-sel kell fordulni. Ez akkor hasznos, ha a webszerver egyes URL-jei még mindig http protokollt tartalmaznak.
Pl. ha a wget parancssoros böngésző HSTS fejlécet kap, akkor a ~/.wget-hsts nevű fájlba ilyen információt tesz:
# HSTS 1.0 Known Hosts database for GNU Wget. # Edit at your own risk. # <hostname> <port> <incl. subdomains> <created> <max-age> hu.wikipedia.org 0 1 1505497215 106384710 |
1505497215 a HSTS-fejléc érkezési dátuma másodpercben. Magyar idő szerint 2017. szept. 15., péntek, 19:40:15. A második szám több mint három év, ugyancsak másodpercben. Ezt a magyar Wikipédia szervere küldte egy wget-es https-lekérdezésre. |
Használata az interneten
szerkesztés2017 januárjában a Chrome webböngésző az olyan weboldalakat, amelyek a titkosított HTTPS protokoll nélkül gyűjtenek adatokat, nem biztonságosként kezdte el megjelölni. Ez a módosítás várhatóan jelentős mértékben növeli majd a HTTPS használati arányát. 2017 februárjában a magyarországi domainnevek kb. 9,4%-ánál alkalmazták a HTTPS protokollt.[3]
Jegyzetek
szerkesztés- ↑ a b 2011-ben feltörték az egyik tanúsítóhelyet (a holland DigiNotar-t), és a nevében saját maguk számára adtak ki tanúsítványokat, ezzel a felhasználó számára észrevehetetlenül a kliensgép és a szerver (pl. az iráni gmail.com) közé tudtak ékelődni.
- ↑ a b 2008-ban és 2011-ben a StartCom nevű tanúsítóhely nevében adtak ki hamis tanúsítványt a PayPal.com és a Verisign – egy másik tanúsítóhely – számára.
- ↑ magyar internetes statisztikái dkers.hu (magyar nyelven). www.dkers.hu. [2017. február 6-i dátummal az eredetiből archiválva]. (Hozzáférés: 2017. február 5.)
Források
szerkesztés- GnuTLS kulcs és tanúsítványkérés generálása (Ubuntu dok.)
- OpenSSL Certificate Authority (saját CA létrehozása)
- How to create a self-signed SSL Certificate
- HowTo : Check SSL Certificate Expiration Date from the Linux Shell ([S]hell Hacks)
- SSL Security Error Mozilla SSL hibalista magyarázattal (mozillaZine)
- Pfeiffer Szilárd: Linuxakadémia online előadás (2018.01.31.)
- Scott Helme: HPKP: HTTP Public Key Pinning. scotthelme.co.uk (2015. január 20.) (Hozzáférés: 2018. február 20.)
- A CRL és az OCSP technológiák összehasonlítása. e-szigno (2008. november 19.) (Hozzáférés: 2018. február 21.) arch
További információk
szerkesztésIngyenes tanúsítóhelyek:
- Let's Encrypt
- Comodo
- Ingyen tanúsítvány (WikiKönyvek)
Egyéb:
- RFC 2818: HTTP Over TLS
- SSL 3.0 Specification (IETF)
- HTTPS Everywhere, az Electronic Frontier Foundation böngészőkiterjesztése
- Apache 2.4 mod_ssl documentation
- HTTPS Protocol in Internet Explorer Development - MSDN
- Manually Configuring Windows Communication Foundation (WCF) when using HTTP and HTTPS - MSDN
- HTTPS Security Improvements in Internet Explorer 7 & its Compatibility Impact - MSDN
- HTTP versus HTTPS, egy világos magyarázat