Tijela za izdavanje certifikata jedan su od najvažnijih temelja za internetsku sigurnost. Tijelo za izdavanje certifikata je netko kome svi vjeruju u početku, kada nitko ne vjeruje nikome drugome. Tada je to posao ovog tijela za izdavanje certifikata (a.k.CA) kako bi se osiguralo uspostavljanje povjerenja između poslužitelja i klijenata prije nego što uspostave komunikaciju putem Interneta.CA je važan ne samo za HTTPS koji koriste preglednici i web aplikacije, već i za šifrirane e-adrese, potpisana ažuriranja softvera, VPN-ove i još mnogo toga. Uzeti ćemo prototipski primjer HTTPS-a i naučiti o CA-u, ​​u ovom određenom kontekstu. Iako možete ekstrapolirati rezultat na bilo koji drugi programski paket.

Problemi s HTTP-om i običnim tekstom

Internet je nepovjerljivi kanal komunikacije. Kada šaljete ili primate podatke sa stare HTTP stranice http: //www.primjer.com u vašem se pregledniku puno stvari može dogoditi na pola puta do vaših paketa.

1. Loš glumac može presresti komunikaciju, kopirati podatke za sebe, prije nego što ih ponovo pošalje na kanal prema vama ili poslužitelju s kojim ste razgovarali. Bez znanja bilo koje strane, podaci su ugroženi. Moramo osigurati da komunikacija jest privatni.
2. Loš glumac može mijenjati informacije dok se šalju preko kanala. Bob je možda poslao poruku "x" ali Alice bi primila "Y" od Boba, jer je loš glumac presreo poruku i izmijenio je. Drugim riječima, integritet poruke je ugrožena.
3. I na kraju, i što je najvažnije, moramo osigurati da osoba s kojom razgovaramo zaista bude onakva za koju se kaže. Povratak na primjer.com domena. Kako možemo biti sigurni da je poslužitelj koji nam je odgovorio doista zakoniti nositelj www.primjer.com? U bilo kojem trenutku na mreži možete biti preusmjereni na drugi poslužitelj. DNS je negdje odgovoran za pretvaranje imena domene, poput www.primjer.com, u IP adresu na javnom Internetu. Ali vaš preglednik ne može provjeriti je li DNS preveo IP adresu.

Prva dva problema mogu se riješiti šifriranjem poruke prije nego što se pošalje Internetom na poslužitelj. Odnosno, prebacivanjem na HTTPS. Međutim, posljednji problem, problem identiteta je mjesto u kojem tijelo za izdavanje certifikata nastupa.

Pokretanje šifriranih HTTP sesija

Glavni problem šifrirane komunikacije preko nesigurnog kanala je „Kako ga pokrenuti?"

Prvi korak uključivao bi dvije strane, vaš preglednik i poslužitelj, da razmijene ključeve šifriranja koji će se razmjenjivati ​​preko nesigurnog kanala. Ako vam ključevi pojma nisu poznati, smatrajte ih stvarno dugom nasumično generiranom lozinkom kojom će vaši podaci biti šifrirani prije slanja preko nesigurnog kanala.

Pa, ako se ključevi šalju nesigurnim kanalom, svatko to može slušati i ugroziti sigurnost vaše HTTPS sesije u budućnosti. Štoviše, kako možemo vjerovati da ključ šalje server koji tvrdi da je www.primjer.com je stvarno stvarni vlasnik tog imena domene? Možemo imati šifriranu komunikaciju sa zlonamjernom stranom koja se maskira kao legitimno mjesto i ne znamo razliku.

Dakle, problem osiguranja identiteta važan je ako želimo osigurati sigurnu razmjenu ključeva.

Tijela za ovjeru

Možda ste čuli za LetsEncrypt, DigiCert, Comodo i nekoliko drugih usluga koje nude TLS certifikate za vaše ime domene. Možete odabrati onu koja odgovara vašim potrebama. Sada, osoba / organizacija koja je vlasnik domene mora na neki način dokazati svom tijelu za ovjere da zaista ima kontrolu nad domenom. To se može postići stvaranjem DNS zapisa s jedinstvenom vrijednošću u njemu, kako je zahtijevalo Tijelo za izdavanje certifikata, ili možete dodati datoteku na svoj web poslužitelj, sa sadržajem navedenim od strane Tijela za izdavanje certifikata, a CA tada može pročitati ovu datoteku i potvrdite da ste važeći vlasnik domene.

Zatim pregovarate o TLS certifikatu s CA-om, što rezultira privatnim ključem i javnim TLS certifikatom koji se izdaju na vašu domenu. Poruke šifrirane vašim privatnim ključem mogu zatim dešifrirati javni cert i obrnuto. To je poznato kao asimetrično šifriranje

Klijentski preglednici, poput Firefoxa i Chromea (ponekad čak i operativnog sustava) imaju znanje tijela za izdavanje certifikata. Te se informacije ubacuju u preglednik / uređaj od samog početka (to jest, kada su instalirane) kako bi znale da mogu vjerovati određenim CA-ovima. Sada, kada se pokušaju povezati na www.primjer.com preko HTTPS-a i vidjeti potvrdu koju je izdao, recimo DigiCert, preglednik zapravo može potvrditi da pomoću lokalno pohranjenih ključeva. Zapravo postoji još nekoliko posredničkih koraka, ali ovo je dobar pojednostavljeni pregled onoga što se događa.

Sada kada je potvrda koju je pružio www.primjer.com može se vjerovati, ovo se koristi za ugovaranje jedinstvenog simetričnog ključa šifriranja koji se koristi između klijenta i poslužitelja za ostatak njihove sesije. U simetričnom šifriranju jedan se ključ koristi za šifriranje kao i za dešifriranje i obično je puno brži od njegovog asimetričnog kolege.

Nijanse

Ako vam se ideja TLS-a i internetske sigurnosti sviđa, možete dodatno potražiti ovu temu kopajući po LetsEncrypt i njihovom besplatnom CA za TLS. Puno je više minuta do cijele ove rigmarole nego što je gore rečeno.

Drugi resursi koje mogu preporučiti za učenje više o TLS-u su Blog Troy Hunt-a i rad EFF-a poput HTTPS Everywhere i Certbot. Svi su resursi besplatni za pristup i stvarno jeftini za primjenu (samo morate platiti registraciju imena domene i VPS naknade po satu) i steći iskustvo.