Een diepgaande blik op de encryptie die onze internetverbindingen beveiligt
Hoewel Netscape oorspronkelijk halverwege de jaren 90 SSL uitvond, werd het niet verplicht voor elke website om een SSL / TLS-certificaat te installeren tot de zomer van 2018, toen Google begon met het markeren van niet-versleutelde sites “Niet veilig.”
Hoewel Google – met zijn zoekmachine, Chrome-browser en Android-besturingssysteem – het internet eenzijdig kan herdefiniëren, stond het niet alleen in dit mandaat. Apple, Microsoft, Mozilla en de andere grote belanghebbenden in de technische industrie hebben allemaal een gezamenlijk besluit genomen om SSL / TLS-certificaten en HTTPS te verplichten.
De reden hiervoor is simpel: zonder SSL / TLS en de mogelijkheid om veilig verbinding te maken via HTTPS, zou alle communicatie tussen websites en hun bezoekers in platte tekst worden uitgewisseld en gemakkelijk leesbaar zijn door een derde partij.
Het enige nadeel van deze recente push voor universele encryptie is dat het een toestroom van nieuwe klanten naar een onbekende markt heeft gedwongen, een markt die zichzelf weinig minder verwarrend maakt voor de gemiddelde website of bedrijfseigenaar.
Dit artikel zal dienen als een uitgebreide gids voor alles wat met SSL / TLS te maken heeft, we zullen de basis leggen door basisconcepten te bespreken zoals encryptie, HTTPS en de aard van internetverbindingen.
Hopelijk heb je uiteindelijk vertrouwen in het selecteren, kopen en implementeren van een TLS-certificaat en onthoud als je vragen hebt dat je ze kunt achterlaten in de reacties hieronder.
Contents
Fundamentele elementen
Laten we beginnen met het bespreken van het concept dat centraal staat in dit alles: encryptie.
Versleuteling is in zijn meest eenvoudige iteratie niet veel meer dan het door elkaar gooien van gegevens – met behulp van een vooraf bepaald cijfer of sleutel – zodat het door iedereen behalve een andere partij met dezelfde privésleutel onleesbaar wordt gemaakt..
Door de geschiedenis heen is versleuteling met persoonlijke sleutels het meest gebruikte model geweest. Bij de versleuteling van privésleutels moeten beide partijen een privésleutel bezitten of uitwisselen die kan worden gebruikt om informatie zowel te versleutelen als te ontsleutelen.
In het begin waren de meeste cijfers die aan deze cryptosystemen ten grondslag lagen primitief, vertrouwden ze op eenvoudige vervangingen of vervingen ze gewone woorden door tekens. Maar na verloop van tijd werden de cijfers meer beïnvloed door wiskunde en werden ze steeds complexer.
Halverwege de 17e eeuw in Frankrijk creëerde de cryptograaf van koning Lodewijk XIV bijvoorbeeld een cijfer dat zo goed was ontworpen dat het pas 250 jaar later werd verbroken en pas daarna gedeeltelijk. Tot op de dag van vandaag zijn er honderden jaren aan archieven in de Franse archieven die misschien nooit zullen worden ontcijferd.
Maar terwijl encryptie van oudsher een middel was om heimelijk of clandestien te zijn, heeft de opkomst van internet het concept meer mainstream gemaakt. Het internet is alomtegenwoordig en het behandelt een reeks essentiële functies. Elke dag gebruiken miljarden mensen het om gevoelige informatie te openen en te verzenden, hun financiën te beheren en zaken te doen met bedrijven – noem maar op.
Het probleem is dat internet niet helemaal is ontworpen om te schalen naar wat het is geworden. Vroeger, in de tijd dat de academische wereld en de Amerikaanse regering voor het eerst netwerkprotocollen ontwikkelden, werd internet alleen gezien als een mechanisme voor de vrije uitwisseling van informatie tussen de regering en academische instellingen. Op dat moment was commerciële activiteit online illegaal. eCommerce was nog geen woord dat ooit was uitgevonden. En website was meer een geografisch begrip.
Dus toen HTTP of het Hypertext Transfer Protocol voor het eerst werd geïntroduceerd in 1991, was het feit dat de verbindingen die het vormde gegevens uitwisselden in platte tekst geen diskwalificerend probleem.
De dingen zijn tegenwoordig heel anders. De informatie die online wordt uitgewisseld, is geen academisch onderzoek of vrij beschikbare informatie, het is persoonlijk identificeerbare informatie en gevoelige gegevens die mensen geld of zelfs, in sommige regio’s, hun leven kunnen kosten. Dit vereiste een veiligere aanpak.
Het antwoord was codering.
Een probleem met het uitwisselen van sleutels
Een probleem dat in het verleden zelfs de beste cryptosystemen heeft geplaagd, blijft tot op de dag van vandaag bestaan.
Wat we eerder bespraken, en wat traditioneel de standaard voor codering was, is codering van privésleutels. Dit wordt ook symmetrische codering of tweewegscodering genoemd – met privésleutels die zowel de coderings- als de decoderingsfuncties verwerken die nodig zijn om te communiceren.
Om de versleuteling van de privésleutel te laten werken, moet de privésleutel tussen partijen worden overgedragen, of beide partijen moeten over een eigen kopie beschikken. Hoe dan ook, de beveiliging van privésleutels was van cruciaal belang voor de integriteit van het cryptosysteem en, zoals u ongetwijfeld kunt vermoeden, is sleuteluitwisseling een probleem zo oud als encryptie zelf.
Toen, in de jaren 70 – technisch gezien twee verschillende tijden, een hele oceaan uit elkaar – werd een nieuwe vorm van encryptie bedacht en tot leven gebracht: encryptie met openbare sleutels.
Terwijl versleuteling met privésleutels een tweerichtingsfunctie is, symmetrisch, met de privésleutel die zowel gegevens kan versleutelen als ontsleutelen, is versleuteling met openbare sleutels asymmetrisch; een manier. In plaats van een enkele privésleutel, is er een publiek-privaat sleutelpaar. De openbare sleutel behandelt de codering en is, zoals de naam al aangeeft, openbaar beschikbaar, terwijl de privésleutel, die de decodering afhandelt, door de eigenaar geheim wordt gehouden. Met behulp van de openbare sleutel kan men een stuk gegevens versleutelen en naar de eigenaar van de sleutel sturen, waar alleen zij het kunnen ontsleutelen.
Geweldig, maar hoe is dat handig?
Welnu, eenrichtingsversleuteling is niet ideaal voor het versleutelen van internetverbindingen, het is nogal moeilijk om te communiceren wanneer de ene partij alleen kan versleutelen en de andere alleen kan ontsleutelen. Nee, om een internetverbinding te versleutelen, moet u symmetrische privésleutelversleuteling gebruiken.
Maar hoe wissel je sleutels uit? Vooral online?
Codering met openbare sleutel.
En dat, tot in de kern gedestilleerd, is waar SSL / TLS voor staat: veilige sleuteluitwisseling.
Hier brengen we al deze concepten samen. Als u wilt dat uw communicatie met een website privé is, moet u er veilig verbinding mee maken. Als u veilig verbinding wilt maken met die website, moet u symmetrische privésleutels uitwisselen, zodat u ze kunt gebruiken om te communiceren. SSL / TLS (en PKI in het algemeen) is slechts een mooi mechanisme voor het maken en uitwisselen van die sessiesleutel.
Met SSL / TLS kunt u de server of organisatie waarmee u verbinding gaat maken, verifiëren en ervoor zorgen dat u de privésleutels die u gaat gebruiken om uw communicatie met de bedoelde partij te versleutelen, veilig uitwisselt..
Helaas hebben SSL / TLS en PKI veel terminologie en bewegende delen die mensen gemakkelijk kunnen verwarren, maar die ontkennen het feit dat wanneer je alle wiskunde en het technische jargon weghaalt, dit slechts een elegante moderne technologische oplossing is voor een tijdperk -oud probleem: sleuteluitwisseling.
Laten we nu een paar belangrijke termen bespreken
Laten we, voordat we verder gaan, nog een paar andere belangrijke termen bespreken. We hebben al HTTP, hypertext transfer protocol geïntroduceerd, dat al tientallen jaren de ruggengraat van internet is. Maar zoals we bespraken, evolueerde het internet tot iets heel anders dan toen HTTP voor het eerst werd gepubliceerd in 1991.
Er was een veiliger protocol nodig. Dus HTTPS.
HTTPS, ook wel HTTP over TLS genoemd, gebruikt codering om de gegevens die tijdens een verbinding worden uitgewisseld onleesbaar te maken voor iedereen behalve de bedoelde partij. Dit is vooral belangrijk als je kijkt naar de aard van een moderne internetverbinding.
Waar in het begin van het internet een verbinding redelijk direct was, worden verbindingen nu via tientallen apparaten geleid op weg naar hun eindbestemming. Als je ooit een praktische demonstratie hiervan wilde hebben, open je de opdrachtprompt op je besturingssysteem en voer je de opdracht ‘tracert geekflare.com’ in.
Wat u zult zien, is het pad dat uw verbinding aflegde op weg naar zijn bestemming. Tot 30 sprongen. Dat betekent dat uw gegevens door elk van die apparaten gaan voordat ze de website of applicatie bereiken waarmee u verbinding maakt. En als iemand een packetsniffer of een luisteraar op een van die apparaten heeft geïnstalleerd, kunnen ze alle verzonden gegevens stelen en in sommige gevallen zelfs de verbinding manipuleren.
Dit wordt een man-in-the-middle-aanval (MITM) genoemd.
Als je meer wilt weten over de MITM-aanval, dan bekijk deze online cursus.
Er is veel meer oppervlakte te bedekken met moderne internetverbindingen dan de overgrote meerderheid van de mensen beseft, daarom is het van cruciaal belang dat de gegevens tijdens verzending worden versleuteld. Je hebt geen idee wie er zou kunnen luisteren of hoe eenvoudig het is om te doen.
Er wordt een HTTP-verbinding gemaakt via poort 80. Voor onze doeleinden kunt u poorten beschouwen als constructies die een netwerkdienst of protocol aangeven. Een standaardwebsite die via HTTP wordt gebruikt, gebruikt poort 80. HTTPS gebruikt meestal poort 443. Wanneer een website een certificaat installeert, kan deze zijn HTTP-pagina’s omleiden naar HTTPS, en de browsers van gebruikers zullen proberen veilig verbinding te maken via poort 443, in afwachting van verificatie.
Helaas worden de termen SSL / TLS, HTTPS, PKI en codering allemaal veel rondgeslingerd, soms zelfs uitwisselbaar gebruikt, dus om elke aanhoudende verwarring op te lossen, volgt hier een korte handleiding:
- SSL – Secure Sockets Layer, het originele coderingsprotocol dat wordt gebruikt met HTTPS
- TLS – Transport Layer Security, het recentere versleutelingsprotocol dat SSL heeft vervangen
- HTTPS – De veilige versie van HTTP, gebruikt om verbindingen met websites te maken
- PKI – Public Key Infrastructure, verwijst naar het volledige vertrouwensmodel dat codering met openbare sleutels mogelijk maakt
SSL / TLS werkt samen om HTTPS-verbindingen mogelijk te maken. En PKI verwijst naar de hele zaak als je uitzoomt.
Ik snap het? Maak je geen zorgen, dat doe je.
Bouwen aan een Public Key Infrastructure
Nu we de basis hebben gelegd, gaan we uitzoomen en kijken naar de architectuur die wordt gebruikt door het vertrouwensmodel in het hart van SSL / TLS.
Wanneer u op een website aankomt, controleert het eerste wat uw browser doet de authenticiteit van het SSL / TLS-certificaat dat de site presenteert. We zullen zien wat er gebeurt nadat die authenticatie in een paar secties heeft plaatsgevonden, maar we beginnen met het bespreken van het vertrouwensmodel dat dit alles mogelijk maakt.
We beginnen dus met de vraag: hoe weet mijn computer of hij een bepaald SSL / TLS-certificaat moet vertrouwen?
Om dat te beantwoorden, moeten we PKI bespreken en de verschillende elementen die ervoor zorgen dat het werkt. We beginnen met Certificate Authorities en Root-programma’s.
Certificaatautoriteiten
Een certificeringsinstantie is een organisatie die voldoet aan een reeks vooraf vastgestelde normen in ruil voor de mogelijkheid om vertrouwde digitale certificaten uit te geven.
Er zijn tientallen CA’s, zowel gratis als commercieel, die vertrouwde certificaten kunnen afgeven.
Ze moeten allemaal voldoen aan een reeks normen waarover is gedebatteerd en wetgeving is uitgevaardigd via het CA / Browser Forum, dat fungeert als de regelgevende instantie voor de TLS-industrie. Deze normen beschrijven zaken als:
- Technische beveiligingen die aanwezig moeten zijn
- Best practices voor het uitvoeren van validatie
- Geef best practices uit
- Intrekkingsprocedures en tijdlijnen
- Vereisten voor certificaatregistratie
Deze richtlijnen zijn opgesteld door de browsers, in samenwerking met de CA’s. De browsers spelen een unieke rol in het TLS-ecosysteem.
Niemand kan overal op internet komen zonder hun webbrowser. Als zodanig zal de browser het digitale TLS-certificaat ontvangen en valideren en vervolgens sleutels uitwisselen met de server. Dus, gezien hun belangrijkste rol, hebben ze aanzienlijke invloed.
En het is belangrijk om in gedachten te houden dat browsers zijn ontworpen om zo sceptisch mogelijk te zijn. Niets vertrouwen. Dit is de beste manier om hun gebruikers veilig te houden. Dus als een browser een digitaal certificaat gaat vertrouwen – dat mogelijk kan worden misbruikt ten nadele van de gebruiker – heeft het bepaalde garanties nodig dat degene die dit certificaat heeft uitgegeven, zijn due diligence heeft gedaan.
Dit is de rol en verantwoordelijkheid van de certificaatautoriteiten. En de browsers houden zich ook niet aan fouten. Er is een letterlijk kerkhof van voormalige CA’s die in de problemen zijn geraakt met de browsers en in de wei zijn gezet.
Wanneer een certificeringsinstantie heeft aangetoond dat ze voldoet aan de basisvereisten van het CAB Forum en alle vereiste audits en beoordelingen heeft doorstaan, kan ze de verschillende basisprogramma’s verzoeken om haar basiscertificaten te laten toevoegen.
Root-programma’s
Een rootprogramma – de belangrijkste worden beheerd door Apple, Microsoft, Google en Mozilla – is het apparaat dat rootstores overziet en faciliteert (ook wel truststores genoemd), dit zijn verzamelingen Root CA-certificaten die zich op het systeem van een gebruiker bevinden. Nogmaals, deze wortels zijn ongelooflijk waardevol en ongelooflijk gevaarlijk – ze kunnen tenslotte vertrouwde digitale certificaten afgeven – dus beveiliging is de grootste zorg.
Dat is de reden waarom CA’s bijna nooit rechtstreeks uit de Root CA-certificaten zelf komen. In plaats daarvan draaien ze tussenliggende rootcertificaten op en gebruiken die om eindgebruikers- of leaf-certificaten uit te geven. Ze kunnen die wortels ook overdragen aan sub-CA’s, die certificeringsinstanties zijn die niet hun specifieke wortels hebben, maar die wel ondertekende certificaten kunnen afgeven aan hun tussenpersonen.
Laten we dit allemaal samenvoegen. Wanneer een website een TLS-certificaat wil laten afgeven, genereert het iets dat een Certificate Signing Request (CSR) wordt genoemd op de server waarop het wordt gehost. In dit verzoek zijn alle details opgenomen die de website op het certificaat wil opnemen. Zoals u in een oogopslag zult zien, kan de hoeveelheid informatie variëren van volledige bedrijfsgegevens tot een eenvoudige serveridentiteit, maar zodra de CSR is voltooid, wordt deze voor uitgifte naar de certificeringsinstantie gestuurd.
Alvorens het certificaat uit te geven, moet de certificeringsautoriteit haar door de CA / browser-forum verplichte due diligence uitvoeren en valideren dat de informatie in de CSR juist is. Zodra dat is geverifieerd, ondertekent het het certificaat met zijn privésleutel en stuurt het het terug naar de website-eigenaar voor installatie.
Certificaatketen
Nadat het TLS-certificaat is geïnstalleerd, zal elke keer dat iemand de site bezoekt die door de server wordt gehost, het certificaat aan de browser van de gebruiker worden gepresenteerd. De browser gaat kijken naar de digitale handtekening op het certificaat, die is gemaakt door de vertrouwde certificeringsinstantie, die instaat voor het feit dat alle informatie in het certificaat juist is.
Dit is waar de term certificaatketening in het spel komt.
De browser leest de digitale handtekening en schuift een schakel in de ketting omhoog. Vervolgens controleert hij de digitale handtekening op het tussenliggende certificaat waarvan de privésleutel werd gebruikt om het bladcertificaat te ondertekenen. Het zal de handtekeningen blijven volgen totdat de certificaatketen eindigt bij een van de vertrouwde roots in de root store, of totdat de chain eindigt zonder een root te bereiken, in welk geval een browserfout zal verschijnen en de verbinding zal mislukken.
Daarom kunt u uw certificaten niet zelf uitgeven en ondertekenen.
De browsers vertrouwen alleen SSL / TLS-certificaten die ze terug kunnen koppelen aan hun root-winkel (wat betekent dat ze zijn uitgegeven door een vertrouwde entiteit). Certificaatautoriteiten moeten zich houden aan specifieke normen om hun betrouwbaarheid te behouden, en zelfs dan willen de browsers ze niet vertrouwen.
Browsers hebben dergelijke garanties over zelfondertekende certificaten niet en daarom mogen ze alleen worden ingezet op interne netwerken, achter firewalls en in testomgevingen.
SSL / TLS-certificaattypen en functionaliteit
Voordat we SSL / TLS in beweging bekijken, laten we het hebben over certificaten en de verschillende iteraties die beschikbaar zijn. TLS-certificaten vergemakkelijken het TLS-protocol en helpen bij het dicteren van de voorwaarden van de gecodeerde HTTPS-verbindingen die een website maakt.
Eerder hebben we al gezegd dat u door het installeren van een TLS-certificaat uw website kunt configureren om HTTPS-verbindingen te maken via poort 443. Het fungeert ook als een soort naambadge voor de site of server waarmee u communiceert. Teruggaand naar het idee dat SSL / TLS en PKI in essentie allemaal voortreffelijke vormen van veilige sleuteluitwisseling zijn, helpt het SSL / TLS-certificaat de browser te informeren naar wie de sessiesleutel wordt verzonden – naar wie de partij aan de andere kant van de verbinding is.
En wanneer u de verschillende iteraties van SSL / TLS-certificaten opsplitst, is dat een belangrijk ding om in gedachten te houden. Certificaten variëren wat betreft functionaliteit en validatieniveau. Of anders gezegd, ze variëren op basis van:
- Hoeveel identiteiten te bevestigen
- Op welke eindpunten de identiteit wordt bevestigd
Als u deze twee vragen beantwoordt, krijgt u een vrij duidelijke indicatie van welk type certificaat u nodig heeft.
Hoeveel identiteiten naar Assert
Er zijn drie verschillende validatieniveaus beschikbaar met SSL / TLS-certificaten, en ze variëren afhankelijk van hoeveel identiteitsinformatie uw website wil bevestigen.
- Domeinvalidatie SSL-certificaten – Assert serveridentiteit
- Organization Validation SSL-certificaten – Bepaal een gedeeltelijke identiteit van de organisatie
- Uitgebreide validatie SSL-certificaten – Bewijs de volledige identiteit van de organisatie
Domain Validation SSL-certificaten zijn verreweg het populairst vanwege hun prijs en de snelheid waarmee ze kunnen worden uitgegeven. Een DV SSL / TLS-certificaat vereist een eenvoudige domeincontrolecontrole, die op verschillende manieren kan worden uitgevoerd, maar zodra dit het is, kan het certificaat worden uitgegeven. Je kunt er ook gratis enkele 30-daagse en 90-daagse versies van krijgen, wat ongetwijfeld heeft bijgedragen aan hun marktaandeel.
Het nadeel is dat DV SSL-certificaten een minimale identiteit hebben. En aangezien op bijna de helft van alle phishing-websites nu een DV SSL-certificaat is geïnstalleerd, kopen ze u niet per se veel vertrouwen in.
Organisatie Validatie SSL-certificaten zijn het oorspronkelijke type SSL / TLS-certificaat. Ze zijn ook het enige type SSL-certificaat dat een IP-adres kan beveiligen na een beslissing van het CAB Forum in 2016 om alle intranet SSL-certificaten ongeldig te maken. Organisatie-validatie vereist een licht bedrijfsonderzoek en kan doorgaans binnen een dag of twee worden afgegeven – soms sneller. OV SSL-certificaten bevestigen enige organisatorische informatie, maar een internetgebruiker moet op het hangslotpictogram klikken en ernaar zoeken. Tegenwoordig zie je veel OV SSL-certificaten ingezet op grote bedrijfs- en bedrijfsnetwerken, bijvoorbeeld voor verbindingen achter firewalls.
Omdat noch DV-, noch OV-SSL-certificaten voldoende identiteit hebben om aan de meeste browsers te voldoen, krijgen ze een neutrale behandeling.
Uitgebreide validatie SSL-certificaten zijn verreweg het meest controversieel, aangezien sommigen in de technische gemeenschap van mening zijn dat er meer moet worden gedaan om de validatie te versterken waarvan ze afhankelijk zijn. Maar EV SSL beweert maximale identiteit. Om de uitgebreide validatie te voltooien, voert de certificeringsinstantie de organisatie door een rigoureus controleproces dat in sommige gevallen meer dan een week kan duren.
Maar het voordeel valt niet te ontkennen: omdat het voldoende identiteit beweert, krijgt een website met een EV SSL-certificaat een unieke browserbehandeling, inclusief het weergeven van de naam in de adresbalk van de browser.
Er is geen andere manier om dit te bereiken, en je kunt er geen nep maken: de adresbalk van de EV is een van de krachtigste visuele indicatoren die we vandaag hebben.
Op welke eindpunten identiteit moet worden bevestigd
De andere manier waarop SSL / TLS-certificaten variëren, is wat betreft functionaliteit. Websites zijn behoorlijk geëvolueerd sinds de begindagen van internet, waarbij verschillende bedrijven sites op verschillende manieren hebben geïmplementeerd. Sommige hebben meerdere domeinen voor verschillende bedrijfsbranches; anderen gebruiken subdomeinen voor meerdere functies en webapplicaties. Sommigen gebruiken beide.
Wat de context ook is, er is een SSL / TLS-certificaat dat kan helpen dit te beveiligen.
Eén domein
De primaire website en het standaard SSL-certificaat zijn slechts één domein. De meeste moderne SSL / TLS-certificaten beveiligen zowel de WWW- als de niet-WWW-versies van dat domein, maar het is beperkt tot één domein. Jij kan vergelijk hier de SSL-certificaten.
Meerdere domeinen
Multi-domein certificaten of Unified Communication Certificates (in het geval van Microsoft Exchange- en Office Communications-servers) bestaan ook om organisaties de mogelijkheid te geven om meerdere domeinen met één enkel certificaat te versleutelen. Dit kan een aantrekkelijke optie zijn omdat het geld bespaart en het het beheer van de certificaten (verlopen / vernieuwingen) een stuk eenvoudiger maakt.
Multi-Domain- en UCC-certificaten gebruiken SAN, het veld Subject Alternative Name in de CSR, om extra domeinen aan het certificaat toe te voegen. De meeste CA’s staan maximaal 250 verschillende SAN’s toe op één enkel certificaat. En de meeste Multi-Domain certificaten worden geleverd met 2-4 gratis SAN’s, de rest is beschikbaar voor aankoop indien nodig.
Wildcard SSL-certificaten
Wildcard SSL-certificaten zijn een uiterst nuttig certificaattype omdat ze een onbeperkt aantal subdomeinen op hetzelfde niveau van de URL kunnen versleutelen. Als u bijvoorbeeld een website heeft die subdomeinen gebruikt, zoals:
- app.website.com
- portal.website.com
- user.website.com
U kunt ze allemaal coderen met hetzelfde Wildcard-certificaat door een asterisk te gebruiken in het FQDN-veld van uw CSR: * .website.com
Nu kan elk subdomein, zelfs degene die u nog niet heeft toegevoegd, worden beveiligd met dat certificaat.
Er zijn echter twee nadelen aan Wildcard-certificaten. De eerste is dat door dezelfde openbare sleutel te gebruiken op sommige eindpunten, u kwetsbaarder bent voor bepaalde exploits zoals Bleichenbacher-aanvallen.
De andere is dat er geen EV Wildcard-optie is. Vanwege het open karakter van de Wildcard-functionaliteit, kunnen de browsers dat vertrouwen niet delegeren. Als u de EV-adresbalk op uw subdomeinen wilt, moet u ze afzonderlijk versleutelen of een EV Multi-Domain-certificaat gebruiken.
Wildcard met meerdere domeinen
Een relatief nieuwe toevoeging aan het SSL / TLS-ecosysteem, de Multi-Domain Wildcard kan tot 250 verschillende domeinen versleutelen, maar het kan ook een asterisk gebruiken in de SAN-velden, waarmee je ook 250 verschillende domeinen EN al hun bijbehorende eerst kunt versleutelen -niveau subdomeinen.
Een andere use-case voor de Wildcard met meerdere domeinen is als een Wildcard met meerdere niveaus, waar het subdomeinen op meerdere niveaus van de URL kan versleutelen (een standaard Wildcard kan ze slechts op één niveau versleutelen).
Vanwege de Wildcard-functionaliteit zijn Multi-Domain Wildcards ook niet beschikbaar in EV.
SSL / TLS in beweging
Nu we alle belangrijke concepten hebben besproken die make-up SSL / TLS en PKI maken, laten we het allemaal samenvoegen en het in beweging zien.
Validatie en uitgifte
Laten we helemaal bij het begin beginnen met een website die een SSL / TLS-certificaat koopt van een CA of reseller. Na de aankoop maakt de organisatorische contactpersoon die de verwerving van certificaten afhandelt, een aanvraag voor certificaatondertekening op de server waar het certificaat zal worden geïnstalleerd (de server die de website host).
Samen met de CSR genereert de server ook een openbaar / privé-sleutelpaar en slaat de privé-sleutel lokaal op. Wanneer de CA de CSR en de openbare sleutel ontvangt, voert deze de vereiste validatiestappen uit om ervoor te zorgen dat alle informatie in het certificaat juist is. Over het algemeen houdt dit voor zakelijke authenticatiecertificaten (niet DV) in dat de registratiegegevens en openbare registers van een organisatie in overheidsdatabases worden opgezocht.
Zodra de validatie is voltooid, gebruikt de CA een van de persoonlijke sleutels van een van de uitgevende certificaten, meestal een tussenliggende root, en ondertekent het certificaat voordat het wordt teruggestuurd naar de site-eigenaar.
Nu kan de website-eigenaar het nieuw uitgegeven SSL / TLS-certificaat nemen, het op hun server installeren en de website configureren om HTTPS-verbindingen op poort 443 te maken (met 301-omleidingen om verkeer van de reeds bestaande HTTP-pagina’s naar hun nieuwe HTTPS-tegenhangers te sturen).
Verificatie en de SSL-handdruk
Nu het SSL / TLS-certificaat is geïnstalleerd en de website is geconfigureerd voor HTTPS, gaan we kijken hoe het versleutelde verbindingen met de bezoekers van de site mogelijk maakt..
Bij aankomst op de website presenteert de server het SSL / TLS-certificaat aan de browser van de gebruiker. De browser van de gebruiker voert vervolgens een reeks controles uit.
Ten eerste gaat het het certificaat verifiëren door de digitale handtekening te bekijken en de certificaatketen te volgen. Het zorgt er ook voor dat het certificaat niet is verlopen en controleert Logboeken met certificaattransparantie (CT) en lijsten met ingetrokken certificaten (CRL’s). Op voorwaarde dat de ketting teruggaat naar een van de wortels in de trust store van het systeem en dat deze geldig is, vertrouwt de browser het certificaat.
Nu is het tijd voor een handdruk.
De SSL / TLS-handshake is de reeks stappen waarbij de client (gebruiker) en de server (website) de parameters van hun beveiligde verbinding onderhandelen, symmetrische sessiesleutels genereren en uitwisselen.
Eerst beslissen ze over een coderingssuite. Een coderingssuite is de groep algoritmen en cijfers die zullen worden gebruikt voor de verbinding. Het SSL / TLS-certificaat biedt een lijst met coderingssuites die de server ondersteunt. Over het algemeen bevat een coderingssuite een coderingsalgoritme voor openbare sleutels, een algoritme voor het genereren van sleutels, een algoritme voor berichtverificatie en een symmetrisch of bulkcoderingsalgoritme – hoewel dat is verfijnd in TLS 1.3.
Nadat de klant de lijst met ondersteunde cijfers heeft ontvangen, kiest hij een aangename en communiceert deze met de server. Van daaruit genereert de client een symmetrische sessiesleutel, versleutelt deze met de openbare sleutel en stuurt deze vervolgens naar de server, die de persoonlijke sleutel bezit die nodig is om de sessiesleutel te decoderen.
Zodra beide partijen een kopie van de sessiesleutel hebben, kan de communicatie beginnen.
En dat is SSL / TLS.
U kunt zien hoe alle concepten die we eerder hebben doorgemaakt met elkaar in wisselwerking staan om een geavanceerd maar elegant systeem te creëren voor het beveiligen van internetverbindingen. We gebruiken cryptografie met openbare sleutels om de sessiesleutels veilig uit te wisselen waarmee we zullen communiceren. De certificaten die de identiteit van de server of de organisatie bevestigen, kunnen worden vertrouwd vanwege de infrastructuur die we hebben tussen de verschillende CA’s, browsers en rootprogramma’s.
En communicatie vindt plaats als gevolg van symmetrische versleuteling van privésleutels die afstamt van de klassieke cryptosystemen uit de oudheid.
Er zijn veel bewegende delen, maar als je langzamer gaat en ze allemaal afzonderlijk begrijpt, is het een stuk gemakkelijker om te zien hoe het allemaal samenwerkt.
Voordat u vertrekt, eindigen we met een paar SSL / TLS-gerelateerde bewegingen die u na installatie / configuratie kunt maken om het meeste uit uw investering te halen.
Na SSL / TLS – Haal het maximale uit uw implementatie
Het simpelweg hebben van een certificaat en het correct configureren van uw website betekent niet dat uw website veilig is. TLS is slechts een onderdeel van een bredere, holistische cyberdefensiestrategie. Maar toch een belangrijk onderdeel. Laten we een paar dingen bespreken die u kunt doen om ervoor te zorgen dat u het meeste uit de implementatie haalt.
Schakel serverondersteuning uit voor oude protocollen
Terugkomend op het gesprek dat we eerder hadden over Cipher Suites, bepaalt een deel van het configureren van uw server welke coderingssuites en SSL / TLS-versies moeten worden ondersteund. Het is absoluut noodzakelijk dat u ondersteuning voor oudere SSL / TLS-versies en specifieke algoritmen uitschakelt om kwetsbaarheid voor verschillende bekende exploits te voorkomen.
SSL 2.0 en SSL 3.0 zijn beide meer dan 20 jaar oud. Best practice was om de ondersteuning voor hen jaren geleden stop te zetten, maar tot op de dag van vandaag staat ongeveer 7% van de Alexa top 100.000 hen nog toe. Dit is gevaarlijk omdat het je blootstelt aan SSL-stripping en downgrade-aanvallen zoals POODLE.
TLS 1.0 en TLS 1.1 zijn ook op geleende tijd.
De grote technologiebedrijven, Apple, Microsoft, Google en Mozilla, hebben dit najaar gezamenlijk aangekondigd dat ze de ondersteuning voor TLS 1.0 en 1.1 begin 2020 zullen beëindigen.
De protocolversies zijn vatbaar voor kwetsbaarheden zoals de POODLE, FREAK, BEAST en CRIME (dit zijn allemaal acroniemen). TLS 1.2 bestaat al tien jaar en zou de standaard moeten zijn. TLS 1.3 werd afgelopen zomer afgerond en de adoptie is sindsdien in een gestaag tempo gegaan.
Bovendien zijn er specifieke algoritmen die ook niet mogen worden gebruikt. DES kan bijvoorbeeld binnen enkele uren worden verbroken. RC4 is kwetsbaarder dan ooit werd aangenomen en is al verboden door de gegevensbeveiligingsnormen van de Payment Card Industry. En tot slot, gezien het nieuws van recente exploits, is het niet raadzaam om RSA meer te gebruiken voor sleuteluitwisseling.
Voorgestelde algoritmen / cijfers:
- Sleuteluitwisseling: elliptische curve Diffie-Helman (ECDH)
- Verificatie: Elliptic Curve Digital Signature Algorithm (ECDSA)
- Symmetrische / bulkversleuteling: AES 256 in Galois-tellermodus (AES256-GCM)
- MAC-algoritme: SHA-2 (SHA384)
Always-on SSL
In het verleden migreerden websites soms alleen de webpagina’s die informatie verzamelden naar HTTPS, terwijl ze de rest van de site via HTTP bedienden. Dit is een slechte gewoonte.
Naast het feit dat Google deze pagina’s als ‘Niet veilig’ markeert, stelt u mogelijk ook de bezoekers van uw site bloot aan risico’s door hun browsers heen en weer te laten springen tussen gecodeerde pagina’s en HTTP-pagina’s.
U zou uw hele website voor HTTPS moeten configureren. Dit wordt Always-on SSL genoemd. Het is tenslotte niet alsof u per pagina betaalt, uw SSL / TLS-certificaat kan uw hele site versleutelen. Dus maak het zo.
Stel een CAA-record (Certificate Authority Authorization) in
Een van de belangrijkste risico’s van digitale certificaten is in het algemeen een verkeerde uitgifte. Als een andere partij dan u een SSL / TLS-certificaat voor UW website krijgt, kunnen zij zich effectief voor u voordoen en allerlei problemen veroorzaken.
CAA-records helpen dit risico te beperken door te beperken wat certificaatautoriteiten digitale certificaten voor uw website kunnen afgeven. Certificaatautoriteiten zijn verplicht door het CA / Browser Forum om CAA-records te controleren voordat een certificaat wordt afgegeven. Als de CA niet de autorisatie heeft om voor die site uit te geven, kan dat niet. Als u dit wel doet, wordt dit beschouwd als een foutieve uitgifte en krijgt u de woede van de browsergemeenschap.
Het toevoegen van een CAA-record is relatief eenvoudig, het is een eenvoudig DNS-record dat kan worden toegevoegd via de interface van de meeste hostingplatforms. U kunt de CA’s beperken die voor uw domein kunnen worden uitgegeven, en of er ook Wildcard-certificaten voor kunnen worden uitgegeven.
Voeg uw website toe aan de HSTS-preloadlijst
HTTP Strict Transport Security, of HSTS, is een HTTP-header die ervoor zorgt dat browsers alleen HTTPS-verbindingen maken met een bepaalde site. Op deze manier zullen de webgebruikers, zelfs als ze naar de HTTP-versie van de pagina proberen te gaan, alleen de HTTPS-versie bezoeken. Dat is belangrijk omdat het het venster sluit voor verschillende bekende exploits, zoals downgrade-aanvallen en het kapen van cookies.
Helaas blijft er een kleine aanvalsvector over bij HSTS, daarom zou u uw website aan de preloadlijst moeten toevoegen. Wanneer een bezoeker op uw website aankomt, downloadt zijn browser doorgaans de HTTP-header en houdt deze vervolgens aan, zolang het beleid is ingesteld om te blijven bestaan. Maar bij dat allereerste bezoek, voordat de koptekst is ontvangen, is er nog een kleine opening voor een aanvaller.
De HSTS-preload-lijst met records wordt beheerd door Google en een variatie daarop wordt gebruikt door alle grote browsers. Die browsers weten alleen dat ze via HTTPS verbinding kunnen maken met elke website die op de lijst staat, zelfs als ze daar nog nooit eerder zijn bezocht. Het kan een week of twee duren voordat uw site op de lijst wordt weergegeven omdat updates voor de lijst worden uitgezet in combinatie met de release-schema’s van de browsers.
Veelgestelde vragen over SSL / TLS
Wat is een X.509-certificaat?
X.509 verwijst naar het type digitaal certificaat dat wordt gebruikt met SSL / TLS en andere typen PKI. X.509 is een coderingsstandaard voor openbare sleutels. Af en toe ziet u dat bedrijven het X.509-certificaat gebruiken in plaats van ‘digitaal certificaat’ of ‘PKI-certificaat’.
Waarom verlopen SSL / TLS-certificaten??
Hiervoor zijn twee redenen.
De eerste is dat internet voortdurend verandert, websites komen en websites gaan. En gezien hoe gevoelig de browsers zijn om deze certificaten te vertrouwen, willen ze in de eerste plaats weten dat de websites die de certificaten presenteren regelmatig worden gevalideerd. Het verschilt niet veel van hoe u af en toe moet inchecken om de informatie op uw rijbewijs bij te werken.
De andere reden is technischer. Updates en technische wijzigingen zijn moeilijker te verspreiden wanneer certificaten niet 3-5 jaar verlopen. Als certificaten echter elke 24 maanden vervallen, is elk certificaat het langst verouderd: twee jaar. In 2017 is de maximale geldigheid verlaagd van drie naar twee jaar. Het wordt waarschijnlijk binnenkort ingekort tot 12 maanden.
Hoe verlengt u een SSL / TLS-certificaat?
Verlenging kan een beetje een verkeerde benaming zijn omdat u het oude certificaat vervangt door een nieuw uitgegeven. Door dit regelmatig te doen, blijft u up-to-date met nieuwe ontwikkelingen op het gebied van coderingstechnologie en blijft uw validatiegegevens up-to-date. CA’s kunnen de validatie-informatie die aanvankelijk was verstrekt alleen hergebruiken zolang de basiseisen hen ertoe dwingen deze opnieuw te valideren.
Wanneer u verlengt, kunt u ofwel hetzelfde certificaattype behouden dat u eerder had, of u kunt iets nieuws gebruiken, u kunt zelfs CA’s wijzigen. Het belangrijkste is hoeveel tijd je nog hebt op het verlopen certificaat – je kunt maximaal drie maanden meenemen. Zolang u verlengt voordat het certificaat verloopt, kunt u de resterende tijd overdragen en alle validatiegegevens hergebruiken die niet zijn verlopen sinds uw laatste validatie. Als je het laat verlopen, begin je helemaal opnieuw.
Wat is HTTPS-inspectie?
Veel grotere bedrijven met grotere netwerken willen graag zicht hebben op hun verkeer. In dat opzicht is HTTPS een tweesnijdend zwaard. Het beschermt de privacy van mensen, maar het kan ook helpen om cybercriminelen te verbergen. Veel organisaties decoderen hun HTTPS-verkeer op een edge-apparaat of een middlebox en sturen het vervolgens in platte tekst achter hun firewall of versleutelen het en sturen het onderweg. Wanneer u het verkeer niet opnieuw codeert, wordt dit SSL-beëindiging genoemd. Wanneer u opnieuw codeert, wordt dat SSL-bridging genoemd.
Wat is SSL-offloading?
SSL-offloading is een andere bedrijfspraktijk. Op grote schaal kan het uitvoeren van duizenden handdrukken en vervolgens het versleutelen en ontsleutelen van al die gegevens een belasting vormen voor de bronnen van een netwerk. Veel grotere netwerken zullen de SSL-functies dus overzetten naar een ander apparaat, zodat de applicatieserver zich kan concentreren op zijn kerntaken. Dit wordt ook wel load balancing genoemd.
Waarom stuurde mijn CA mij een tussenliggend certificaat?
Onthoud eerder toen we rootprogramma’s bespraken?
Very OS heeft een root store die het gebruikt om PKI-vertrouwensoordelen te maken. Maar CA’s geven geen eindgebruikerscertificaten uit die wortels uit angst voor wat er zou gebeuren als iemand ooit zou moeten worden ingetrokken. In plaats daarvan draaien ze tussenwortels op en geven die af. Het probleem is dat die tussenliggende wortels niet in de trust store van een systeem zitten.
Als de website dus niet het tussenliggende certificaat samen met het leaf SSL / TLS-certificaat presenteert, kunnen veel browsers de certificaatketen niet voltooien en geven ze een waarschuwing. Sommige browsers cachen tussenliggende certificaten, maar het wordt nog steeds als een goede gewoonte beschouwd om tussenproducten samen met uw leaf-certificaat te installeren.
Welke documentatie heb ik nodig voor een Extended Validation SSL-certificaat?
In de meeste gevallen zal de certificeringsinstantie die de uitgebreide validatie uitvoert, eerst proberen toegang te krijgen tot de informatie via openbaar beschikbare bronnen van de “overheidsinstantie”.
Op sommige locaties is dit echter mogelijk niet mogelijk. Er zijn echter een paar dingen die kunnen helpen bij het versnellen van de validatie. Hoewel het aantal validatiecontroles waaraan een Professional Opinion Letter kan voldoen, onlangs is verminderd, kan een advocaat of accountant met een goed teken een aanzienlijke bijdrage leveren.
Daarnaast kunt u een door de overheid uitgegeven bedrijfsreferentie of “Proof of Right” -document verstrekken dat uw organisatie het recht geeft zaken te doen onder de vermelde naam. Enkele voorbeelden van deze documenten zijn:
- Statuten
- Certificaten van vorming
- Bedrijfs- / leveranciers- / handelaarslicenties
- Handvestdocumenten
- Partnerschapsovereenkomsten
- Registratie van handel of veronderstelde naam
- Registro Mercantil
Afsluitend
Ik hoop dat dit je een idee geeft over SSL / TLS. Als je meer wilt weten, dan raad ik je aan deze online cursus volgen.
Dit bericht is bijgedragen door Patrick Nohe, redacteur van Uitgehakt door de SSL Store, een blog over nieuws en trends over cyberbeveiliging.
