Kriptográfia a hálózati kommunikációban: TLS és SSL

Manapság minden olyan weboldalnál, ami valamilyen módon személyes adatot kér be tőlünk elvárás, hogy titkosítottan kommunikáljon a böngészőnk és a távoli szerver között. Ez a legtöbb esetben HTTPS protokoll segítségével valósul meg. Azonban a titkosított hálózati adatátvitel ötlete már 1987-ben felmerült. Hosszas egyeztetések után 1995-ben került elfogadásra a SSL 2.0 specifikáció, ami lehetővé tette alkalmazások számára, hogy titkosítva kommunikáljanak.

Az SSL (Secure Sockets Layer) protokoll 1.0-ás változata sosem lett kiadva, mivel még a kiadása előtt biztonsági hibákat találtak benne. A 2.0-ás változatot egy évvel később váltotta a 3.0-ás változat. A váltás oka annak volt köszönhető, hogy az SSL 2.0-ás változata nem tette lehetővé azt, hogy egy szerver több domaint is kiszolgáljon (virtuális web hosting -a mai weboldalak nagy része ilyen módon kerül kiszolgálásra), ami az internet növekedésének köszönhetően egyre több oldalt zárt ki az SSL használatának lehetőségéből.

Az SSL-t 1999-ben váltotta a TLS (Transport Layer Security) megjelenése, ami a 3.0-ás SSL továbbfejlesztett változatának tekinthető. A névváltást az indokolta, hogy a SSL eredetileg egy Netscape által fejlesztett protokoll volt és az IETF¹ nem akarta még véletlenül sem annak a látszatát kelteni, hogy egy specifikus gyártó protokollját favorizálja.

A TLS-ből jelenleg az 1.3-as változat a legfrissebb. Ezt 2018-ban publikálták és egyre szélesebb körben adaptált. A protokollok korábbi verzióit időközben kivezették, mivel a bennük definiált hash és titkosítási algoritmusokról bebizonyosodott, hogy nem biztonságosak.

Az alábbi táblázat a protokollok jelenlegi státuszát foglalja össze:

A különböző TLS és SSL verziók elavulását és ennek szükségességét egy példán keresztül a legegyszerűbb bemutatni. Tételezzük fel, hogy a böngészőnkkel csatlakozni szeretnénk a https://example oldalhoz. Ebben az esetben a böngésző felveszi a kapcsolatot a szerverrel és elkezdik lefixálni, hogy melyik TLS protokollt szeretnék használni. Ez az alapján dől el, hogy a szerver mit támogat és böngésző mit támogat. Ideális esetben a legfrissebbet, de a szerver válaszolhat úgy, hogy ő csak a TLS 1.0-t támogatja.

Ebben az esetben a böngészőnk el fogja utasítani és el is kell utasítania a kapcsolatot, mivel a biztonságot nem tudja garantálni, köszönhetően annak, hogy a protokoll korábbi verziójában használt algoritmusok vagy elavultak és nem biztonságosak, vagy az algoritmus implementációja bizonyos körülmények között sebezhető.

Fontos kiemelni a bizonyos körülmények fontosságát. Egy ilyen körülmény például a szerver által használt kulcs digitális aláírásában használt Hash algoritmus. Az MD5 és az SHA-1 már elavultnak számít, ennek köszönhetően egyetlenegy tanúsítványkibocsájtó sem alkalmazza már őket a gyakorlatban, de csak a TLS 1.3-as verziója tiltja ezen aláírások elfogadását explicit módon.

A TLS hálózati szempontból

Hálózati szempontból nézve a TLS nem illeszthető be az OSI vagy TCP/IP modell egy rétegébe sem, mivel működéséhez kell egy megbízható szállítási protokoll (pl. TCP). Ez azt jelenti, hogy ez felett kellene állnia rétegzési szempontból, de a magasabb rétegek titkosítását szolgálja. Ez pedig klasszikus OSI terminológiában a megjelenítési réteg feladata lenne.

Az alkalmazások azonban általában úgy használják a TLS-t, mintha egy szállítási réteg lenne, annak ellenére, hogy a TLS-t használó alkalmazásoknak aktívan kell irányítaniuk a TLS-kézfogások kezdeményezését és a kicserélt hitelesítési tanúsítványok kezelését.

A TLS működése

Az RSA alkalmazásánál említettem, hogy hálózati átvitel és nagy méretű adatok esetén nem igen ideális, mivel lassú. Ez a tény a kulcsméret növekedésével még ma is probléma. Éppen ezért TLS esetén a hálózati kommunikáció egy szimmetrikus kulcsos algoritmus által titkosítva történik. Ennek oka az, hogy az AES igen gyors és manapság minden modern hardverben megtalálható.

A probléma az, hogy hogyan jut két fél ugyanarra a titkosítási kulcsra egy még nem megbízható csatornán? Itt jön be a képbe a korábban tárgyalt Diffie–Hellman algoritmus. A felek hitelesítését pedig valamilyen nyílt kulcsú digitális aláírással oldják meg.

TLS és .NET

A modern alkalmazásfejlesztésben elkerülhetetlen, hogy előbb-utóbb ne kelljen valami API-t vagy egyéb szolgáltatást igénybe vennünk az internetről. Ezek az API-k manapság leginkább HTTP és HTTPS felett vannak megvalósítva, ezért a .NET-nek is támogatnia kell a TLS különböző verzióit.

A támogatás két kategóriára bontható. Kliens, avagy fogyasztói oldalon a WebClient, HttpClient és WebRequest osztályok jöhetnek szóba. Ezek közül a WebClient a legrégebbi. Ez még a .NET Framework életének elején mutatkozott be és mára már elavultnak számít és későbbi verziókban kivezetésre kerülhet. Ez TLS 1.2-t támogat maximum.

Helyette a HttpClient alkalmazása javasolt, ami rendelkezik TLS 1.3 támogatással és modern API-nak megfelelően aszinkron hívási lehetőségekkel.

A WebRequest anno kifejezetten webes API hívások fogyasztására lett kitalálva. Ez jelenleg még támogatott, de új kód írásánál használata nem javasolt, helyette a Microsoft szintén a HttpClient alkalmazását preferálja.

Szerver oldalon ‘klasszikus’ (.NET Framework alapú) ASP.NET esetén a HTTPS funkció megvalósítása a hostolást végző szerver feladata, ami általában egy IIS, ami valami Windows szerveren fut. A Core óta azonban az ASP.NET alkalmazások egy saját webszerverrel rendelkeznek, ami az alkalmazásba fordul bele. Ez a szerver a Microsoft.AspNetCore.Hosting NuGet csomagban található és szintén rendelkezik TLS támogatással. Előnye, hogy ASP.NET-en kívül bármilyen .NET alkalmazásba beépíthető.

A harmadik megoldás a HttpListener, ami a .NET Framework 2.0-ban mutatkozott be. Ez a szerver a Windows beépített HTTP rétegét alkalmazza és szintén használható HTTPS kiszolgálásra is. Hátránya, hogy ha HTTPS-re szeretnénk konfigurálni, akkor a Windows netsh parancsán keresztül tudjuk megtenni, ami nem feltétlen triviális. .NET Core 2.0 óta multiplatform, így akár Linux vagy OS-X rendszereken is használható. Komoly hosting célokra azonban nem alkalmas, mivel ez a szerver egy gépen belüli vagy helyi hálózaton belüli kapcsolatok fogadására lett kitalálva és inkább hasonlít egy építőkockára, mint egy tényleges HTTP/HTTPS szerverre.

TLS/SSL tanúsítvány igénylése

A TLS/SSL működéséhez szükség lesz egy tanúsítványra, amit egy 3. megbízható fél állított ki. Egy ilyen tanúsítvány a megbízható féltől függően elég sokba is kerülhet. Ingyenesen 90 napra érvényes tanúsítvány a Let’s Encrypt-en keresztül igényelhető.

Ez a megoldás publikusan elérhető (DNS bejegyzéssel rendelkező és 80-as porton kapcsolatokat fogadó) weblapokra alkalmazható.

Ha ilyen cert fájlt szeretnénk beszerezni, akkor ez az EFF által fejlesztett certbot segítségével a legkönnyebb. A certbot a https://certbot.eff.org/ címről szerezhető be és nagyon részletes leírással rendelkezik a különböző operációs rendszerekre a használatát illetően.