Sertifikaadiasutused on Interneti-turvalisuse üks olulisemaid alustalasid. Sertifikaadi väljastaja on keegi, keda kõik usaldavad alguses, kui keegi kedagi teist ei usalda. Seejärel on selle sertifikaadiasutuse ülesanne (a.k.a) tagamaks, et serverite ja klientide vahel tekib usaldus enne Interneti-ühenduse loomist.CA pole oluline mitte ainult brauserite ja veebirakenduste kasutatava HTTPS-i jaoks, vaid ka krüptitud meilide, allkirjastatud tarkvarauuenduste, VPN-ide ja palju muu jaoks. Võtame HTTPS-i prototüüpse näite ja õpime CA-d selles konkreetses kontekstis. Kuigi saate tulemust ekstrapoleerida mis tahes muu tarkvarakomplektiga.

Probleemid HTTP ja tavalise tekstiga

Internet on ebausaldusväärne suhtluskanal. Vana HTTP-saidilt teabe saatmisel või vastuvõtmisel http: //www.näide.com brauseris võivad paljud asjad juhtuda teie pakettide keskel.

1. Halb näitleja võib suhtluse pealtkuulata, ise andmed kopeerida, enne kui see uuesti kanalil teie või serveri suunas, kellega rääkisite, uuesti saata. Kummagi poole teadmata on teave ohustatud. Peame tagama, et suhtlus oleks privaatne.
2. Halb näitleja saab teavet muuta, kui seda kanali kaudu saadetakse. Bob võis sõnumi saata "X" aga Alice saaks "Y" Bobilt, sest halb näitleja võttis sõnumi pealt ja muutis seda. Teisisõnu terviklikkus teade on ohustatud.
3. Lõpuks ja mis kõige tähtsam, peame tagama, et inimene, kellega räägime, on tõepoolest see, kellena nad end ütlevad. Tulles tagasi näide.com domeen. Kuidas saaksime veenduda, et meile vastanud server on tõepoolest www.näide.com? Teie võrgu mis tahes punktis võidakse teid valesti suunata teise serverisse. Kusagil asuv DNS vastutab domeeninime, näiteks www, teisendamise eest.näide.com, IP-aadressiks avalikus Internetis. Kuid teie brauseril pole võimalust kontrollida, kas DNS tõlgib IP-aadressi.

Esimesed kaks probleemi saab lahendada sõnumi krüpteerimisega, enne kui see Interneti kaudu serverile saadetakse. See tähendab, HTTPS-ile üle minnes. Kuid viimane probleem, identiteedi probleem, on see, kus mängib sertifikaadiasutus.

Krüpteeritud HTTP-seansside algatamine

Ebakindla kanali kaudu krüptitud suhtluse peamine probleem on „Kuidas me seda alustame?”

Esimene samm hõlmaks kaht osapoolt, teie brauserit ja serverit, et vahetada krüptovõtmed, mida vahetada ebaturvalisel kanalil. Kui terminivõtmed pole teile tuttavad, mõelge neist kui tõeliselt pikalt juhuslikult loodud paroolist, millega teie andmed enne ebaturvalisel kanalil saatmist krüpteeritakse.

Noh, kui võtmeid saadetakse ebaturvalisel kanalil, saavad kõik seda tulevikus kuulata ja ohustada teie HTTPS-seansi turvalisust tulevikus. Veelgi enam, kuidas saame usaldada, et võtme saadab server, kes väidab end olevat www.näide.com on tõepoolest selle domeeninime tegelik omanik? Meil võib olla krüpteeritud suhtlus pahatahtliku osapoolega, kes maskeerub seaduslikuks saidiks, ja ei tea erinevust.

Seega on identiteedi tagamise probleem oluline, kui soovime tagada turvalise võtmevahetuse.

Sertifikaadiasutused

Võib-olla olete kuulnud LetsEncryptist, DigiCertist, Comodost ja mõnest teisest teenusest, mis pakuvad teie domeeninime jaoks TLS-sertifikaate. Võite valida oma vajadustele vastava. Nüüd peab domeeni omanik / organisatsioon tõendama mingil viisil oma sertifikaadiasutusele, et neil on domeeni üle tõepoolest kontroll. Seda saab teha kas luua unikaalse väärtusega DNS-kirje vastavalt sertifikaadi väljaandja soovile või lisada veebiserverisse fail koos sertifikaadi väljaandja määratud sisuga. Seejärel saab CA seda faili lugeda ja kinnitage, et olete domeeni kehtiv omanik.

Seejärel pidate CA-ga läbirääkimisi TLS-sertifikaadi üle ja selle tulemuseks on teie domeenile välja antud privaatne võti ja avalik TLS-sertifikaat. Teie privaatse võtmega krüptitud sõnumid saab seejärel dekrüpteerida avaliku sertiga ja vastupidi. Seda nimetatakse asümmeetriliseks krüptimiseks

Kliendibrauserid, nagu Firefox ja Chrome (mõnikord isegi operatsioonisüsteem), tunnevad sertifikaadiasutusi. See teave küpsetatakse brauserisse / seadmesse juba algusest peale (st kui need on installitud), et nad teaksid, et nad võivad teatud CA-sid usaldada. Kui nad proovivad luua ühenduse veebisaidiga.näide.com HTTPS-i kaudu ja näeme DigiCerti välja antud sertifikaati, brauser saab tegelikult kontrollida, kas kohalikult salvestatud võtmeid kasutades. Tegelikult on selle juurde veel paar vahepealset sammu, kuid see on hea lihtsustatud ülevaade toimuvast.

Nüüd, kui sertifikaadi pakub www.näide.com-i võib usaldada, seda kasutatakse ainulaadse sümmeetrilise krüptovõtme läbirääkimisteks, mida kliendi ja serveri vahel kasutatakse ülejäänud seansiks. Sümmeetrilises krüptimisel kasutatakse ühte võtit nii krüptimiseks kui ka dekrüpteerimiseks ja see on tavaliselt palju kiirem kui asümmeetriline vaste.

Nüansid

Kui TLS-i ja Interneti-turvalisuse idee teid huvitab, saate seda teemat lähemalt uurida, uurides LetsEncrypt'i ja nende tasuta TLS-i CA-d. Kogu sellel rigmaroolil on palju rohkem üksikasju kui eespool öeldud.

Muud ressursid, mida saan TLS-i kohta lisateabe saamiseks soovitada, on Troy Hunti ajaveeb ja EFFi tehtud tööd, näiteks HTTPS Everywhere ja Certbot. Kõigile ressurssidele on tasuta juurdepääs ja nende rakendamine on tõesti odav (peate lihtsalt maksma domeeninime registreerimise ja VPS-i tunnitasude eest) ning saama kogemusi.