Sertifikātu iestādes ir viens no vissvarīgākajiem stūrakmeņiem interneta drošībā. Sertifikāta iestāde ir persona, kurai visi uzticas sākumā, kad neviens neuzticas nevienam citam. Tad šīs sertifikācijas iestādes uzdevums ir (a.k.CA), lai nodrošinātu, ka starp serveriem un klientiem tiek izveidota uzticība, pirms viņi izveido saziņu internetā.CA ir svarīga ne tikai HTTPS, ko izmanto pārlūkprogrammas un tīmekļa lietotnes, bet arī šifrētiem e-pastiem, parakstītiem programmatūras atjauninājumiem, VPN un daudz ko citu. Mēs ņemsim HTTPS prototipisko piemēru un uzzināsim par CA šajā konkrētajā kontekstā. Lai gan jūs varat ekstrapolēt rezultātu jebkuram citam programmatūras komplektam.

Problēmas ar HTTP un vienkāršu tekstu

Internets ir neuzticams saziņas kanāls. Sūtot vai saņemot informāciju no vecās HTTP vietnes http: //www.piemērs.com pārlūkprogrammā daudzas lietas var notikt jūsu paku vidū.

1. Slikts aktieris var pārtvert saziņu, kopēt datus sev, pirms tos atkal nosūtīt kanālā pret jums vai serveri, ar kuru runājāt. Bez abu pušu ziņas informācija tiek apdraudēta. Mums jānodrošina, lai saziņa būtu Privāts.
2. Slikts aktieris var modificēt informāciju, kad tā tiek sūtīta pa kanālu. Bobs, iespējams, ir nosūtījis ziņojumu “X” bet Alise saņemtos “Y” no Boba, jo slikts aktieris pārtvēra ziņojumu un to pārveidoja. Citiem vārdiem sakot, integritāte ir apdraudēta.
3. Visbeidzot, un pats galvenais, mums jānodrošina, ka persona, ar kuru mēs runājam, patiešām ir tā, kuru viņi saka. Atgriežoties pie piemērs.com domēns. Kā mēs varam pārliecināties, ka serveris, kas mums atbildēja, patiešām ir likumīgs www īpašnieks.piemērs.com? Jebkurā tīkla vietā jūs varat nepareizi novirzīt uz citu serveri. DNS kaut kur ir atbildīgs par domēna vārda, piemēram, www, pārveidošanu.piemērs.com, IP adresē publiskajā internetā. Bet jūsu pārlūkprogrammā nav iespēju pārbaudīt, vai DNS tulkoja IP adresi.

Pirmās divas problēmas var atrisināt, šifrējot ziņojumu, pirms tas tiek nosūtīts internetā uz serveri. Tas ir, pārejot uz HTTPS. Tomēr pēdējā problēma, Identitātes problēma ir tā, kur spēlē sertifikātu pārvalde.

Šifrētu HTTP sesiju sākšana

Galvenā problēma ar šifrētu saziņu nedrošā kanālā ir “Kā mēs to sākam?”

Pirmais solis būtu iesaistīt abas puses, jūsu pārlūkprogrammu un serveri, lai apmainītos ar šifrēšanas atslēgām, kuras jāmaina nedrošajā kanālā. Ja jums nav zināmas terminu atslēgas, domājiet par tām kā par ļoti garu nejauši ģenerētu paroli, ar kuru jūsu dati tiks šifrēti pirms nosūtīšanas pa nedrošu kanālu.

Ja atslēgas tiek sūtītas pa nedrošu kanālu, ikviens to var klausīties un nākotnē apdraudēt jūsu HTTPS sesijas drošību. Turklāt kā mēs varam uzticēties tam, ka atslēgu sūta serveris, kurš apgalvo, ka tā ir www.piemērs.com patiešām ir šī domēna vārda faktiskais īpašnieks? Mums var būt šifrēta saziņa ar ļaunprātīgu pusi, kas maskējas par likumīgu vietni, un nezinām atšķirību.

Tātad identitātes nodrošināšanas problēma ir svarīga, ja mēs vēlamies nodrošināt drošu atslēgu apmaiņu.

Sertifikāta iestādes

Iespējams, esat dzirdējis par LetsEncrypt, DigiCert, Comodo un dažiem citiem pakalpojumiem, kas piedāvā TLS sertifikātus jūsu domēna vārdam. Jūs varat izvēlēties tādu, kas atbilst jūsu vajadzībām. Tagad personai / organizācijai, kurai pieder domēns, kaut kādā veidā jāpierāda savai sertifikāta iestādei, ka tā patiešām kontrolē domēnu. To var izdarīt, vai nu izveidojot DNS ierakstu ar unikālu vērtību, kā to pieprasa sertifikātu pārvalde, vai arī varat pievienot failu savam tīmekļa serverim ar sertifikāta iestādes norādīto saturu, pēc tam SI var izlasīt šo failu un apstipriniet, ka esat derīgs domēna īpašnieks.

Pēc tam jūs sarunājat ar CA par TLS sertifikātu, kā rezultātā jūsu domēnam tiek izsniegta privāta atslēga un publisks TLS sertifikāts. Pēc tam publiskajā sertā var atšifrēt ar jūsu privāto atslēgu šifrētus ziņojumus un otrādi. To sauc par asimetrisku šifrēšanu

Klientu pārlūkprogrammās, piemēram, Firefox un Chrome (dažreiz pat operētājsistēmā), ir zināšanas par sertifikātu iestādēm. Šī informācija jau pašā sākumā tiek ievadīta pārlūkprogrammā / ierīcē (tas ir, kad tās ir instalētas), lai viņi zinātu, ka var uzticēties noteiktām CA. Tagad, kad viņi mēģina izveidot savienojumu ar vietni www.piemērs.com, izmantojot HTTPS, un skatiet sertifikātu, ko izdevis, teiksim DigiCert, pārlūks faktiski var pārliecināties, ka, izmantojot lokāli saglabātās atslēgas. Patiesībā tam ir vēl daži starpniecības soļi, taču tas ir labs vienkāršots pārskats par notiekošo.

Tagad sertifikātu nodrošina www.piemērs.com var uzticēties, tas tiek izmantots, lai vienotos par unikālu simetrisku šifrēšanas atslēgu, kas tiek izmantota starp klientu un serveri atlikušajā sesijas laikā. Simetriskā šifrēšanā vienu atslēgu izmanto, lai šifrētu, kā arī atšifrētu, un tā parasti ir daudz ātrāka nekā asimetriskais kolēģis.

Nianses

Ja TLS un interneta drošības ideja jūs uzrunā, varat apskatīt šo tēmu tālāk, iedziļinoties LetsEncrypt un viņu bezmaksas TLS CA. Visai šai rigmarolei ir daudz sīkāka informācija, nekā norādīts iepriekš.

Citi resursi, kurus es varu ieteikt, lai uzzinātu vairāk par TLS, ir Troja Hanta emuārs un EZF paveiktais darbs, piemēram, HTTPS visur un Certbot. Visi resursi ir brīvi pieejami un patiešām lēti īstenojami (jums vienkārši jāmaksā par domēna vārda reģistrāciju un VPS stundas maksu) un jāiegūst pieredze.