A tanúsító hatóságok az internetes biztonság egyik legfontosabb sarokköve. A tanúsító hatóság olyan személy, akiben mindenki megbízik az elején, amikor senki sem bízik senki másban. Ezután ennek a tanúsító hatóságnak a feladata (a.k.egy CA) annak biztosítása érdekében, hogy a szerverek és az ügyfelek között bizalom jöjjön létre, mielőtt az interneten keresztül kommunikációt létesítenek.A CA nem csak a böngészők és a webalkalmazások által használt HTTPS, hanem a titkosított e-mailek, az aláírt szoftverfrissítések, a VPN-ek és még sok más szempontjából is fontos. Vesszük a HTTPS prototípusos példáját, és megismerjük a CA-t, ebben a konkrét összefüggésben. Bár az eredményt bármely más szoftvercsomagra extrapolálhatja.

Problémák a HTTP és az egyszerű szöveggel

Az Internet nem megbízható kommunikációs csatorna. Amikor régi HTTP-webhelyről küld információt vagy információt, http: //www.példa.com böngészőjében sok minden történhet csomagjainak közepén.

1. Egy rossz színész képes lehallgatni a kommunikációt, lemásolni az adatokat maguknak, mielőtt újra elküldenék azokat a csatornán feléd vagy a szerver felé, akivel beszéltél. Bármelyik fél tudta nélkül az információ veszélybe kerül. Biztosítanunk kell a kommunikációt magán.
2. Egy rossz színész módosíthatja az információkat, ahogy azokat a csatornán továbbítják. Lehet, hogy Bob üzenetet küldött "x" de Alice megkapja „Y” Bobtól, mert egy rossz színész elfogta az üzenetet, és módosította. Más szavakkal, a sértetlenség üzenet sérül.
3. Végül, és ami a legfontosabb, biztosítanunk kell, hogy az a személy, akivel beszélgetünk, valóban az, akinek mondják magukat. Visszatérve a példa.com tartomány. Hogyan győződhetünk meg arról, hogy az a szerver, amely válaszolt nekünk, valóban a www jogos tulajdonosa.példa.com? A hálózat bármely pontján rosszul irányíthat egy másik szerverre. Egy DNS valahol felelős a domain név, például a www konvertálásáért.példa.com, a nyilvános internet IP-címére. De a böngészője 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 azt az interneten keresztül elküldené a szerverre. Vagyis a HTTPS-re való áttéréssel. Azonban az utolsó probléma, az Identitás problémája az, ahol a tanúsító hatóság játszik szerepet.

Titkosított HTTP munkamenetek kezdeményezése

A nem biztonságos csatornán történő titkosított kommunikáció fő problémája: „Hogyan kezdjük el?”

A legelső lépés a két fél, a böngésző és a szerver bevonásával járna a bizonytalan csatornán cserélendő titkosítási kulcsok cseréjével. Ha nem ismeri a kifejezéskulcsokat, gondoljon rájuk, mint egy valóban hosszú, véletlenszerűen generált jelszóra, amellyel titkosítják adatait, mielőtt elküldenék őket a nem biztonságos csatornán.

Nos, ha a kulcsokat nem biztonságos csatornán küldik, akkor bárki meghallgathatja ezt, és a jövőben veszélyeztetheti a HTTPS munkamenet biztonságát. Sőt, hogyan bízhatunk abban, hogy a kulcsot egy szerver állítja, amely www.példa.com valóban a tulajdonosa ennek a domain névnek? Titkosított kommunikációt folytathatunk egy törvényes webhelynek álcázott rosszindulatú féllel, és nem tudjuk a különbséget.

Tehát az identitás biztosításának problémája fontos, ha biztos kulcscserét akarunk biztosítani.

Igazoló hatóságok

Lehet, hogy hallott a LetsEncrypt, a DigiCert, a 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 azt, amelyik megfelel az igényeinek. A domaint birtokló személynek / szervezetnek valamilyen módon igazolnia kell a tanúsító hatóságának, hogy valóban rendelkezik a domain feletti ellenőrzéssel. Ezt úgy teheti meg, hogy létrehoz egy DNS-rekordot, benne egyedi értékkel, a tanúsító hatóság kérésére, vagy felvehet egy fájlt a webkiszolgálóra, a tanúsító hatóság által megadott tartalommal. A CA ezután elolvassa ezt a fájlt. és erősítse meg, hogy Ön a domain érvényes tulajdonosa.

Ezután egyeztet egy TLS-tanúsítványt a CA-val, és ez egy magánkulcsot és egy nyilvános TLS-tanúsítványt eredményez a domainjéhez. A magánkulcsával titkosított üzeneteket ezután visszafejtheti a nyilvános tanúsítvány és fordítva. Ezt aszimmetrikus titkosításnak nevezik

Az ügyfélböngészők, például a Firefox és a Chrome (néha még az operációs rendszer is) rendelkeznek a tanúsító hatóságok ismereteivel. Ez az információ a kezdetektől fogva bekerül a böngészőbe / eszközbe (vagyis amikor telepítve vannak), így tudják, hogy megbízhatnak bizonyos CA-kban. Most, amikor megpróbálnak csatlakozni a www-hez.példa.com HTTPS-en keresztül, és lásd a DigiCert által kiállított tanúsítványt, a böngésző valóban ellenőrizheti, hogy a helyben tárolt kulcsok használatával. Valójában van még néhány közvetítő lépés, de ez egy jó egyszerűsített áttekintés a történésekről.

Most, hogy a tanúsítványt a www.példa.A com megbízható, ez egy egyedi szimmetrikus titkosítási kulcs megtárgyalására szolgál, amelyet a kliens és a szerver használ a munkamenet hátralévő részében. A szimmetrikus titkosítás során egy kulcsot használnak a titkosításhoz és a visszafejtéshez is, és általában sokkal gyorsabb, mint aszimmetrikus megfelelője.

Árnyalatok

Ha a TLS és az internetbiztonság ötlete vonzza Önt, akkor a LetsEncrypt és az ingyenes TLS CA-jába mélyedve tovább vizsgálhatja ezt a témát. Sokkal több apróság van ennek az egész rigmarole-nak, mint fentebb említettük.

Egyéb források, amelyeket ajánlani tudok a TLS-ről, Troy Hunt blogja és az EFF által végzett munka, például a HTTPS Everywhere és a Certbot. Az összes erőforrás szabadon hozzáférhető és nagyon olcsó a megvalósításhoz (csak fizetnie kell a domain név regisztrációjáért és a VPS óradíjáért), és gyakorlati tapasztalatokat szerezzen.