A hitelesítésszolgáltatók az internetes biztonság egyik legfontosabb sarokkövei. A tanúsító hatóság olyan valaki, akiben mindenki megbízik, kezdetben, amikor még senki sem bízik senki másban. Ezután ennek a tanúsító hatóságnak (más néven CA) az a feladata, hogy biztosítsa, hogy a szerverek és az ügyfelek között bizalom alakuljon ki, mielőtt az interneten keresztül kommunikálnának. a CA nemcsak a böngészők és webes alkalmazások által használt HTTPS esetében fontos, hanem a titkosított e-mailek, az aláírt szoftverfrissítések, a VPN-ek és még sok-sok minden más esetében is. A HTTPS prototípusos példáján keresztül fogjuk megismerni a hitelesítésszolgáltatót, ebben a konkrét kontextusban. Bár az eredményt bármely más szoftvercsomagra is kivetíthetjük.

Az internet egy nem megbízható kommunikációs csatorna. Amikor információt küld vagy fogad egy régi HTTP-oldalról http://www.example.com a böngészőjében, sok minden történhet a csomagok közepén.

1. Egy rossz szereplő elfoghatja a kommunikációt, lemásolhatja az adatokat magának, mielőtt újra elküldené azokat a csatornán Ön vagy a szerver felé, amellyel beszélt. Bármelyik fél tudta nélkül, az információ veszélybe kerül. Biztosítanunk kell, hogy a kommunikáció privát legyen.
2. Egy rossz szereplő módosíthatja az információt, miközben azt a csatornán keresztül küldik. Lehet, hogy Bob “x” üzenetet küldött, de Alice “y” üzenetet kap Bobtól, mert egy rossz szereplő elfogta az üzenetet, és módosította azt. Más szóval, az üzenet integritása sérül.
3. Végül, és ez a legfontosabb, meg kell bizonyosodnunk arról, hogy az a személy, akivel beszélünk, valóban az, akinek mondja magát. Visszatérve a example.com domainhez. Hogyan győződhetünk meg arról, hogy a nekünk válaszoló szerver valóban a www.example.com jogos tulajdonosa? A hálózat bármely pontján tévesen átirányíthatnak egy másik kiszolgálóra. Valahol egy DNS felelős azért, hogy egy tartománynevet, például a www.example.com-t, IP-címmé alakítson át a nyilvános interneten. A böngészője azonban nem tudja ellenőrizni, hogy a DNS lefordította-e az IP-címet.

Az első két probléma megoldható az üzenet titkosításával, mielőtt az interneten keresztül elküldi a kiszolgálónak. Vagyis a HTTPS-re való áttéréssel. Az utolsó probléma, az azonosság problémája azonban az, ahol a Tanúsítvány Hatóság lép a képbe.

Titkosított HTTP-munkamenetek kezdeményezése

A nem biztonságos csatornán keresztüli titkosított kommunikáció fő problémája: “Hogyan kezdjük el?”

A legelső lépés az lenne, hogy a két fél, a böngésző és a kiszolgáló kicserélje a titkosítási kulcsokat, amelyeket a nem biztonságos csatornán keresztül kell kicserélni. Ha nem ismeri a kulcsok fogalmát, gondoljon rájuk úgy, mint egy nagyon hosszú, véletlenszerűen generált jelszóra, amellyel az adatait titkosítják, mielőtt a nem biztonságos csatornán keresztül elküldik.”

Hát, ha a kulcsokat egy nem biztonságos csatornán keresztül küldik, bárki lehallgathatja azt, és a jövőben veszélyeztetheti a HTTPS-munkamenet biztonságát. Ráadásul hogyan bízhatunk abban, hogy a kulcs, amelyet egy magát www.example.com címnek valló szerver küld, valóban az adott domainnév tényleges tulajdonosa? Lehet, hogy titkosított kommunikációnk van egy rosszindulatú féllel, aki legitim webhelynek álcázza magát, és nem tudunk különbséget tenni.

Az azonosság biztosításának problémája tehát fontos, ha biztonságos kulcscserét szeretnénk biztosítani.

Tanúsítványhivatalok

Hallhatott már a LetsEncrypt, DigiCert, Comodo és néhány más szolgáltatásról, amelyek TLS tanúsítványokat kínálnak a domain nevéhez. Kiválaszthatja az igényeinek megfelelőt. Most a domain-tulajdonos személynek/szervezetnek valamilyen módon bizonyítania kell a tanúsítványkiadó hatóságnak, hogy valóban ő rendelkezik a domain felett. Ezt megteheti úgy, hogy vagy létrehoz egy DNS-rekordot egy egyedi értékkel, amelyet a Tanúsítványkezelő kér, vagy hozzáad egy fájlt a webszerveréhez, amelynek tartalmát a Tanúsítványkezelő határozza meg, a Tanúsítványkezelő ezt a fájlt el tudja olvasni, és meg tudja erősíteni, hogy Ön a domain érvényes tulajdonosa.

Ezután tárgyal a Tanúsítványkezelővel egy TLS-tanúsítványról, és ennek eredményeként egy privát kulcsot és egy nyilvános TLS-tanúsítványt állítanak ki a domainjéhez. A magánkulccsal titkosított üzeneteket ezután a nyilvános tanúsítvány segítségével lehet visszafejteni, és fordítva. Ezt aszimmetrikus titkosításnak nevezik

A kliensböngészők, mint a Firefox és a Chrome (néha még az operációs rendszer is) rendelkeznek a Certificate Authorities ismeretével. Ezt az információt már a kezdetektől fogva (vagyis a telepítéskor) beépítik a böngészőbe/készülékbe, így tudják, hogy megbízhatnak bizonyos hitelesítésszolgáltatókban. Most, amikor megpróbálnak HTTPS-en keresztül csatlakozni a www.example.com oldalra, és egy, mondjuk a DigiCert által kiállított tanúsítványt látnak, a böngésző ezt a helyben tárolt kulcsok segítségével ellenőrizni tudja. Valójában van még néhány további köztes lépés, de ez egy jó egyszerűsített áttekintés arról, hogy mi történik.

Most, hogy a www.example.com által biztosított tanúsítvány megbízható, ez egy egyedi szimmetrikus titkosítási kulcs egyeztetésére szolgál, amelyet az ügyfél és a kiszolgáló a munkamenet hátralévő részében használ. A szimmetrikus titkosításnál egy kulcsot használnak a titkosításhoz és a visszafejtéshez is, és általában sokkal gyorsabb, mint aszimmetrikus társa.

Nuance

Ha a TLS és az internetes biztonság gondolata tetszik Önnek, akkor a LetsEncrypt és az ingyenes TLS CA-jukban való kutakodással mélyebben beleáshatja magát a témába. Sokkal több minutiate van ebben az egész rigmarole-ban, mint amit fentebb leírtunk.