Certifikacijski organi so eden najpomembnejših temeljev za internetno varnost. Overitelj je tisti, ki mu vsi zaupajo na začetku, ko nihče ne zaupa nikomur. Nato je naloga tega overitelja (a.k.CA), da se zagotovi vzpostavitev zaupanja med strežniki in odjemalci, preden vzpostavijo komunikacijo prek interneta.CA ni pomemben samo za HTTPS, ki ga uporabljajo brskalniki in spletne aplikacije, ampak tudi za šifrirana e-poštna sporočila, podpisane posodobitve programske opreme, VPN-je in še veliko več. Vzeli bomo prototipni primer HTTPS in se v tem posebnem kontekstu seznanili s CA. Rezultat lahko ekstrapolirate na katero koli drugo programsko opremo.

Težave s HTTP in navadnim besedilom

Internet je nezaupljiv komunikacijski kanal. Ko pošiljate ali prejemate informacije s starega spletnega mesta HTTP http: //www.primer.com v vašem brskalniku se lahko veliko stvari zgodi sredi vaših paketov.

1. Slab igralec lahko prestreže komunikacijo, kopira podatke zase, preden jih znova pošlje na kanal do vas ali strežnika, s katerim ste govorili. Brez vednosti obeh strani so informacije ogrožene. Zagotoviti moramo, da je komunikacija takšna zasebno.
2. Slab igralec lahko spremeni informacije, ko se pošiljajo po kanalu. Bob je morda poslal sporočilo "X" ampak Alice bi prejela "Y" od Boba, ker je slab igralec prestregel sporočilo in ga spremenil. Z drugimi besedami, celovitost sporočila je ogroženo.
3. Nazadnje in kar je najpomembneje, moramo zagotoviti, da je oseba, s katero se pogovarjamo, res taka, za katero pravi, da je. Nazaj na primer.com domena. Kako lahko zagotovimo, da je strežnik, ki nam je odgovoril, res upravičeni imetnik www.primer.com? Kadar koli v vašem omrežju ste lahko napačno preusmerjeni na drug strežnik. DNS nekje je odgovoren za pretvorbo imena domene, na primer www.primer.com v naslov IP na javnem internetu. Toda vaš brskalnik ne more preveriti, ali je DNS prevedel naslov IP.

Prvi dve težavi lahko rešite s šifriranjem sporočila, preden ga pošljete prek interneta na strežnik. Se pravi s prehodom na HTTPS. Vendar pa je zadnji problem, problem identitete, v tem, kje v veljavo pride overitelj potrdil.

Začetek šifriranih sej HTTP

Glavna težava šifrirane komunikacije prek negotovega kanala je »Kako jo zaženemo?"

Prvi korak bi vključeval obe strani, vaš brskalnik in strežnik, da bi izmenjali šifrirne ključe, ki bi jih izmenjali po nezanesljivem kanalu. Če ključev izraza ne poznate, si jih oglejte kot res dolgo naključno generirano geslo, s katerim bodo vaši podatki šifrirani, preden jih pošljete po negotovem kanalu.

No, če se ključi pošiljajo po negotovem kanalu, lahko kdor koli posluša to in ogrozi varnost vaše seje HTTPS v prihodnosti. Poleg tega, kako lahko zaupamo, da ključ pošlje strežnik, ki trdi, da je www.primer.com je dejanski lastnik tega imena domene? Lahko imamo šifrirano komunikacijo z zlonamerno stranko, ki se predstavlja kot zakonito spletno mesto in ne vemo razlike.

Torej je problem zagotavljanja identitete pomemben, če želimo zagotoviti varno izmenjavo ključev.

Certifikacijski organi

Morda ste že slišali za LetsEncrypt, DigiCert, Comodo in nekaj drugih storitev, ki ponujajo potrdila TLS za vaše domensko ime. Izberete lahko tistega, ki ustreza vašim potrebam. Zdaj mora oseba / organizacija, ki je lastnik domene, na nek način dokazati svojemu overitelju, da ima nadzor nad domeno. To lahko storite tako, da ustvarite zapis DNS z edinstveno vrednostjo, kot zahteva certifikacijski organ, ali pa na svoj spletni strežnik dodate datoteko z vsebino, ki jo določi certifikacijski organ, CA pa lahko nato prebere to datoteko in potrdite, da ste veljavni lastnik domene.

Nato se s CA-jem dogovorite za potrdilo TLS, kar povzroči, da se vaši domeni izda zasebni ključ in javno potrdilo TLS. Sporočila, ki jih šifrira vaš zasebni ključ, lahko nato dešifrira javni cert in obratno. To je znano kot asimetrično šifriranje

Odjemalski brskalniki, kot sta Firefox in Chrome (včasih celo operacijski sistem), poznajo certifikacijske organe. Te informacije se v brskalnik / napravo vnesejo že od samega začetka (se pravi, ko so nameščene), tako da vedo, da lahko zaupajo določenim overiteljem. Zdaj, ko se poskušajo povezati na www.primer.com prek HTTPS in si oglejte potrdilo, ki ga je izdal, recimo DigiCert, brskalnik lahko dejansko preveri, ali z lokalno shranjenimi ključi. Pravzaprav obstaja še nekaj posredniških korakov, vendar je to dober poenostavljen pregled dogajanja.

Zdaj, ko potrdilo, ki ga je zagotovil www.primer.com je mogoče zaupati, to se uporablja za izpopolnjevanje edinstvenega simetričnega šifrirnega ključa, ki se med odjemalcem in strežnikom uporablja za preostanek njihove seje. Pri simetričnem šifriranju se za šifriranje in dešifriranje uporablja en ključ, ki je običajno veliko hitrejši od asimetričnega kolega.

Odtenki

Če vas ideja TLS in internetne varnosti privlači, lahko to temo poglobite še naprej, tako da se poglobite v LetsEncrypt in njihov brezplačni CA za TLS. Na tej celotni rigmaroli je veliko več minut, kot je navedeno zgoraj.

Drugi viri, ki jih lahko priporočim za učenje več o TLS, so Blog Troy Hunt-a in delo EFF, kot sta HTTPS Everywhere in Certbot. Vsi viri so brezplačni in resnično poceni za uporabo (za registracijo domenskih imen morate plačati le urne postavke VPS) in pridobiti izkušnje.