Mit véd a HTTPS, és mit nem?

Célok

A lecke végére meg tudod mondani, mit véd és mit nem véd a HTTPS, el tudod magyarázni a tanúsítványhibák, a vegyes tartalom és a HSTS szerepét, és érted, miért nem jelent „hibátlan alkalmazást” a böngésző lakat ikonja.

Miért kell külön lecke a HTTPS-nek?

A HTTPS a leggyakoribb védelem a weben, ezért a legtöbb tévhit is hozzá kapcsolódik. „Van lakat, tehát biztonságos az oldal.” Ez nem igaz, de nem is hamis: a lakat egy konkrét, szűk állítást támaszt alá. Aki pontosan tudja, mit véd a HTTPS, nem bízik benne többet a kelleténél, és nem hagyja ki ott, ahol szükség van rá. A 8. fejezetben ugyanerre a tudásra építünk, amikor az alkalmazás hibáit tárgyaljuk.

Védett kapcsolat egy nyilvános hálózaton

A HTTPS a HTTP-üzenetek továbbítása TLS-védelemmel. Egy hallgató nyilvános Wi-Fi-n bejelentkezik a Kurzuspontba. A köztes hálózat továbbítja a forgalmat, ezért érdemes megkérdezni, mit láthat vagy változtathat meg. Ha a böngésző érvényes HTTPS-kapcsolatot épített a kívánt domainhez, a kérés és a válasz tartalma TLS-védelem alatt halad: egy kívülálló nem tudja egyszerűen elolvasni, és észrevétlenül átírni sem.

flowchart LR
    B[Böngésző] -->|TLS-sel védett HTTP| S[Webes végpont]
    K[Köztes hálózat] -. továbbítja, de a tartalmat nem olvassa .-> B

Az ábra nem teljes láthatatlanságot ígér. A kapcsolat léte, időzítése, mennyisége és egyes címzési adatok megfigyelhetők lehetnek. A „titkosított” nem azt jelenti, hogy a felhasználó minden tevékenysége rejtve marad.

Három védelmi tulajdonság

Tulajdonság	Mit véd?
Titkosság	Az átvitt tartalom olvasása ellen.
Sértetlenség	Az ellen, hogy az üzenetet útközben észrevétlenül módosítsák.
Hitelesítés	A böngésző ellenőrzi, hogy a megnyitott domainhez tartozó szerverrel beszél.

A három együtt ad értelmet a védelemnek: titkosítás nélküli hitelesítés vagy hitelesítés nélküli titkosítás nem elég, mert egy támadó a titkosított csatornán is a saját szerverével szólhatna.

Mi történik, ha a tanúsítvány hibás?

Ha a tanúsítvány nem érvényes a megnyitott domainre, a böngésző megáll, mielőtt HTTP-kérést küldene. Ez más típusú hiba, mint a 404: ott már HTTP-válasz van. Három tipikus tanúsítványhiba valódi példája a curl-ből, a badssl.com nevű tesztoldal (amelyet a böngészők TLS-viselkedésének kipróbálására hoztak létre, és a Chromium forrásából is ismert) szándékosan hibás szervereivel:

$ curl https://expired.badssl.com/
curl: (60) SSL certificate problem: certificate has expired

$ curl https://wrong.host.badssl.com/
curl: (60) SSL: no alternative certificate subject name matches target host name 'wrong.host.badssl.com'

$ curl https://self-signed.badssl.com/
curl: (60) SSL certificate problem: self signed certificate

• lejárt tanúsítvány: az érvényességi idő letelt;
• rossz hosztnév: a tanúsítvány nem az elért névre szól;
• önaláírt tanúsítvány: nincs mögötte a böngésző által ismert hitelesítésszolgáltató.

A curl hibakódot ad, a böngésző pedig figyelmeztető oldalt. Utóbbin a „folytatás” gomb megkerüli a védelmet: ha a felhasználó átlép rajta, a titkosítás megmarad, de már nem tudja, kivel beszél. Ezért a figyelmeztetés figyelmen kívül hagyása éppen a lényeget gyengíti.

A védelem határai

Konkrétan a HTTPS nem:

• igazolja, hogy a szolgáltató megbízható. Egy megtévesztő (adathalász) oldal is kaphat érvényes tanúsítványt a saját nevére. A felhasználónak az URL nevét és a szolgáltatás összefüggését is értelmeznie kell.
• véd az alkalmazás hibái ellen: a HTTPS-sel továbbított oldal is tartalmazhat XSS-hibát (injektált szkript), rossz jogosultságkezelést vagy hibás CORS-beállítást (8. fejezet). Az injekciót sem állítja meg: a támadó adata titkosított csatornán is eljut a szerverhez.
• véd a szerver ellen: a kapcsolat másik végén lévő fél látja a tartalmat.
• fedi el az összes metaadatot (lásd fent).
• véd a TLS-végpont mögötti szakaszon. Ha reverse proxy bontja a TLS-t (lásd 4.4), a böngésző és a proxy közötti védelem nem terjed ki automatikusan a proxy és az alkalmazásszerver közötti szakaszra. A teljes út határozza meg, hol kell még védeni a kommunikációt.

flowchart LR
    B[Böngésző] -->|HTTPS / TLS| P[TLS-végpont: proxy]
    P -->|belső kapcsolat: külön védelem kérdése| A[Alkalmazás]
    A --> D[(Adatbázis)]

Vegyes tartalom

Ha egy HTTPS-oldal nem védett (HTTP) erőforrást próbál betölteni, vegyes tartalom (mixed content) jön létre. Az MDN szerint a gyenge pont az, hogy egy támadó látja vagy módosítja a nem védett erőforrást, a szkript pedig különösen veszélyes, mert az oldal bármely részét átírhatja. A jelenlegi szabály két kategóriát különböztet meg: a frissíthető tartalmat (például képek, hang, videó) a böngésző https-re írja át, a blokkolandó tartalmat (például szkriptek, stíluslapok, fetch() hívások) viszont letiltja. A javítás: minden erőforrás HTTPS-en vagy relatív címen töltődjön be.

HSTS: a lefokozás megakadályozása

Mi történik, ha a felhasználó csak annyit ír be, hogy kurzuspont.example? A böngésző először http:// címre fordulhat, ahonnan a szerver https://-re irányít át:

$ curl -I http://github.com
HTTP/1.1 301 Moved Permanently
Location: https://github.com/

Ez az első HTTP-kérés védetlen: egy támadó útközben megakaszthatja, és „lefokozhatja” a kapcsolatot. A HSTS (HTTP Strict Transport Security) ezt oldja meg: a szerver a Strict-Transport-Security fejléccel közli, hogy a hosztot a továbbiakban csak HTTPS-en szabad elérni.

$ curl -sI https://github.com | grep -i strict
strict-transport-security: max-age=31536000; includeSubdomains; preload

A max-age másodpercben adja meg, meddig jegyezze meg a böngésző a szabályt (31 536 000 másodperc egy év). Az MDN szerint a includeSubDomains az aldomainekre is kiterjeszti; a szabály csak az első HTTPS-látogatás után lép érvénybe, ezért a preload lista megoldása az, hogy a hosztok listája a böngészőkbe van építve. Érvényes szabály mellett a böngésző az http címet még a kapcsolat felépítése előtt https-re írja át, és a tanúsítványhibát a felhasználó nem tudja átlépni. HTTP-n kapott HSTS-fejlécet a böngésző figyelmen kívül hagy.

A munkamenet-cookie Secure attribútuma ugyanebbe a gondolatba illik: biztosítja, hogy a böngésző a cookie-t ne küldje egyszerű HTTP-n (lásd 7.2).

Végigvezetett példa: a Kurzuspont HTTPS-beállítása

Kérdés	Megoldás
A bejelentkezés és a jelentkezés védett legyen	A teljes oldal HTTPS-en fut.
Az http:// cím átirányítson	301 https-re.
A lefokozás ne legyen lehetséges	HSTS-fejléc, hosszú max-age-gel.
Vegyes tartalom ne maradjon	A logó, a stíluslap és a szkript is HTTPS-en vagy relatív címen töltődik.
A belső szakasz is legyen védett	A reverse proxy és az alkalmazás közötti kapcsolat is titkosított, vagy zárt hálózaton fut.
A lakat nem elég	Az alkalmazás hibáit a 8. fejezet eszközeivel kell megelőzni.

Gyakori tévhitek

Állítás	Pontosítás
„A HTTPS-es oldal biztosan megbízható.”	A kapcsolat védelme nem bizonyítja a szolgáltató jó szándékát.
„A titkosítás minden hálózati adatot elrejt.”	A kapcsolat egyes metaadatai láthatók lehetnek.
„A tanúsítvány a tartalom igazságát garantálja.”	A névhez kötött kapcsolat ellenőrzésében segít.
„A tanúsítványhiba egy HTTP 404.”	A TLS-ellenőrzés a HTTP-válasz előtt állíthatja meg a folyamatot.
„A TLS a belső szakaszokat is automatikusan védi.”	A TLS-végpont után külön szakasz lehet.

Röviden

• A HTTPS titkosságot, sértetlenséget és szerverhitelesítést ad a HTTP-forgalomnak.
• Tanúsítványhibánál a böngésző megáll, mielőtt HTTP-kérést küldene.
• A HTTPS nem minősíti a szolgáltatót, és nem véd az alkalmazás hibái ellen.
• A vegyes tartalom gyengíti a védelmet; a HSTS megakadályozza a lefokozást.
• A teljes út védelme a TLS-végpont mögött is kérdés.

Ellenőrző kérdések

1. Miért kaphat adathalász oldal is érvényes tanúsítványt?
2. Mi a különbség egy tanúsítványhiba és egy 404 között?
3. Mi a vegyes tartalom, és miért veszélyes egy HTTPS-oldalon?
4. Mit jelent a HSTS, és miért nem véd az első látogatáskor?

Tanulási források

• Transport Layer Security (MDN) — a TLS és a HTTPS kapcsolata angolul.
• Mixed content (MDN) — a vegyes tartalom és a böngészők kezelése.
• Strict-Transport-Security (MDN) — a HSTS részletei.
• badssl.com — tesztoldalak szándékosan hibás TLS-beállításokkal.