'N Deeglike blik op die kodering wat ons internetverbindings verseker
Terwyl Netscape oorspronklik SSL in die middel van die negentigerjare uitgevind het, het dit nie verpligtend geword vir elke webwerf om 'n SSL / TLS-sertifikaat te installeer tot die somer van 2018 toe Google ongeënkripteerde webwerwe begin merk nie "Nie veilig nie."
Terwyl Google – met sy soekenjin, Chrome-blaaier en Android-bedryfstelsel – die internet eensydig kan herdefinieer, was dit nie alleen op hierdie mandaat nie. Apple, Microsoft, Mozilla en die ander belangrike belanghebbendes in die tegnologiebedryf het almal 'n gesamentlike besluit geneem om SSL / TLS-sertifikate en HTTPS op te stel.
Die rede hiervoor is eenvoudig: sonder SSL / TLS en die vermoë om veilig via HTTPS te koppel, sou alle kommunikasie tussen webwerwe en hul besoekers in gewone teks en maklik leesbaar deur 'n derde party uitgeruil word..
Die enigste nadeel van hierdie onlangse drang na universele kodering is dat dit 'n instroming van nuwe kliënte tot 'n onbekende mark gedwing het, wat baie min doen om homself minder verwarrend te maak vir die gemiddelde webwerf of besigheidseienaar.
Hierdie artikel sal dien as 'n omvattende gids vir alle dinge wat SSL / TLS betref. Ons lê die grondslag deur basiese konsepte soos kodering, HTTPS en die aard van internetverbindings te ondersoek..
Hopelik sal u teen die einde vertroue hê oor die keuse, aankoop en implementering van 'n TLS-sertifikaat, en onthou as u enige vrae het wat u in die kommentaar hieronder kan lewer..
1.1 'N Kwessie van die uitruil van sleutels
1.2 Laat ons nou oor 'n paar sleutelterme gaan
2 Bou van 'n openbare sleutelinfrastruktuur
3 SSL / TLS sertifikaat tipes en funksionaliteit
3.1 Hoeveel identiteite moet aangevoer word
4 Watter eindpunte om op Identiteit te beweer
4.1 Enkel domein
4.3 Wildcard SSL-sertifikate
4.4 Multi-domein Wildcard
5 SSL / TLS in beweging
5.1 Bekragtiging en uitreiking
5.2 Verifikasie en die SSL-handdruk
6 Na SSL / TLS – om die beste uit u implementering te put
6.1 Deaktiveer bedienerondersteuning vir ou protokolle
6.2 SSL altyd aan
6.3 Stel 'n CAA-rekord vir sertifikaatowerhede op
6.4 Voeg u webwerf by die HSTS Preload List
Laat ons begin met die bespreking van die konsep wat die kern vorm van dit alles: kodering.
Enkodering, in sy eenvoudigste iterasie, is weinig meer as die skrapping van data – met behulp van 'n voorafbepaalde kode of sleutel – sodat dit onleesbaar gemaak word deur iemand behalwe 'n ander party met dieselfde private sleutel..
Privaat sleutel-kodering was deur die geskiedenis die algemeenste model wat gebruik is. In enkripsie met privaat sleutels moet beide partye 'n privaat sleutel besit of ten minste ruil wat gebruik kan word om inligting te versleut en te ontsyfer.
Vroeg op was die meeste cifers wat hierdie kriptosisteme onderlê primitief, en vertrou op eenvoudige vervangings of vervang gewone woorde met karakters. Maar met verloop van tyd het die tjipers meer beïnvloed deur wiskunde en het dit in ingewikkeldheid gegroei.
Byvoorbeeld, in die middel van die 1600's in Frankryk het die kriptograaf van King Louis XIV 'n kode geskep wat so goed ontwerp is dat dit eers 250 jaar later gebreek is en eers dan gedeeltelik. Tot vandag toe is daar rekords van honderde jare in die Franse argiewe wat nooit ontsyfer kan word nie.
Maar hoewel histories kodering 'n manier was om geheime of klandestiene te wees, het die koms van die internet die konsep meer hoofstroom gebring. Die internet is alomteenwoordig, en dit hanteer 'n verskeidenheid kritieke funksies. Miljoene mense gebruik dit elke dag om sensitiewe inligting te bekom en te stuur, hul finansies te bestuur, sake met sake te doen – noem maar op.
Die probleem is dat die internet nie heeltemal ontwerp is om te skaal volgens wat dit geword het nie. Vroeg in die dae toe die akademie en die Amerikaanse regering die eerste keer netwerkprotokolle ontwikkel het, is die internet slegs gesien as 'n meganisme vir die vrye uitruil van inligting tussen die regering en akademiese instellings. Op daardie stadium was kommersiële aktiwiteite onwettig aanlyn. e-handel was nog nie 'n woord wat nog nie uitgevind is nie. En die webwerf was meer 'n geografiese idee.
Dus, toe HTTP of die Hypertext Transfer Protocol vir die eerste keer in 1991 bekendgestel is, was die feit dat die verbindings wat dit gevorm het, data in gewone teks uitgeruil, nie 'n diskwalifiserende probleem nie.
Dinge is deesdae baie anders. Die inligting wat aanlyn uitgeruil word, is nie akademiese navorsing of vrylik beskikbare inligting nie; dit is persoonlik identifiseerbare inligting en sensitiewe inligting wat mense geld of selfs in sommige streke hul lewens kan kos. Dit vra vir 'n veiliger benadering.
Die antwoord was kodering.
'N Kwessie van die uitruil van sleutels
Een probleem wat selfs die beste kriptosisteme histories geteister het, bly steeds tot vandag toe.
Wat ons vroeër bespreek het, en wat tradisioneel die standaard vir kodering was, is kodering vir privaat sleutels. Dit word ook simmetriese enkripsie genoem, of tweerigting-kodering – met privaat sleutels wat beide die koderings- en dekripsiefunksies hanteer wat nodig is om te kommunikeer.
Vir kodering van privaat sleutels om te werk, moet die private sleutel tussen partye oorgedra word, of albei partye moet oor hul eie kopie beskik. Hoe dan ook, privaat sleutelsekuriteit was van kritieke belang vir die integriteit van die kriptosisteem, en soos u ongetwyfeld kan vermoed, is sleuteluitruiling 'n probleem so oud soos kodering self.
Toe, in die 1970's – tegnies twee verskillende tye, 'n hele oseaan uitmekaar – is 'n nuwe vorm van kodering gekonseptualiseer en tot lewe gebring: kodering van openbare sleutel.
Terwyl die kodering van privaat sleutels 'n tweerigtingfunksie is, simmetries, met die privaat sleutel wat data kan kodering en dekripteer, is die sleutelkodering asimmetries; eenrigting. In plaas van 'n enkele private sleutel, is daar 'n publiek-private sleutelpaar. Die openbare sleutel hanteer kodering en is, soos die naam aandui, in die openbaar beskikbaar, terwyl die private sleutel, wat dekripsie hanteer, deur die eienaar geheim gehou word. Met behulp van die openbare sleutel kan 'n mens 'n stukkie data versleut en dit na die eienaar van die sleutel stuur, waar slegs hulle dit kan dekripteer.
Geweldig, maar hoe is dit nuttig??
Een-rigting enkripsie is nie ideaal vir die versleuteling van internetverbindings nie, dit is moeilik om te kommunikeer wanneer een party slegs kan enkripteer, en die ander slegs kan dekripteer. Nee, om 'n internetverbinding te enkripteer, moet u simmetriese, privaat sleutelskripsie gebruik.
Maar hoe ruil jy sleutels uit? Veral aanlyn?
Enkripsie van die openbare sleutel.
En dit, tot in wese gedistilleer, is waaroor SSL / TLS gaan: veilige sleutelruil.
Dit is hier waar ons al hierdie konsepte sal verbind. As u wil hê dat u kommunikasie met 'n webwerf privaat moet wees, moet u veilig daarmee skakel. As u veilig met die webwerf wil skakel, moet u simmetriese privaat sleutels uitruil sodat u dit kan gebruik om te kommunikeer. SSL / TLS (en PKI in die algemeen) is net 'n deftige meganisme om die sessiesleutel te skep en uit te ruil.
Deur gebruik te maak van SSL / TLS, kan u die bediener of organisasie waarmee u gaan skakel, verifieer en verseker dat u die private sleutels wat u sal gebruik, veilig uitruil om u kommunikasie met die beoogde party te versleut.
Ongelukkig het SSL / TLS en PKI baie terminologie en bewegende dele wat mense maklik kan verwar, maar diegene glo die feit dat as u al die wiskunde en die tegniese jargon wegneem, dit net 'n elegante moderne tegnologiese oplossing vir 'n era is -out probleem: sleutel ruil.
Laat ons nou oor 'n paar sleutelterme gaan
Voordat ons verder gaan, gaan ons oor 'n paar ander sleutelterme. Ons het reeds HTTP, hiperteksoordragprotokol, bekendgestel wat al dekades lank die ruggraat van die internet is. Maar soos ons bespreek het, het die internet ontwikkel in iets anders as wat dit was toe HTTP die eerste keer in 1991 gepubliseer is.
'N Veiliger protokol was nodig. Dus, HTTPS.
HTTPS, wat soms HTTP via TLS genoem word, gebruik enkripsie om die data wat tydens 'n verbinding uitgeruil word, vir niemand behalwe die beoogde party te lees nie. Dit is veral belangrik as u die aard van 'n moderne internetverbinding oorweeg.
Terwyl 'n verbinding in die vroeë dae van die internet redelik direk was, word verbindings nou deur dosyne toestelle gesit op pad na hul eindbestemming. As u ooit 'n praktiese demonstrasie hiervan wou gehad het, open die opdrag op u OS en voer die opdrag "tracert geekflare.com."
Wat u sal sien, is die pad wat u verbinding onderweg na die bestemming afgelê het. Tot 30 spronge. Dit beteken dat u data deur elk van hierdie toestelle gaan voordat dit enige webwerf of program waaraan u skakel, bereik. En as iemand 'n pakketsnyer of 'n luisteraar op enige een van hierdie toestelle geïnstalleer het, kan hy die data wat oorgedra is, steel en selfs die verbinding in sommige gevalle manipuleer..
Dit word 'n man-in-die-middel-aanval (MITM) genoem.
As u wil leer oor MITM-aanval, dan kyk na hierdie aanlynkursus.
Daar is baie meer oppervlaktes met moderne internetverbindings te dek as wat die oorgrote meerderheid mense besef, en dit is die rede waarom die data gekodeer tydens die oordrag van kritieke belang is. U weet nie wie luister of hoe maklik dit maklik is om te doen nie.
'N HTTP-verbinding word via poort 80 gemaak. Vir ons doeleindes kan u aan hawens dink as konstruksies wat 'n netwerkdiens of protokol aandui. 'N Standaard webwerf wat via HTTP bedien word, gebruik poort 80. HTTPS gebruik meestal poort 443. Wanneer 'n webwerf 'n sertifikaat installeer, kan dit sy HTTP-bladsye na HTTPS-bladsye herlei, en gebruikers se blaaiers sal poog om veilig via poort 443 te koppel, in afwagting van verifikasie..
Ongelukkig word die terme SSL / TLS, HTTPS, PKI en enkripsie baie rondgegooi, soms selfs uitruilbaar gebruik, sodat u enige verwarring kan oplos, hier is 'n vinnige gids:
SSL – Secure Sockets Layer, die oorspronklike koderingsprotokol wat met HTTPS gebruik word
TLS – Transport Layer Security, die meer onlangse koderingsprotokol wat SSL vervang het
HTTPS – Die veilige weergawe van HTTP, wat gebruik word om verbindings met webwerwe te skep
PKI – Openbare sleutelinfrastruktuur, verwys na die volledige trustmodel wat die kodering van openbare sleutels vergemaklik
SSL / TLS werk saam om HTTPS-verbindings moontlik te maak. En PKI verwys na die hele ding as jy uitzoom.
Het dit? Moenie bekommerd wees nie, jy sal.
Bou van 'n openbare sleutelinfrastruktuur
Noudat ons die grondslag gelê het, laat ons uitzoom en kyk na die argitektuur wat gebruik word deur die trustmodel in die hartjie van SSL / TLS.
As u op 'n webwerf aankom, is dit die eerste ding wat u blaaier doen om die egtheid van die SSL / TLS-sertifikaat te verifieer waarop die webwerf dit bied. Ons sal agterkom wat gebeur nadat die verifikasie in 'n paar afdelings plaasvind, maar ons sal begin met die vertrouensmodel wat dit alles moontlik maak.
Ons begin dus met die vraag: hoe weet my rekenaar of ek 'n gegewe SSL / TLS-sertifikaat moet vertrou?
Om dit te beantwoord, sal ons PKI moet bespreek en die verskillende elemente wat dit laat werk. Ons begin met sertifikaatowerhede en wortelprogramme.
'N Sertifikaatowerheid is 'n organisasie wat voldoen aan 'n stel voorafbepaalde standaarde in ruil vir die vermoë om betroubare digitale sertifikate uit te reik.
Daar is tientalle CA's, beide gratis en kommersieel, wat betroubare sertifikate kan uitreik.
Hulle moet almal voldoen aan 'n stel standaarde wat deur die CA / Browser Forum, wat optree as die regulerende liggaam vir die TLS-bedryf, gedebatteer en wetgewend is. Hierdie standaarde gee 'n uiteensetting van dinge soos:
Tegniese voorsorgmaatreëls wat in plek moet wees
Beste praktyke vir die uitvoering van validering
Beste praktyke vir uitreiking
Herroeping prosedures en tydlyne
Hierdie riglyne is deur die blaaiers uiteengesit, in samewerking met die CA's. Die blaaiers speel 'n unieke rol in die TLS-ekosisteem.
Niemand kan êrens op die internet kom sonder hul webblaaier nie. As sodanig is dit die blaaier wat die digitale TLS-sertifikaat sal ontvang en valideer en dan sleutels met die bediener sal verruil. Dus, gegewe hul grootste rol, het hulle aansienlike invloed.
En dit is belangrik om in gedagte te hou dat blaaiers so ontwerp is dat hulle so skepties as moontlik is. Om niks te vertrou nie. Dit is die beste manier om hul gebruikers veilig te hou. Dus, as 'n blaaier 'n digitale sertifikaat gaan vertrou – wat potensieel tot die gebruiker kan benut word, is dit seker dat die persoon wat hierdie sertifikaat uitgereik het, die nodige omsigtigheid gedoen het.
Dit is die rol en verantwoordelikheid van die Sertifikaatowerhede. En die blaaiers hou ook nie foute nie. Daar is 'n letterlike begraafplaas van voormalige CA's wat deur die blaaiers gevloei het en met weiding gesit is.
As 'n sertifikaatowerheid bewys het dat hy aan die basisvereistes van die CAB Forum voldoen het en al die nodige oudits en oorsigte geslaag het, kan dit die verskillende wortelprogramme indien om sy wortelsertifikate by te voeg.
'N Wortelprogram – die belangrikste word bestuur deur Apple, Microsoft, Google en Mozilla – is die apparaat wat toesig hou oor die wortelwinkels (soms trustwinkels genoem), wat versamelings van wortel CA-sertifikate is wat op die gebruiker se stelsel geleë is. Hierdie wortels is weereens ongelooflik waardevol en ongelooflik gevaarlik – hulle kan immers betroubare digitale sertifikate uitreik – daarom is veiligheid uiters kommerwekkend.
Daarom reik CA's byna nooit direk uit die Root CA-sertifikate uit nie. In plaas daarvan trek hulle intermediêre wortelsertifikate op en gebruik hulle om eindgebruikers- of blaarsertifikate uit te reik. Hulle kan ook hierdie wortels aan sub-CA's oorhandig, wat sertifikaatowerhede is wat nie hul toegewyde wortels het nie, maar steeds kruisondertekende sertifikate van hul tussengangers kan uitreik.
Kom ons stel dit alles saam. As 'n webwerf 'n TLS-sertifikaat wil hê, word dit op die bediener waarop dit aangebied word genereer, genaamd 'n Certificate Signing Request (CSR). In hierdie versoek is al die besonderhede wat die webwerf op die sertifikaat wil insluit, ingesluit. Soos u 'n bietjie sien, kan die hoeveelheid inligting wissel van volledige besigheidsinligting tot 'n eenvoudige bedieneridentiteit, maar sodra die CSR voltooi is, word dit na die sertifikaatowerheid gestuur vir uitreiking.
Voordat die sertifikaat uitgereik word, moet die CA sy CA / Browser Forum-mandaat met behoorlike omsigtigheid doen en bevestig dat die inligting in die CSR akkuraat is. Sodra dit geverifieer is, onderteken dit die sertifikaat met sy privaat sleutel en stuur dit terug na die eienaar van die webwerf vir installasie.
Nadat die TLS-sertifikaat geïnstalleer is, sal die gebruiker se blaaier met die sertifikaat enige tyd wat iemand die webwerf besoek waar die bediener dit huisves. Die blaaier gaan kyk na die digitale handtekening op die sertifikaat, die een wat deur die betroubare sertifikaatowerheid gemaak is, en dit bevestig dat alle inligting in die sertifikaat korrek is.
Dit is hier waar die begrip sertifikaatketting speel.
Die blaaier gaan die digitale handtekening lees en 'n skakel na die ketting opskuif; daarna sal die digitale handtekening op die intermediêre sertifikaat gekyk word waarvan die private sleutel gebruik is om die blaarsertifikaat te onderteken. Dit sal voortgaan om handtekeninge te volg totdat die sertifikaatketting eindig by een van die vertroude wortels in die wortelstoor, of totdat die ketting eindig sonder om 'n wortel te bereik, in welke geval 'n blaaierfout sal verskyn en die verbinding sal misluk.
Daarom kan u nie u sertifikate uitreik en self onderteken nie.
Die blaaiers vertrou slegs SSL / TLS-sertifikate wat hulle kan terugketting na hul wortelstoor (wat beteken dat dit deur 'n betroubare entiteit uitgereik is). Sertifikaatowerhede moet aan spesifieke standaarde voldoen om hul betroubaarheid te handhaaf, en selfs dan is die blaaiers moedeloos om hulle te vertrou.
Blaaiers kan nie so 'n versekering gee oor selfondertekende sertifikate nie, en daarom moet dit slegs op interne netwerke, agter firewalls en in toetsomgewings ontplooi word..
SSL / TLS sertifikaat tipes en funksionaliteit
Voordat ons SSL / TLS aan die gang kyk, kom ons praat oor sertifikate en die verskillende iterasies wat beskikbaar is. TLS-sertifikate vergemaklik die TLS-protokol en help om die bepalings van die gekodeerde HTTPS-verbindings wat 'n webwerf maak, te bepaal.
Ons het vroeër genoem dat die installering van 'n TLS-sertifikaat u in staat stel om u webwerf op te stel om HTTPS-verbindings via poort 443 te maak. Dit dien ook as 'n soort naamwapen vir die webwerf of bediener waarmee u kommunikeer. As ons terugkeer na die idee dat SSL / TLS en PKI uiters uitstekende vorms van veilige sleuteluitruiling is, help die SSL / TLS-sertifikaat om die blaaier in kennis te stel van wie hy die sessiesleutel stuur – wie die party aan die ander kant van die konneksie is.
En as u die verskillende iterasies van SSL / TLS-sertifikate uiteensit, is dit 'n toepaslike ding om in gedagte te hou. Sertifikate verskil ten opsigte van funksionaliteit en valideringsvlak. Of om dit anders te sê, dit verskil volgens die volgende:
Hoeveel identiteite moet aangevoer word
Watter eindpunte om identiteit aan te voer
As u hierdie twee vrae beantwoord, sal u 'n duidelike aanduiding gee van watter tipe sertifikaat u benodig.
Daar is drie verskillende vlakke van bekragtiging beskikbaar met SSL / TLS-sertifikate, en dit wissel na gelang van hoeveel identiteitsinligting u webwerf wil aanvoer..
Domeinvalidering SSL-sertifikate – voer bedieneridentiteit aan
Organisasie-validering SSL-sertifikate – Stel gedeeltelike organisasie-identiteit aan
SSL-sertifikate vir uitgebreide geldigheid – gee volledige identiteit aan die organisasie
Domeinvalidering SSL-sertifikate is verreweg die gewildste weens die prys en die spoed waarmee dit uitgereik kan word. 'N DV SSL / TLS-sertifikaat benodig 'n eenvoudige kontrole vir domeinkontrole wat op verskillende maniere uitgevoer kan word, maar sodra dit wel is, kan die sertifikaat uitgereik word. U kan ook 'n paar weergawes van 30 dae en 90 dae gratis kry, wat ongetwyfeld tot hul markaandeel bygedra het..
Die nadeel is dat DV SSL-sertifikate minimale identiteit het. Aangesien byna die helfte van alle uitvissingswebwerwe nou 'n DV SSL-sertifikaat op hulle het, koop hulle jou nie noodwendig veel in die manier van vertroue nie.
Organisasie-validering SSL-sertifikate is die oorspronklike tipe SSL / TLS-sertifikaat. Dit is ook die enigste soort SSL-sertifikaat wat 'n IP-adres kan beveilig na 'n 2016-besluit deur die CAB Forum om alle intranet-SSL-sertifikate ongeldig te maak. Organisasie-bekragtiging vereis 'n ligte besigheidsmeting en kan gewoonlik binne 'n dag of twee uitgereik word – soms vinniger. OV SSL-sertifikate beweer organisatoriese inligting, maar 'n internetgebruiker moet op die hangslot-ikoon klik en daarna kyk. Deesdae sien u baie OV SSL-sertifikate wat op groot ondernemings- en korporatiewe netwerke ontplooi word, byvoorbeeld vir verbindings agter firewalls..
Omdat nie DV of OV SSL-sertifikate voldoende identiteit het om die meeste blaaiers te bevredig nie, kry hulle neutrale behandeling.
SSL-sertifikate vir uitgebreide geldigheid is verreweg die mees kontroversiële, aangesien sommige in die tegnologegemeenskap voel dat daar meer gedoen moet word om die bevestiging te versterk waarop hulle afhanklik is. Maar EV SSL voer aan maksimum identiteit. Om die uitgebreide bekragtiging te voltooi, plaas die Sertifikaatowerheid die organisasie deur middel van 'n streng keuringsproses wat in sommige gevalle tot 'n week kan duur.
Maar die voordeel is onmiskenbaar: omdat dit voldoende identiteit gee, ontvang 'n webwerf met 'n EV SSL-sertifikaat unieke blaaierbehandeling, insluitend dat die naam daarvan in die adresbalk van die blaaier vertoon word.
Daar is geen ander manier om dit te bewerkstellig nie, en u kan dit nie namaak nie – die EV-adresbalk is een van die kragtigste visuele aanwysers wat ons vandag het.
Watter eindpunte om op Identiteit te beweer
Die ander manier waarop SSL / TLS-sertifikate verskil, is met betrekking tot funksionaliteit. Webwerwe het sedert die vroeë dae van die internet taamlik ontwikkel, met verskillende ondernemings wat webwerwe op verskillende maniere ontplooi. Sommige het verskeie domeine vir verskillende ondernemingsvertikale; ander gebruik sub-domeine vir verskeie funksies en webtoepassings. Sommige gebruik albei.
Dit maak nie saak wat die konteks is nie, daar is 'n SSL / TLS-sertifikaat wat kan help om dit te beveilig.
Die primêre webwerf en die standaard SSL-sertifikaat is slegs 'n enkele domein. Die meeste moderne SSL / TLS-sertifikate sal beide die WWW- en nie-WWW-weergawes van daardie domein beveilig, maar dit is beperk tot 'n enkele domein. Jy kan vergelyk die SSL-sertifikate hier.
Multi-domeinsertifikate of eenvormige kommunikasiesertifikate (in die geval van Microsoft Exchange en Office Communications-bedieners) bestaan ​​ook om organisasies die vermoë te gee om verskeie domeine met 'n enkele sertifikaat te enkripteer. Dit kan 'n aantreklike opsie wees, aangesien dit geld bespaar en dit die bestuur van die sertifikate (verstrykings / hernuwings) baie eenvoudiger maak.
Multi-domein- en UCC-sertifikate gebruik SAN, die veld Alternatiewe naam in die CSR, om addisionele domeine tot die sertifikaat toe te voeg. Die meeste CA's laat tot 250 verskillende SAN's toe op 'n enkele sertifikaat. En die meeste Multi-Domain-sertifikate bevat 2-4 komplimentêre SAN's, met die res beskikbaar om te koop.
Wildcard SSL-sertifikate is 'n uiters nuttige sertifikaattipe omdat dit 'n onbeperkte aantal subdomeine op dieselfde vlak van die URL kan enkripteer. As u byvoorbeeld 'n webwerf het wat sub-domeine gebruik, soos:
U kan almal met dieselfde Wildcard-sertifikaat enkripteer deur 'n sterretjie te gebruik in die FQDN-veld van u CSR: * .website.com
Nou kan enige sub-domein, selfs dié wat u nog nie bygevoeg het nie, met daardie sertifikaat beveilig word.
Daar is egter twee nadele van Wildcard-sertifikate. Die eerste is dat u deur die gebruik van dieselfde openbare sleutel oor sekere eindpunte meer kwesbaar is vir sekere uitbuiterings soos Bleichenbacher-aanvalle.
Die ander is dat daar geen EV Wildcard-opsie is nie. As gevolg van die openlike aard van Wildcard-funksies, is die blaaiers nie in orde met die delegering van daardie vlak van vertroue nie. As u die EV-adresbalk op u subdomeine wil hê, moet u dit afsonderlik enkripteer of 'n EV-multi-domeinsertifikaat gebruik.
'N Relatief nuwe toevoeging tot die SSL / TLS-ekosisteem, die Multi-Domain Wildcard kan tot 250 verskillende domeine enkripteer, maar dit kan ook 'n sterretjie in die SAN-velde gebruik, wat u ook toelaat om 250 verskillende domeine te enkripteer en al hul gepaardgaande eerste -lewe subdomeine.
'N Ander gebruikskas vir die Multi-Domain Wildcard is as 'n multi-level Wildcard, waar dit subdomeine op verskillende vlakke van die URL kan enkripteer ('n standaard Wildcard kan dit slegs op een vlak enkripteer).
Vanweë die Wildcard-funksionaliteit is Multi-Domain Wildcards ook nie in EV beskikbaar nie.
SSL / TLS in beweging
Noudat ons al die belangrike konsepte behandel wat SSL / TLS en PKI opmaak, laat ons dit alles bymekaar sit en dit in beweging sien.
Bekragtiging en uitreiking
Laat ons heel aan die begin begin met 'n webwerf wat 'n SSL / TLS-sertifikaat by 'n CA of herverkoper koop. Na die aankoop skep die organisatoriese kontak wat die sertifikaatverkryging hanteer, 'n sertifikaatondertekeningsversoek op die bediener waar die sertifikaat geïnstalleer sal word (die bediener wat die webwerf huisves).
Saam met die CSR sal die bediener ook 'n openbare / private sleutelpaar genereer en die private sleutel plaaslik stoor. Wanneer die CA die CSR en die Public Key ontvang, voer dit die nodige stappe uit om te verseker dat die inligting in die sertifikaat korrek is. Oor die algemeen behels dit dat die organisasie se registrasie-inligting en openbare rekords in regeringsdatabasisse opgesoek word (nie DV nie)..
Nadat die validasie voltooi is, gebruik die CA een van die privaat sleutels van een van sy sertifikate wat gewoonlik uitgereik is, tipies 'n tussentydse wortel, en teken dit die sertifikaat voordat dit aan die eienaar van die werf terugbesorg word.
Nou kan die webwerf-eienaar die nuut uitgereikte SSL / TLS-sertifikaat neem, dit op hul bediener installeer en die webwerf opstel om HTTPS-verbindings op poort 443 te maak (met behulp van 301 aansture om verkeer vanaf die bestaande HTTP-bladsye na hul nuwe HTTPS-eweknieë te stuur).
Verifikasie en die SSL-handdruk
Noudat die SSL / TLS-sertifikaat geïnstalleer is en die webwerf vir HTTPS gekonfigureer is, kan ons kyk hoe dit geënkripteerde verbindings met die besoekers van die webwerf sal vergemaklik.
By die aankoms van die webwerf sal die bediener die SSL / TLS-sertifikaat aan die gebruiker se blaaier aanbied. Die gebruiker se blaaier voer dan 'n reeks tjeks uit.
Eerstens gaan dit die sertifikaat verifieer deur die digitale handtekening te sien en die sertifikaatketting te volg. Dit sal ook seker maak dat die sertifikaat nie verval het nie en dat die sertifikate-deursnee-logboeke (CRL's) en sertifikate-herroepinglyste (CRL's) nagegaan word. Mits die ketting na een van die wortels in die trustwinkel van die stelsel lei, en dat dit geldig is, sal die blaaier die sertifikaat vertrou.
Nou is dit die handskud tyd.
Die SSL / TLS-handdruk is die reeks stappe waar die kliënt (gebruiker) en die bediener (webwerf) die parameters van hul veilige verbinding onderhandel, simmetriese sessiesleutels genereer en dan uitruil.
Eerstens besluit hulle oor 'n kodeksuite. 'N Sifersuite is die groep algoritmes en chiffer wat vir die verbinding gebruik sal word. Die SSL / TLS-sertifikaat bevat 'n lys met kodeksuites wat die bediener ondersteun. Oor die algemeen bevat 'n kodeksuite 'n koderingsalgoritme vir openbare sleutels, 'n sleutelgenereringsalgoritme, 'n boodskapverifiëringsalgoritme en 'n simmetriese of grootmaat-koderingsalgoritme – hoewel dit in TLS 1.3 verfyn is..
Die kliënt kies 'n aangename een en word aan die bediener gekommunikeer nadat die lys met ondersteunende chiffer, aangebied word. Van daar af sal die kliënt 'n simmetriese sessiesleutel genereer, dit met die publieke sleutel enkripteer en dit dan na die bediener stuur, wat die private sleutel het wat nodig is om die sessiesleutel te dekodeer..
Sodra albei partye 'n afskrif van die sessiesleutel het, kan kommunikasie begin.
En dit is SSL / TLS.
U kan sien hoe al die konsepte wat ons vroeër deurgemaak het, met mekaar omgaan om 'n gesofistikeerde dog elegante stelsel te skep vir die beveiliging van internetverbindings. Ons gebruik kriptografie met 'n openbare sleutel om die sessiesleutels veilig uit te ruil met wie ons sal kommunikeer. Die sertifikate wat bedieners- of organisatoriese identiteit bevestig, kan vertrou word as gevolg van die infrastruktuur wat ons tussen die verskillende CA's, blaaiers en wortelprogramme het..
En kommunikasie vind plaas as gevolg van simmetriese, private sleutel-kodering wat afstam van die klassieke kriptosisteme van die oudheid.
Daar is baie bewegende dele, maar as jy almal afsonderlik vertraag en verstaan, is dit baie makliker om te sien hoe dit alles saamwerk.
Laat ons klaar wees met 'n paar SSL / TLS-verwante skuiwe wat jy na die installasie / opstelling kan maak om die beste uit jou belegging te put.
Na SSL / TLS – om die beste uit u implementering te put
As u 'n sertifikaat geïnstalleer het en u webwerf korrek opgestel is, beteken dit nie dat u webwerf veilig is nie. TLS is slegs een komponent van 'n breër, holistiese kuberverdedigingstrategie. Maar 'n belangrike komponent, nietemin. Kom ons bespreek 'n paar dinge wat u kan doen om te verseker dat u die beste uit die implementering put.
Deaktiveer bedienerondersteuning vir ou protokolle
As ons terugkeer na die gesprek wat ons vroeër oor Cipher Suites gehad het, is dit 'n deel van die opstel van u bediener om te besluit watter kodeksuites en SSL / TLS-weergawes moet ondersteun. Dit is noodsaaklik dat u ondersteuning vir ouer SSL / TLS-weergawes en spesifieke algoritmes deaktiveer om die kwesbaarheid van verskeie bekende ontginning te voorkom..
SSL 2.0 en SSL 3.0 is albei ouer as 20 jaar. Die beste praktyk was om jare gelede die steun daarvoor te verlaag, maar tot vandag toe laat ongeveer 7% van die Alexa-top 100,000 hulle steeds toe. Dit is gevaarlik omdat dit u blootstel aan SSL-aanvalle en afgradering soos POODLE.
TLS 1.0 en TLS 1.1 is ook op geleende tyd.
Die belangrikste tegnologiemaatskappye, Apple, Microsoft, Google en Mozilla, het die herfs 'n gesamentlike aankondiging gemaak dat hulle die begin van 2020 die ondersteuning vir TLS 1.0 en 1.1 sal verlaag..
Die protokolweergawes is vatbaar vir kwesbaarhede soos die POODLE, FREAK, BEAST en CRIME (dit is alles akronieme). TLS 1.2 is al tien jaar uit en behoort die standaard te wees. TLS 1.3 is verlede somer afgehandel en die aanneming beweeg sedertdien konstant.
Daar is ook spesifieke algoritmes wat ook nie gebruik moet word nie. DES kan byvoorbeeld binne enkele ure gebreek word. RC4 is kwesbaarder as wat vroeër geglo is en is reeds verbied deur die betalingskaartbedryf se standaarde vir datasekerheid. En ten slotte is dit nie raadsaam om RSA vir sleutelruil te gebruik nie, gegewe nuus oor onlangse uitbuiting.
Voorgestelde algoritmes / chiffer:
Sleutelruil: Elliffiese kurwe Diffie-Helman (ECDH)
Verifikasie: Elliptiese kurwe digitale handtekeningalgoritme (ECDSA)
Simmetriese / grootmaat-kodering: AES 256 in Galois-toonbankmodus (AES256-GCM)
MAC-algoritme: SHA-2 (SHA384)
SSL altyd aan
In die verlede het webwerwe soms net die webblaaie wat inligting versamel na HTTPS migreer terwyl hulle die res van die webwerf via HTTP bedien. Dit is 'n slegte praktyk.
Benewens die feit dat Google die bladsye "Nie veilig nie" sal merk, stel u die besoekers van u webwerf moontlik ook bloot aan risiko's deur hul blaaiers heen en weer te laat spring tussen geïnkripteer bladsye en HTTP-blaaie.
U moet u hele webwerf vir HTTPS opstel. Dit word altyd-op SSL genoem. Uiteindelik is dit nie asof u per bladsy betaal nie, u SSL / TLS-sertifikaat kan u hele werf versleut. So maak dit so.
Stel 'n CAA-rekord vir sertifikaatowerhede op
Een van die belangrikste risiko's wat digitale sertifikate inhou, is oor die algemeen verkeerde uitreiking. As 'n ander party dan u 'n SSL / TLS-sertifikaat vir U webwerf ontvang, kan hulle u effektief verpersoonlik en allerhande probleme veroorsaak.
CAA-rekords help om hierdie risiko te verminder deur te beperk wat sertifikaatowerhede digitale sertifikate vir u webwerf kan uitreik. Sertifikaatowerhede moet deur die CA / Browser Forum die CAA-rekords nagaan voordat hulle 'n sertifikaat uitgereik het. As die CA nie die magtiging het om vir daardie webwerf uit te reik nie, kan dit nie. As u dit doen, sou dit as 'n mis-uitgifte beskou word en die woede van die blaaiergemeenskap verower.
Om 'n CAA-rekord by te voeg, is relatief maklik, dit is 'n eenvoudige DNS-rekord wat bygevoeg kan word deur die koppelvlak van die meeste hosting-platforms. U kan die CA's wat vir u domein mag uitreik, beperk, of ook 'n Wildcard-sertifikaat daarvoor uitgereik kan word..
Voeg u webwerf by die HSTS Preload List
HTTP Strict Transport Security, of HSTS, is 'n HTTP-kop wat blaaiers net dwing om HTTPS-verbindings met 'n gegewe webwerf te maak. Op hierdie manier, selfs as die webgebruiker probeer om na die HTTP-weergawe van die bladsy te gaan, sal hulle uiteindelik net die HTTPS-weergawe besoek. Dit is belangrik omdat dit die venster sluit vir verskeie bekende misbruik, soos aanvalle op afgradering en kaping van koekies.
Ongelukkig bly daar 'n klein aanvalvektor by HSTS, en daarom moet u u webwerf by die voorlaadlys voeg. As 'n besoeker by u webwerf aankom, sal die blaaier gewoonlik die HTTP-kop aflaai en dit hou vir so lank as wat die beleid ingestel is om te hou. Maar op daardie heel eerste besoek, voordat die kop ontvang is, is daar nog steeds 'n klein opening vir 'n aanvaller.
Die HSTS-voorlyslys van rekords word bestuur deur Google en die variasie daarvan word deur alle groot blaaiers gebruik. Hierdie blaaiers weet net om via HTTPS aan te koppel aan enige webwerf wat op die lys is – selfs al is dit nog nooit tevore daar besoek nie. Dit kan 'n week of twee duur voordat u werf op die lys verskyn omdat die opdaterings van die lys saam met die vrystellingskedules van die blaaiers uitgeskuif word..
Wat is 'n X.509-sertifikaat?
X.509 verwys na die tipe digitale sertifikaat wat saam met SSL / TLS en ander soorte PKI gebruik word. X.509 is 'n koderingstandaard vir openbare sleutels. Soms sien u dat maatskappye X.509-sertifikaat gebruik in die plek van 'digitale sertifikaat' of 'PKI-sertifikaat'.
Waarom verval SSL / TLS-sertifikate?
Daar is twee redes hiervoor.
Die eerste is dat die internet voortdurend verander, webwerwe kom, en webwerwe gaan. En gesien hoe sensitief die blaaiers is oor die vertroue van hierdie sertifikate in die eerste plek, wil hulle weet dat die webwerwe wat die sertifikate aanbied, gereeld validering ondergaan. Dit verskil nie van hoe u by geleentheid moet aanmeld om die inligting op u rybewys op te dateer nie.
Die ander rede is meer tegnies. Dit is moeiliker om opdaterings en tegniese veranderinge te versprei wanneer sertifikate nie vir 3-5 jaar verval nie. Terwyl sertifikate elke 24 maande verval, is die langste dat 'n sertifikaat verouderd is, twee jaar. In 2017 is die maksimum geldigheid van drie jaar na twee verminder. Dit sal waarskynlik binnekort tot 12 maande verkort word.
Hoe kan u 'n SSL / TLS-sertifikaat hernu??
Hernuwing kan 'n bietjie verkeerde naam wees omdat u die ou sertifikaat vervang met 'n pas uitgereikte sertifikaat. Deur dit gereeld te doen, kan u op hoogte bly van nuwe vorderings met koderingstegnologie en u verseker dat u geldigheidsinligting op datum bly. CA's kan slegs die validasie-inligting wat aanvanklik so lank gelede verskaf is, weer gebruik voordat die basisvereistes hulle verplig om dit weer te valideer.
As u hernu, kan u dieselfde sertifikaattipe behou as wat u voorheen gehad het, of u kan saamgaan met iets nuuts, of u kan selfs CA's verander. Die groot ding is hoeveel tyd u oorbly op die sertifikaat wat verval – u kan tot drie maande oorskry. Solank u hernu voordat die sertifikaat verval, kan u enige oorblywende tyd oorskry en die geldigheidsinligting wat nog nie uitgestel is sedert u laaste validering nie, weer gebruik. As u dit laat verval, begin u van voor af.
Wat is HTTPS-inspeksie?
Baie groter ondernemings met groter netwerke hou daarvan om sigbaar te wees oor hul verkeer. In hierdie opsig is HTTPS 'n tweesnydende swaard. Dit beskerm mense se privaatheid, maar dit kan ook help om kuberkriminele weg te steek. Baie organisasies dekripteer hul HTTPS-verkeer op 'n randtoestel of 'n middelkissie en stuur dit óf in gewone teks agter hul firewall aan, óf versleut dit weer en stuur dit onderweg. As u die verkeer nie weer enkripteer nie, word dit SSL-beëindiging genoem. As u weer enkripteer, word dit SSL-oorbrugging genoem.
Wat is SSL-aflaai??
SSL-aflaai is 'n ander ondernemingspraktyk. Op skaal kan duisende handdrukke uitgevoer word en dan al die data geïnkripteer en ontsyfer kan dit 'n netwerk se hulpbronne belas. Dus, baie groter netwerke sal die SSL-funksies na 'n ander toestel aflaai, sodat die toepassingsbediener op sy kerntake kan fokus. Dit word soms lasbalansering genoem.
Waarom het my CA my 'n intermediêre sertifikaat gestuur?
Onthou dit vroeër toe ons wortelprogramme bespreek het?
Baie OS het 'n wortelwinkel wat dit gebruik om PKI-trustuitsprake te maak. Die CA's gee egter nie die einde van die gebruiker se sertifikate uit vrees vir wat sou gebeur as iemand ooit herroep sou word nie. In plaas daarvan trek hulle intermediêre wortels op en lewer dit uit. Die probleem is dat intermediêre wortels nie in die trustwinkel van 'n stelsel woon nie.
Dus, as die webwerf nie die intermediêre sertifikaat saam met die blaar SSL / TLS-sertifikaat aanbied nie, sal baie blaaiers nie die sertifikaatketting kan voltooi nie en sal hulle 'n waarskuwing uitreik. Sommige blaaiers doen tussentydse sertifikate, maar dit word steeds beskou as die beste praktyk om enige tussengangers saam met u blaarsertifikaat te installeer.
Watter dokumentasie het ek nodig vir 'n SSL-sertifikaat vir uitgebreide validering??
In die meeste gevalle sal die Sertifikaatowerheid wat die uitgebreide bekragtiging doen, eers probeer om toegang tot die inligting te verkry deur middel van 'n openbare owerheidsbron.
Op sommige plekke is dit miskien nie moontlik nie. Daar is 'n paar dinge wat u kan help om die validering te bespoedig. Alhoewel die aantal valideringskontroles waaraan 'n professionele opiniebrief kan voldoen, onlangs verminder is, kan 'n prokureur of rekenmeester met 'n goeie status teken nog steeds aansienlik help.
Boonop kan u 'n besigheidsbewys of 'n bewys van die reg wat deur die regering uitgereik is, voorsien wat u organisasie die reg gee om onder die genoemde naam sake te doen. Voorbeelde van hierdie dokumente is:
Artikels van inlywing
Besigheid- / verskaffer- / handelaarslisensies
Registrasie van handel of veronderstelde naam
In die sluiting
Ek hoop dit gee u 'n idee oor SSL / TLS. As u belangstel om meer te leer, sal ek dit aanbeveel neem hierdie aanlynkursus.
Hierdie boodskap is bygedra deur Patrick Nohe, redakteur van Hashed Out deur die SSL-winkel, 'n blog wat nuus en neigings oor kuberveiligheid dek.