SSL / TLS 101 algajatele

Krüptimise põhjalik ülevaade, mis tagab meie Interneti-ühenduse


Kui Netscape leiutas SSL-i algselt 90-ndate keskel, ei muutunud SSL / TLS-sertifikaadi installimine igal veebisaidil kohustuslikuks kuni 2018. aasta suveni, kui Google hakkas krüptimata saite tähistama “Pole kindel.”

Kuigi Google – oma otsimootori, Chrome’i brauseri ja Android OS-iga – saab Interneti ühepoolselt uuesti määratleda, ei olnud see ainuvõimalus. Apple, Microsoft, Mozilla ja teised peamised tehnoloogiavaldkonna sidusrühmad on kõik teinud kooskõlastatud otsuse lubada SSL / TLS-sertifikaate ja HTTPS-i.

Põhjus selleks on lihtne: ilma SSL / TLS-i ja võimaluseta turvalise ühenduse loomiseks HTTPS-i kaudu oleks kogu veebisaitide ja nende külastajate vaheline suhtlus vahetatud tavalises tekstis ja kolmas osapool on hõlpsasti loetav..

Ainus negatiivne külg universaalse krüptimise hiljutisele tõukele on see, et see on sundinud uute klientide sissevoolu võõrale turule, mis teeb väga vähe, et end keskmise veebisaidi või ettevõtte omaniku jaoks vähem segadusse ajada..

See artikkel on kõikehõlmav juhend SSL / TLS-i jaoks, paneme aluse põhikontseptsioonide, näiteks krüptimise, HTTPS ja Interneti-ühenduste olemuse ületamise kaudu.

Loodetavasti tunnete end lõpuks kindlalt TLS-i sertifikaadi valimisel, ostmisel ja rakendamisel ning pidage meeles, et kui teil on küsimusi, mille saate jätta nende juurde allpool toodud kommentaarides.

Sihtasutuste elemendid

Alustame arutlusega kõige selle keskmes oleva mõiste: krüptimise üle.

Krüptimine on kõige sirgjoonelisemas iteratsioonis midagi enamat kui andmete krüpteerimine – kasutades etteantud šifrit või võtit – nii, et see muutuks kõigile, välja arvatud sama privaatvõtmega, osapooltele loetamatuks..

Läbi ajaloo on kõige levinum mudel olnud privaatvõtme krüptimine. Privaatvõtme krüptimisel peavad mõlemad pooled omama või vähemalt vahetama privaatvõtit, mida saab kasutada teabe krüptimiseks ja dekrüptimiseks.

Varem olid enamik nende krüptosüsteemide aluseks olnud šifreid primitiivsed, tuginedes lihtsatele asendustele või asendades tavalised sõnad tähemärkidega. Kuid aja jooksul muutusid šifrid matemaatikast üha enam keerukamaks.

Näiteks lõi Prantsusmaal 1600. aastate keskel kuningas Louis XIV krüptograaf šifri, mis oli nii hästi läbi mõeldud, et see purustati alles 250 aastat hiljem ja alles siis osaliselt. Tänaseks on Prantsuse arhiivides sadu aastaid väärt dokumente, mida ei pruugita kunagi dešifreerida.

Kuid kui ajalooliselt on krüpteerimine olnud varjatud või salajane vahend, on Interneti tulek seda mõistet laiemalt kasutusele võtnud. Internet on laialt levinud ja ta tegeleb paljude kriitiliste funktsioonidega. Iga päev kasutavad miljardid inimesed seda tundlikule teabele juurdepääsuks ja selle saatmiseks, oma rahaasjade haldamiseks, ettevõtetega tehingute tegemiseks – teie nimetate seda.

Probleem on selles, et Internet ei olnud täielikult loodud vastavalt sellele, mis ta on saanud. Varem, päevil, mil akadeemilised ringkonnad ja USA valitsus töötasid esmakordselt välja võrgundusprotokolle, peeti internetti vaid valitsuse ja akadeemiliste asutuste vahelise vaba teabevahetuse mehhanismiks. Sel ajal oli äritegevus veebis ebaseaduslik. e-kaubandus ei olnud sõna, mis oleks isegi veel leiutatud. Ja veebisait oli rohkem geograafiline mõiste.

Nii et kui HTTP või hüperteksti edastusprotokoll võeti esmakordselt kasutusele 1991. aastal, ei olnud asjaolu, et selle moodustatud ühendused vahetasid andmeid tavalises tekstis, diskvalifitseerivat probleemi.

Täna on asjad palju teisiti. Veebis vahetatav teave ei ole akadeemiline uurimistöö ega vabalt kättesaadav teave, see on isikut tuvastav teave ja tundlikud andmed, mis võivad inimestele maksta raha või mõnes piirkonnas isegi nende elu. See nõudis kindlamat lähenemist.

Vastus oli krüptimine.

Võtmete vahetamise teema

Üks probleem, mis on ajalooliselt vaevanud ka parimaid krüptosüsteeme, püsib tänapäevani.

See, mida me varem arutasime ja mis on traditsiooniliselt olnud krüptimise standard, on privaatvõtme krüptimine. Seda nimetatakse ka sümmeetriliseks krüptimiseks ehk kahesuunaliseks krüptimiseks – privaatvõtmetega, mis käsitlevad suhtlemiseks vajalikke krüptimis- ja dekrüptimisfunktsioone.

Privaatvõtme krüptimise toimimiseks tuleb privaatvõti osapoolte vahel üle kanda või mõlemal osapoolel peab olema oma koopia. Mõlemal juhul oli privaatvõtme turvalisus krüptosüsteemi terviklikkuse jaoks kriitilise tähtsusega ja nagu võite kahtlemata oletada, on võtmete vahetamine sama vana probleem kui krüptimine ise.

Siis, 1970. aastatel – tehniliselt kahel erineval ajal, üksteisest peale kogu ookean – kontsepteeriti ja ellu viidi uus krüptimisvorm: avaliku võtme krüptimine.

Kui privaatvõtme krüptimine on kahesuunaline sümmeetriline funktsioon, kus privaatvõti on võimeline nii krüpteerima kui ka dekrüpteerima, on avaliku võtme krüptimine asümmeetriline; ühel viisil. Üksiku privaatvõtme asemel on olemas avaliku ja privaatse võtme paar. Avalik võti tegeleb krüptimisega ja on, nagu nimigi viitab, avalikult kättesaadav, samas kui privaatvõtit, mis tegeleb dekrüpteerimisega, hoiab selle omanik salajas. Avaliku võtme abil saab krüptida andmeid ja saata need võtme omanikule, kus ainult nad saavad selle dekrüpteerida..

Tore, aga kuidas sellest kasu on??

Noh, ühesuunaline krüptimine ei ole ideaalne Interneti-ühenduste krüptimiseks. See on omamoodi keeruline suhelda, kui üks osapool saab ainult krüptida ja teine ​​ainult dekrüpteerida. Ei, Interneti-ühenduse krüptimiseks peaksite kasutama sümmeetrilist privaatvõtme krüptimist.

Kuidas aga võtmeid vahetada? Eriti veebis?

Avaliku võtme krüptimine.

Ja see on oma olemuselt destilleeritud, mida SSL / TLS endast kujutab: turvaline võtmevahetus.

Siin seome kõik need mõisted omavahel kokku. Kui soovite, et teie suhtlus veebisaidiga oleks privaatne, peate sellega turvaliselt ühenduse looma. Kui soovite selle veebisaidiga turvaliselt ühenduse luua, peate vahetama sümmeetrilised privaatvõtmed, et saaksite neid kasutada suhtlemiseks. SSL / TLS (ja üldiselt PKI) on lihtsalt väljamõeldud mehhanism selle seansivõtme loomiseks ja vahetamiseks.

SSL / TLS-i abil saate autentseerida serverit või organisatsiooni, millega kavatsete ühendust luua, ja tagada, et vahetate turvaliselt privaatsed võtmed, mida kasutate selleks, et krüpteerida oma suhtlus soovitud osapoolega.

Kahjuks on SSL / TLS-il ja PKI-l palju terminoloogiat ja liikuvaid osi, mis võivad inimesi hõlpsalt segadusse ajada, kuid usuvad tõsiasja, et kogu matemaatika ja tehnilise kõnepruuki eemaldamisel on see lihtsalt elegantne kaasaegne tehnoloogiline lahendus vanusele -vanune probleem: võtmete vahetamine.

Vaatame nüüd mõnda peamist terminit

Enne kui läheme kaugemale, vaatame veel paar peamist terminit. Tutvustasime juba HTTP-d, hüperteksti edastusprotokolli, mis on aastakümneid olnud Interneti alustala. Kuid nagu me arutasime, kujunes Internetist midagi palju erinevat, kui see oli siis, kui HTTP esmakordselt 1991. aastal avaldati.

Vaja oli turvalisemat protokolli. Seega HTTPS.

HTTPS, mida mõnikord nimetatakse TLS-is HTTP-na, kasutab krüpteerimist, et muuta ühenduse ajal vahetatavad andmed loetamatuks kellelegi teisele, välja arvatud selleks mõeldud osapool. See on eriti oluline, kui arvestada tänapäevase Interneti-ühenduse olemusega.

Kui Interneti algusaegadel oli ühendus mõistlikult otsene, siis nüüd suunatakse ühendused kümnete seadmete kaudu oma lõppsihtkohta. Kui olete kunagi soovinud selle praktilist tutvustamist, avage oma operatsioonisüsteemi käsurida ja sisestage käsk „tracert geekflare.com“.

Näete teed, mille kaudu teie ühendus kulges marsruudil sihtkohta. Kuni 30 hüpet. See tähendab, et teie andmed läbivad kõik need seadmed enne, kui nad jõuavad mis tahes veebisaidile või rakendusse, millega ühendate. Ja kui mõnele neist seadmetest on installitud pakettaknad või mõni kuulaja, saavad nad varastada edastatud andmed ja mõnel juhul isegi ühendusega manipuleerida.

Seda nimetatakse keskeltläbi rünnakuks (MITM).

Kui soovite teada saada MITM-i rünnaku kohta, siis vaadake seda veebikursust.

Kaasaegsete Interneti-ühendustega on kaetud palju rohkem pinda, kui suurem osa inimestest aru saab, mistõttu on andmete edastamise ajal krüptitud olemasolu kriitiline. Teil pole aimugi, keda võiks kuulata või kui triviaalselt lihtne seda teha on.

HTTP-ühendus luuakse pordi 80 kaudu. Meie eesmärkidel võite mõelda sadamatele kui konstruktsioonidele, mis osutavad võrguteenusele või -protokollile. Tavaline veebisait, mida pakutakse HTTP kaudu, kasutab porti 80. HTTPS kasutab tavaliselt porti 443. Kui veebisait installib sertifikaadi, saab ta oma HTTP-lehed suunata ümber HTTPS-i saitidele ja kasutajate brauserid proovivad autentimiseni ootel turvaliselt ühenduse luua pordi 443 kaudu..

Kahjuks on mõisteid SSL / TLS, HTTPS, PKI ja krüptimine kõik ümber lükatud, mõnikord kasutatakse neid isegi vaheldumisi, nii et siin tekkiva segaduse likvideerimiseks on siin lühike juhend:

  • SSL – Secure Sockets Layer, originaalne krüptimisprotokoll, mida kasutatakse koos HTTPS-iga
  • TLS – Transpordikihi turvalisus, uuem krüptimisprotokoll, mis on asendanud SSL-i
  • HTTPS – HTTP turvaline versioon, mida kasutatakse veebisaitidega ühenduse loomiseks
  • PKI – Avaliku võtme infrastruktuur – viitab kogu usaldusmudelile, mis hõlbustab avaliku võtme krüptimist

SSL / TLS töötab koos HTTPS-ühenduste lubamiseks. Ja PKI viitab suumimisel kogu asjale.

Sain aru? Ärge muretsege, küll saate.

Avaliku võtme infrastruktuuri loomine

Nüüd, kui oleme aluse pannud, vähendame ja vaatame läbi SSL / TLS keskmes oleva usaldusmudeli rakendatud arhitektuuri.

Veebisaidile jõudes kontrollib teie brauser kõigepealt SSL / TLS-sertifikaadi autentsust, millega see sait seda esindab. Saame teada, mis juhtub pärast seda, kui autentimine toimub mõnes osas, kuid alustame sellest, arutades usaldusmudelit, mis kõik selle võimalikuks teeb.

Alustame küsimuse esitamisega: kuidas mu arvuti teab, kas antud SSL / TLS-sertifikaati usaldada??

Sellele vastamiseks peame arutama PKI-d ja mitmesuguseid elemente, mis panevad selle tööle. Alustame sertifikaatide autoriteetide ja juurprogrammidega.

Sertifikaadiasutused

Sertifikaadiasutus on organisatsioon, mis vastab usaldusväärsete digitaalsete sertifikaatide väljastamise võimaluse eest eelmääratud standardite kogumile..

Seal on kümneid CA-sid, nii tasuta kui ka kommertsteenuseid, mis võivad väljastada usaldusväärseid sertifikaate.

Nad kõik peavad järgima standardite kogumit, mille üle on arutatud ja seadustatud CA / brauserifoorumi kaudu, mis toimib TLS-i tööstust reguleeriva organina. Need standardid kirjeldavad järgmisi asju:

  • Tehnilised kaitsemeetmed, mis peavad olema paigas
  • Parimad tavad valideerimise jaoks
  • Parimate tavade väljastamine
  • Tühistamismenetlused ja tähtajad
  • Sertifikaatide logimise nõuded

Need juhised on koostanud brauserid koos pädevate asutustega. Brauseritel on TLS-i ökosüsteemis ainulaadne roll.

Keegi ei pääse ilma veebibrauserita internetti kuskile. Seetõttu võtab digitaalse TLS-sertifikaadi vastu ja valideerib brauser ning vahetab seejärel võtmeid serveriga. Seega, arvestades nende ülitähtsat rolli, on neil märkimisväärne mõju.

Ja on oluline meeles pidada, et brauserid on loodud võimalikult skeptilisteks. Mitte midagi usaldada. See on parim viis nende kasutajate turvaliseks hoidmiseks. Niisiis, kui brauser usaldab digitaalset sertifikaati – mida võidakse kasutaja kahjuks kuritarvitada -, on vaja kindlaid kinnitusi, et see, kes selle sertifikaadi välja andis, tegi oma hoolsuskohustuse.

See on sertifitseerimisasutuste roll ja vastutus. Ja ka brauserid ei pea vigadest kinni. Seal on sõnasõnaline surnuaed endistest asutustest, mis on brauseritega vaeva näinud ja karjamaale pandud.

Kui sertifitseerimisasutus on tõestanud vastavust CAB Foorumi põhinõuetele ja läbinud kõik nõutavad auditid ja ülevaated, saab ta avalduse erinevatele juurprogrammidele lisada juursertifikaadid.

Juurprogrammid

Juurprogramm – peamisi haldavad Apple, Microsoft, Google ja Mozilla – on aparaat, mis jälgib ja hõlbustab juurpoode (mõnikord nimetatakse neid ka usalduspoodideks), mis on Root CA sertifikaatide kogumid, mis asuvad kasutaja süsteemis. Need juured on jällegi uskumatult väärtuslikud ja uskumatult ohtlikud – nad saavad ju väljastada usaldusväärseid digitaalsertifikaate – seega on turvalisus ülimalt murettekitav.

Sellepärast ei väljasta CA peaaegu kunagi otse Root CA sertifikaate ise. Selle asemel keerutavad nad vahepealseid juursertifikaate ja kasutavad neid lõppkasutaja või lehe sertifikaatide väljastamiseks. Nad saavad need juured üle anda ka all-CA-dele, kes on sertifitseerimisasutused, kellel pole oma pühendunud juuri, kuid saavad siiski oma allkirjastatud sertifikaate oma vahendajate käest väljastada.

Paneme selle kõik kokku. Kui veebisait soovib TLS-sertifikaadi väljaandmist, genereerib see serveris, mida ta majutab, midagi, mida nimetatakse sertifikaadi allkirjastamistaotluseks (CSR). Selles taotluses sisalduvad kõik üksikasjad, mida veebisait soovib sertifikaadile lisada. Nagu natuke näete, võib teabe hulk varieeruda ettevõtte täielikest üksikasjadest kuni lihtsa serveri identiteedini, kuid kui CSR on lõpule viidud, saadetakse see koos sertifikaatide asutusega väljastamiseks.

Enne sertifikaadi väljaandmist peab CA tegema oma CA / Brauseri Foorumi volitatud hoolsuskohustuse ja kontrollima, et CSR-is sisalduv teave oleks õige. Kui see on kinnitatud, allkirjastab see sertifikaadi oma privaatvõtmega ja saadab selle veebisaidi omanikule installimiseks tagasi.

Sertifikaadi aheldamine

Pärast TLS-sertifikaadi installimist edastab keegi seda külastavale saidile kasutaja brauseri koos sertifikaadiga. Brauser uurib sertifikaadil olevat digitaalallkirja, selle, mille koostas usaldusväärne sertifikaadiasutus, mis tagab, et kogu sertifikaadis sisalduv teave on õige.

See on koht, kus mängib termin sertifikaadi aheldamine.

Brauser loeb digitaalallkirja ja liigutab keti lingi üles – järgmisena kontrollib ta vahesertifikaadi digitaalset allkirja, mille privaatvõtit kasutati lehe sertifikaadi allkirjastamiseks. See jätkub allkirjade järgimisega, kuni kas sertifikaatide ahel lõpeb nende juurvara usaldusväärsete juurtega või kuni ahel lõpeb juurtele jõudmata. Sel juhul ilmub brauseri tõrge ja ühendus ebaõnnestub.

Seetõttu ei saa te oma sertifikaate välja anda ega ise allkirjastada.

Brauserid usaldavad ainult neid SSL / TLS-sertifikaate, mida nad saavad oma juurkappi tagasi kettida (see tähendab, et need on välja andnud usaldusväärne üksus). Sertifikaatide väljastajad peavad oma usaldusväärsuse säilitamiseks järgima konkreetseid standardeid ja isegi siis on brauserid lootnud neid usaldada.

Brauseritel pole ise allkirjastatud sertifikaatide osas sellist kinnitust, mistõttu tuleks neid juurutada ainult sisevõrkudes, tulemüüride taga ja testimiskeskkondades.

SSL / TLS sertifikaatide tüübid ja funktsionaalsus

Enne kui vaatame liikuvat SSL / TLS-i, räägime sertifikaatidest ja mitmesugustest saadaolevatest iteratsioonidest. TLS-sertifikaadid hõlbustavad TLS-i protokolli ja aitavad dikteerida veebisaidi krüptitud HTTPS-ühenduste tingimusi.

Varem mainisime, et TLS-sertifikaadi installimine võimaldab teil oma veebisaidi konfigureerida HTTPS-ühenduste loomiseks pordi 443 kaudu. See toimib ka omamoodi selle saidi või serveri nimemärgina, millega teie suhtlete. Tulles tagasi mõttele, et SSL / TLS ja PKI on kõik turvalise võtmevahetuse oivalised vormid, aitab SSL / TLS-sertifikaat brauseril teada anda, kellele see sessioonivõtme saadab – kellele osapoolele teises otsas ühendus on.

Ja kui jaotada SSL / TLS-sertifikaatide erinevad iteratsioonid, on see asjakohane asi, mida tuleks meeles pidada. Sertifikaadid erinevad funktsionaalsuse ja valideerimise taseme järgi. Teisisõnu erinevad need sõltuvalt:

  • Mitu identiteeti kinnitada
  • Millised lõpp-punktid identiteedi kinnitamiseks

Neile kahele küsimusele vastamine annab teile üsna selgelt teada, millist tüüpi sertifikaate te vajate.

Mitu identiteeti Assertiga

SSL / TLS-sertifikaatidega on saadaval kolm erinevat valideerimise taset ja need erinevad sõltuvalt sellest, kui palju identiteediteavet teie veebisait soovib kinnitada.

  • Domeeni valideerimise SSL-sertifikaadid – õigusserveri identiteet
  • Organisatsiooni valideerimise SSL-sertifikaadid – osalise organisatsiooni identiteedi kinnitamine
  • Laiendatud valideerimise SSL-sertifikaadid – kinnitage organisatsiooni täielik identiteet

Domeeni valideerimine SSL-sertifikaadid on nende hinna ja väljastamise kiiruse tõttu vaieldamatult kõige populaarsemad. DV SSL / TLS sertifikaadid nõuavad lihtsat domeenikontrolli kontrolli, mida saab teha mitmel erineval viisil, kuid sertifikaadi saab välja anda kohe, kui see on olemas. Saate neist tasuta saada ka umbes 30- ja 90-päevaseid versioone, mis on nende turuosale kahtlemata lisanud.

Negatiivne külg on see, et DV SSL-sertifikaadid kinnitavad minimaalset identiteeti. Ja arvestades, et peaaegu pooltel andmepüügisaitidel on nüüd installitud DV SSL-sertifikaat, ei osta nad tingimata teile usalduse huvides palju.

Organisatsiooni valideerimine SSL-sertifikaadid on SSL / TLS-sertifikaadi algtüübid. Need on ka ainsad SSL-sertifikaadid, mis saavad IP-aadressi turvaliseks pärast CAB-foorumi 2016. aasta otsust kehtetuks kõik sisevõrgu SSL-sertifikaadid. Organisatsiooni valideerimine eeldab kerget ettevõtte kontrolli ja selle saab tavaliselt välja anda ühe või kahe päeva jooksul – mõnikord kiiremini. OV SSL-sertifikaadid nõuavad teatud organisatsioonilist teavet, kuid Interneti-kasutaja peaks klõpsama tabaluku ikooni ja seda otsima. Tänapäeval näete palju OV SSL-sertifikaate, mida kasutatakse suurtes ettevõtete ja ettevõtete võrkudes näiteks tulemüüride taga tehtud ühenduste jaoks.

Kuna ei DV ega OV SSL sertifikaadid ei kinnita piisavat identiteeti, et rahuldada enamikku brausereid, saavad nad neutraalset kohtlemist.

Laiendatud valideerimise SSL-sertifikaadid on vaieldamatult kõige vaieldavamad, kuna mõned tehnikakogukonnas leiavad, et nende kinnituse valideerimise tugevdamiseks on vaja rohkem ära teha. Kuid EV SSL kinnitab maksimaalset identiteeti. Laiendatud valideerimise lõpuleviimiseks viib sertifitseerimisasutus organisatsiooni läbi range kontrolliprotsessi, mis võib mõnel juhul võtta nädala..

Kuid eelis on vaieldamatu: kuna see tagab piisava identiteedi, saab EV SSL-sertifikaadiga veebisait brauseri kordumatut kohtlemist, sealhulgas selle nime esitamist brauseri aadressiribal.

Selle saavutamiseks pole muud võimalust ja te ei saa seda võltsida – EV-aadressiriba on üks võimsamaid visuaalseid indikaatoreid, mis meil täna on..

Millised lõpp-punktid identiteedi kinnitamiseks

SSL / TLS-sertifikaatide erinev viis on funktsionaalsus. Veebisaidid on Interneti algusaegadest peale üsna palju arenenud, kuna ettevõtted kasutavad saite erineval viisil. Mõnel on mitu domeeni erinevate ettevõtte vertikaalide jaoks; teised kasutavad alamdomeene mitme funktsiooni ja veebirakenduste jaoks. Mõni kasutab mõlemat.

Ükskõik, mis kontekstis on, on olemas SSL / TLS-sertifikaat, mis aitab seda kaitsta.

Üks domeen

Esmane veebisait ja standardne SSL-sertifikaat on vaid üks domeen. Enamik kaasaegseid SSL / TLS-sertifikaate turvavad selle domeeni nii WWW- kui ka WWW-välised versioonid, kuid see on piiratud ühe domeeniga. Sa saad võrrelge siin SSL-sertifikaate.

Mitme valdkonna domeenid

Mitme domeeni sertifikaadid Samuti on olemas ka ühtsed kommunikatsioonisertifikaadid (Microsoft Exchange’i ja Office Communications serverite puhul), et anda organisatsioonidele võimalus krüptida mitu domeeni ühe sertifikaadiga. See võib olla atraktiivne võimalus, kuna see säästab raha ja muudab sertifikaatide (aegumise / pikendamise) haldamise palju lihtsamaks.

Mitme domeeni ja UCC sertifikaadid kasutavad sertifikaadis täiendavate domeenide lisamiseks CSR-i, CSR-i väljat Alternatiivne nimi. Enamik CA-sid lubab ühe sertifikaadiga kuni 250 erinevat SAN-i. Ja enamikul mitme domeeni sertifikaatidel on 2–4 tasuta SAN-i, ülejäänud saab vastavalt vajadusele osta.

Metamärgi SSL-sertifikaadid

Metamärgi SSL-sertifikaadid on äärmiselt kasulik sertifikaadi tüüp, kuna nad saavad krüptida piiramatul arvul alamdomeene URL-i samal tasemel. Näiteks kui teil on veebisait, mis kasutab selliseid alamdomeene nagu:

  • app.veebisait.com
  • portaal.veebisait.com
  • kasutaja.veebisait.com

Saate neid kõiki krüpteerida sama metamärgi sertifikaadiga, kasutades tärni oma CSR-i väljal FQDN: * .website.com

Nüüd saab selle sertifikaadiga kaitsta kõiki alamdomeene, isegi neid, mida te pole veel lisanud.

Wildcardi sertifikaatidel on siiski kaks varjukülge. Esimene on see, et kasutades sama avalikku võtit mõnes lõpp-punktis, olete haavatavam teatavate ekspluateerimiste, näiteks Bleichenbacheri rünnakute suhtes.

Teine on see, et EV metamärgi võimalust pole. Metamärgi funktsioonide lahtise olemuse tõttu pole brauseritel lubatud seda usaldust delegeerida. Kui soovite oma alamdomeenidesse EV aadressiriba, peate need eraldi krüpteerima või kasutama EV mitme domeeni sertifikaati.

Mitme domeeni metamärk

Suhteliselt uus täiendus SSL / TLS ökosüsteemile võib mitme domeeni loodusmärk krüptida kuni 250 erinevat domeeni, kuid see võib kasutada ka SAN-i väljadel tärne, mis võimaldab teil ka krüptida 250 erinevat domeeni JA kõiki nendega kaasnevaid esimesi -taseme alamdomeenid.

Teine mitme domeeni metamärgi kasutamise juhtum on mitmetasandiline metamärk, kus see võib krüptida alamdomeene URL-i mitmel tasandil (tavaline metamärk võib neid ainult ühel tasemel krüptida).

Metamärgi funktsionaalsuse tõttu pole ka mitme domeeni metamärgid EV-s saadaval.

SSL / TLS liikumises

Nüüd, kui oleme katnud kõik olulised mõisted, mis SSL / TLS-i ja PKI-d ühendavad, paneme selle kõik kokku ja näeme liikumises.

Valideerimine ja väljaandmine

Alustame algusest kohe veebisaidiga, mis ostab CA-lt või edasimüüjalt SSL / TLS-sertifikaadi. Pärast ostmist loob sertifikaadi omandamist haldav organisatsiooniline kontakt sertifikaadi allkirjastamistaotluse serverisse, kuhu see sertifikaat installitakse (server, mis majutab veebisaiti).

Koos CSR-iga genereerib server ka avaliku / privaatvõtme paari ja salvestab privaatvõtme kohapeal. Kui CA saab CSR-i ja avaliku võtme, viib ta läbi vajalikud kontrollimistoimingud, et tagada sertifikaadis sisalduva teabe täpsus. Ettevõtte autentimissertifikaatide (mitte DV) puhul hõlmab see üldiselt organisatsiooni registreerimisteabe ja avalike registrite otsimist valitsuse andmebaasides.

Kui valideerimine on lõpule viidud, kasutab CA ühe väljastava sertifikaadi privaatset võtit, tavaliselt vahejuurt, ja allkirjastab sertifikaadi enne selle tagastamist saidi omanikule..

Nüüd saab veebisaidi omanik võtta kasutusele äsja väljastatud SSL / TLS-sertifikaadi, installida see oma serverisse ja konfigureerida veebisaiti looma HTTPS-ühendusi pordi 443 kaudu (kasutades 301 ümbersuunamist, et saata liiklust olemasolevatelt HTTP-lehtedelt oma uutele HTTPS-i kolleegidele).

Autentimine ja SSL-i käepigistus

Nüüd, kui SSL / TLS-sertifikaat on installitud ja veebisait on seadistatud HTTPS-i jaoks, vaatame, kuidas see hõlbustab krüptitud ühendusi saidi külastajatega.

Veebisaidile jõudes tutvustab server SSL / TLS-sertifikaati kasutaja brauserile. Seejärel viib kasutaja brauser läbi rea kontrolle.

Esiteks hakkab see sertifikaati autentima, vaadates selle digitaalallkirja ja järgides sertifikaatide ahelat. Samuti kontrollib ta, kas sertifikaadi aegumine pole lõppenud, ning kontrollib sertifikaatide läbipaistvuse (CT) logisid ja sertifikaatide tühistamise loendeid (CRL). Eeldusel, et kett viib tagasi süsteemi usaldusaluse juurte juurde ja kui see on kehtiv, usaldab brauser sertifikaati.

Nüüd on käesurumise aeg.

SSL / TLS käepigistus on sammude seeria, kus klient (kasutaja) ja server (veebisait) lepivad kokku oma turvalise ühenduse parameetrid, genereerivad ja vahetavad seejärel sümmeetrilisi seansivõtmeid.

Esiteks hakkavad nad otsustama šifrikomplekti üle. Šifrikomplekt on ühenduse jaoks kasutatavate algoritmide ja šifrite rühm. SSL / TLS-sertifikaat sisaldab nende krüpteerimiskomplektide loetelu, mida server toetab. Üldiselt sisaldab šifrikomplekt avaliku võtme krüptimisalgoritmi, võtme genereerimise algoritmi, sõnumi autentimisalgoritmi ja sümmeetrilise või hulgkrüptimisalgoritmi – ehkki seda on täpsustatud TLS 1.3-s.

Pärast toetatud šifrite loendi esitamist valib klient endale meeldiva ja edastab selle serverile. Sealt genereerib klient sümmeetrilise sessioonivõtme, krüpteerib selle avaliku võtme abil ja saadab seejärel serverile, kellel on sessioonivõtme dekrüptimiseks vajalik privaatvõti..

Kui mõlemal osapoolel on istungivõtme koopia, võib suhtlus alata.

Ja see on SSL / TLS.

Näete, kuidas kõik kontseptsioonid, mida me varem läbi käisime, üksteisega suhestuvad, et luua keerukas, kuid elegantne süsteem Interneti-ühenduste tagamiseks. Seansivõtmete turvaliseks vahetamiseks, kellega suhtleme, kasutame avaliku võtme krüptograafiat. Serveri või organisatsiooni identiteeti kinnitavaid sertifikaate saab usaldada erinevate CA-de, brauserite ja juurprogrammide vahelise infrastruktuuri tõttu.

Ja kommunikatsioon toimub sümmeetrilise privaatvõtme krüptimise tagajärjel, mis on põlvnenud antiigi klassikalistest krüptosüsteemidest.

Liikuvaid osi on palju, kuid kui neid kõiki ükshaaval aeglustada ja mõista, on palju lihtsam näha, kuidas see kõik koos töötab.

Lõpetagem enne minekut mõne SSL-iga / TLS-iga seotud käiguga, mille abil saate oma installeerimisjärgse / konfigureerimise teha, et oma investeeringust maksimaalset kasu saada.

Pärast SSL / TLS – rakendamisest maksimaalse kasu saamine

Sertifikaadi installimine ja veebisaidi õigesti konfigureerimine ei tähenda, et teie veebisait on turvaline. TLS on vaid üks komponent laiemast, terviklikust küberkaitsestrateegiast. Kuid oluline komponent sellest hoolimata. Vaatleme mõnda asja, mida saate teha selle tagamiseks, et saaksite rakendusest maksimumi.

Keela vanade protokollide serveri tugi

Kui kahekordistada tagasi vestlust, mis meil varem Cipher Suitesi kohta oli, siis teie serveri konfigureerimise osa on otsustada, milliseid šifrikomplekte ja SSL / TLS-i versioone toetada. Oluline on keelata vanemate SSL / TLS-i versioonide tugi ja konkreetsed algoritmid, et vältida haavatavust mitme teada oleva ekspluateerimise vastu.

SSL 2.0 ja SSL 3.0 on mõlemad üle 20 aasta vanad. Parim tava oli nende toetuste vähendamine aastaid tagasi, kuid tänapäevani lubab neid endiselt umbes 7% Alexa 100 000 populaarsemast arvust. See on ohtlik, kuna see paneb teid SSL-i eemaldama ja alandama rünnakuid nagu POODLE.

Ka TLS 1.0 ja TLS 1.1 on laenatud ajal.

Suuremad tehnoloogiaettevõtted Apple, Microsoft, Google ja Mozilla esitasid sel sügisel ühisavalduse, et nemad vähendavad TLS 1.0 ja 1.1 tuge 2020. aasta alguses..

Protokolli versioonid on haavatavad nagu POODLE, FREAK, BEAST ja CRIME (need on kõik akronüümid). TLS 1.2 on väljas olnud kümme aastat ja see peaks olema standard. TLS 1.3 viidi lõpule eelmisel suvel ja vastuvõtmine on sellest ajast alates liikunud ühtlases tempos.

Lisaks on olemas spetsiifilised algoritmid, mida samuti ei tohiks kasutada. Näiteks DES saab rikkuda mõne tunniga. RC4 on haavatavam kui kunagi varem arvati ja see on maksekaarditööstuse andmeturbe standardite kohaselt juba keelatud. Ja lõpuks, võttes arvesse hiljutiste ekspluatatsioonide uudiseid, pole soovitatav võtmevahetuseks enam RSA-d kasutada.

Soovitatavad algoritmid / šifrid:

  • Võtmevahetus: elliptiline kõver, Diffie-Helman (ECDH)
  • Autentimine: elliptilise kõvera digitaalallkirja algoritm (ECDSA)
  • Sümmeetriline / hulgkrüptimine: AES 256 Galois-loenduri režiimis (AES256-GCM)
  • MAC-algoritm: SHA-2 (SHA384)

Alati sisse lülitatud SSL

Varem on veebisaidid mõnikord teavet kogunud veebilehti üle viinud ainult HTTPS-i, teenindades ülejäänud saiti HTTP kaudu. See on halb tava.

Lisaks asjaolule, et Google tähistab need lehed märkega „Ei ole turvaline”, seate teie saidi külastajad ohtu ka sellega, et nende brauserid hüppavad edasi krüpteeritud lehtede ja HTTP-lehtede vahel.

Peaksite kogu oma veebisaidi seadistama HTTPS-i jaoks. Seda nimetatakse alati sisse lülitatavaks SSL-ks. Lõppude lõpuks pole nii, et maksate lehe kaudu, teie SSL / TLS-sertifikaat võib kogu teie saidi krüpteerida. Nii et tehke nii.

Seadistage sertifikaadiasutuse volituse (CAA) register

Üks kõige olulisemaid riske, mida digitaalsed sertifikaadid üldiselt põhjustavad, on väärväljaandmine. Kui mõni muu osapool kui teie, väljastatakse teie veebisaidi jaoks SSL / TLS-sertifikaat, saavad nad teiega tõhusalt esindada ja põhjustada igasuguseid probleeme.

CAA kirjed aitavad seda riski leevendada, piirates seda, mida sertifitseerimisasutused võivad teie veebisaidile digitaalseid sertifikaate väljastada. CA / brauserifoorum nõuab sertifikaatide autoriteetidelt CAA kirjete kontrollimist enne mis tahes sertifikaadi väljaandmist. Kui CA-l ei ole luba selle saidi jaoks välja anda, siis seda ei saa. Sellist toimingut peetakse puudulikuks väljaandmiseks ja brauserikogukonna viha kogumiseks.

CAA-kirje lisamine on suhteliselt lihtne, see on lihtne DNS-kirje, mille saab lisada enamiku hostimisplatvormide liidese kaudu. Võite piirata CA-sid, mis võivad teie domeenile välja anda, samuti seda, kas ka metamärgi sertifikaate võidakse välja anda ka selle jaoks.

Lisage oma veebisait HSTS-i eellaadimisloendisse

HTTP range transporditurvalisus ehk HSTS on HTTP päis, mis sunnib brausereid ainult antud saidiga HTTPS-ühendust looma. Isegi kui veebikasutaja proovib minna lehe HTTP-versioonile, külastavad nad ainult HTTPS-i versiooni. See on oluline, kuna see sulgeb akna mitmel teadaoleval ärakasutamisel, näiteks madalama astme rünnakud ja küpsiste kaaperdamine.

Kahjuks jääb HSTS-i juurde väike rünnakvektor, mistõttu peaksite oma veebisaidi eellaadmiste loendisse lisama. Kui külastaja saabub teie veebisaidile, laadib tema brauser tavaliselt HTTP päise ja hoiab seda siis alles, kuni poliitika on seatud viimaseks. Kuid juba sellel esimesel visiidil, enne päise kättesaamist, on ründajale siiski väike avaus.

HSTS-i eellaadimise loendit haldab Google ja selle mõningaid variatsioone, mida kasutavad kõik peamised brauserid. Need brauserid teavad, et loendis olevate veebisaitidega saab ühenduse luua ainult HTTPS-i kaudu – isegi kui seda pole seal kunagi varem külastatud. Teie saidi ilmumiseks loendisse võib kuluda nädal või kaks, kuna loendi värskendused lükatakse välja koos brauserite vabastamise ajakavadega.

SSL / TLS KKK

Mis on X.509 sertifikaat?

X.509 viitab digitaalse sertifikaadi tüübile, mida kasutatakse koos SSL / TLS ja muud tüüpi PKI-ga. X.509 on avaliku võtme krüptimisstandard. Mõnikord näete, et ettevõtted kasutavad digitaalse sertifikaadi või PKI sertifikaadi asemel X.509 sertifikaati.

Miks SSL / TLS sertifikaadid aeguvad??

Sellel on kaks põhjust.

Esimene on see, et Internet muutub pidevalt, veebisaidid tulevad ja veebisaidid lähevad. Ja arvestades seda, kui tundlikud on brauserid nende sertifikaatide usaldamise suhtes, tahavad nad teada, et sertifikaate tutvustavad veebisaidid kontrollitakse regulaarselt. See ei erine nii palju sellest, kuidas peate juhiloa teabe värskendamiseks aeg-ajalt registreeruma.

Teine põhjus on tehnilisem. Uuenduste ja tehniliste muudatuste levitamine on raskem, kui sertifikaatide kehtivusaeg ei ole 3-5 aastat. Kui sertifikaatide kehtivusaeg lõpeb iga 24 kuu tagant, võib pikim sertifikaat olla aegunud kaks aastat. 2017. aastal lühendati maksimaalne kehtivus kolmelt aastalt kahele. Tõenäoliselt lüheneb see varsti 12 kuuks.

Kuidas uuendate SSL / TLS-i sertifikaati??

Uuendamine võib olla pisut ekslik, kuna asendate vana sertifikaadi äsja väljastatud sertifikaadiga. Regulaarselt seda tehes saate olla kursis uute krüptimistehnoloogiaga seotud edusammudega ja tagab, et teie valideerimise teave on ajakohane. Pädevad asutused saavad uuesti kasutada ainult algselt edastatud valideerimise teavet nii kaua, enne kui põhinõuded sunnivad neid seda uuesti valideerima..

Uuendamisel võite säilitada sama sertifikaadi tüübi, mis teil varem oli, või võite minna midagi uut ja isegi muuta CA-sid. Suur asi on see, kui palju aega on teil aegumissertifikaadil alles – võite kanda kuni kolm kuud. Nii kaua kui pikendate enne sertifikaadi kehtivusaja lõppu, võite järelejäänud aega üle kanda ja kasutada uuesti valideerimise teavet, mis pole pärast viimast valideerimist aegunud. Kui lasite sellel aeguda, alustate nullist.

Mis on HTTPS-i kontroll?

Paljudele suurematele, suuremate võrkudega ettevõtetele meeldib, kui nende liiklus on nähtav. Sellega seoses on HTTPS kahe teraga mõõk. See kaitseb inimeste privaatsust, kuid võib aidata ka varjata küberkurjategijaid. Paljud organisatsioonid dekrüpteerivad oma HTTPS-i liikluse servaseadmes või keskboksis ja saadavad siis tulemüüri taga tavalises tekstis või krüpteerivad selle uuesti ja saadavad oma teel. Kui te ei krüpteeri liiklust uuesti, nimetatakse seda SSL-i lõpetamiseks. Kui krüptite uuesti, nimetatakse seda SSL-sillaks.

Mis on SSL-i mahalaadimine?

SSL-i mahalaadimine on veel üks ettevõtte tava. Mastaabis võib võrgu ressursse maksustada tuhandete käepigistuste tegemine ning seejärel kõigi nende andmete krüptimine ja dekrüptimine. Nii laadivad paljud suuremad võrgud SSL-funktsioonid teise seadmesse, et rakendusserver saaks keskenduda oma põhifunktsioonidele. Seda nimetatakse mõnikord koormuse tasakaalustamiseks.

Miks mu CA saatis mulle vahesertifikaadi??

Pidage meeles varem, kui arutasime juurprogramme?

Väga operatsioonisüsteemil on juurvara, mida ta kasutab PKI usaldusotsuste tegemiseks. Kuid pädevad asutused ei väljasta lõppkasutaja sertifikaate nende juurte taga kartuses, mis juhtuks, kui see kunagi tühistatakse. Selle asemel keerutavad nad vahepealsed juured ja lasevad need välja. Probleem on selles, et vahepealsed juured ei asu süsteemi usalduspoes.

Seega, kui veebisait ei esita vahesertifikaati koos lehe SSL / TLS-sertifikaadiga, ei saa paljud brauserid sertifikaatide ahelat lõpule viia ja annavad hoiatuse. Mõni brauser teeb vahemällu vahesertifikaate, kuid parimaks tavaks peetakse vahetoodete installimist koos oma lehe sertifikaadiga.

Milliseid dokumente on vaja laiendatud valideerimise SSL-sertifikaadi jaoks??

Enamikul juhtudel püüab laiendatud valideerimist teostav sertifikaadiasutus kõigepealt pääseda sellele teabele avalikult kättesaadavate „valitsusasutuse” ressursside kaudu.

Mõnes piirkonnas ei pruugi see siiski võimalik olla. Siiski on valideerimise kiirendamiseks abiks mõned asjad. Ehkki kutsealase arvamuse kirjaga kinnitatavate kontrollide arv on viimasel ajal vähenenud, võib advokaadi või raamatupidaja hea seisukorra olemasolu siiski märkimisväärselt aidata.

Lisaks võite esitada valitsuse väljaantud ettevõtte mandaadi või dokumendi „Õiguse tõend”, mis annab teie organisatsioonile õiguse tegutseda loetletud nime all. Mõned näited nendest dokumentidest:

  • Põhikiri
  • Asutamissertifikaadid
  • Ettevõtte / müüja / kaupmehe litsentsid
  • Harta dokumendid
  • Partnerluslepingud
  • Kaubandusliku või eeldatava nime registreerimine
  • Registro Mercantil

Lõpus

Loodetavasti annab see teile idee SSL / TLS-ist. Kui teil on huvi rohkem teada saada, siis soovitaksin sellel veebikursusel osalemine.

Selle postituse tegi kaastöötaja Patrick Nohe Räsitud läbi SSL pood, küberjulgeoleku uudiseid ja trende kajastav ajaveeb.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map