WORKING HOURS: Mon. – Fri. 7.30 – 17.30        |  Mauritslaan 77A, 6161HS Geleen        |  CONTACT: +31 (0)43 365 92 44
  • nl
  • en

SSL certificaten, veilig of onveilig?

De laatste tijd, vooral sinds het DigiNotar incident, is er veel te doen omtrent de veiligheid van SSL certificaten.  In dit artikel zal ik proberen jullie duidelijk te maken wat en hoe SSL certificaten beveiligen, hoe de veiligheid van SSL certificaten geborgd word, waar je op moet letten en welke alternatieven/aanvullingen er in ontwikkeling zijn.

SSL beveiliging

In de basis wordt informatie die je via internet verstuurd via verschillende netwerken (‘hops’) gerouteerd naar de eindbestemming. Op iedere hop kan iemand dan ook jouw informatie lezen en zelfs aanpassen. Voor veel alledaagse internet activiteiten is dit niet erg, echter als het om persoonlijke gegevens, banktransacties, wachtwoorden, etc. gaat is dit uiteraard niet acceptabel. Het antwoord daarop is encryptie. Netscape heeft daarvoor Secure Socket Layer (SSL) ontwikkeld. SSL maakt het mogelijk om tussen twee systemen een veilige, gecodeerde, verbinding op te zetten, ongeacht het aantal ‘hops’ tussen beide machines.  SSL of TLS (Transport Layer Security, de  door de IETF (Internet Engineering Task Force) vastgelegde standaard op basis van de Netscape SSL 3.0 specificatie werken op het transport niveau (TCP/IP), maar onder HTTP, SMTP, POP3, etc. Een SSL/TLS beveiligde verbinding is, ten opzichte van zijn niet-beveiligde broer, meestal te herkennen aan de ‘s’  achter de protocol aanduiding (http->https, smtp->smtps, pop3->pop3s).

SSL werkt met asymmetrische cryptografie. Hierbij is er een private-key die niet in handen van derden mag vallen en een public-key die iedereen mag weten. Deze sleutels worden via PKI ondertekend door een zogenaamde CA (Certificate Authority). Een CA is verantwoordelijk voor een aantal controles, afhankelijk van het certificaat-type, en heeft een grote verantwoordelijkheid omtrent het beheren en beveiligen van hun private sleutel en lijsten van uitgegeven (en ingetrokken) certificaten. Zonder die controles van een CA kun je bij een SSL verbinding alleen zeggen dat de verbinding beveiligd is, maar weet je niet met wie je die verbinding hebt. Daarover straks meer.

Omdat SSL boven op het IP protocol, maar onder protocollen als HTTP werkt, word er bij de initiële verbinding met een server eerst een uitwisseling/onderhandeling van de ssl beveiliging gedaan en daarna pas de http-request doorgestuurd naar de server. Tijdens de onderhandeling is dus nog niet bekend welke website/servernaam iemand probeert aan te spreken. Dit is vooral bij gedeelde webhosting een uitdaging. Gelukkig is er geruime tijd geleden al een uitbreiding op TLS gedefinieerd die dit oplost. Deze uitbreiding (SNI, Server Name Indication) is al enkele jaren in veel clients (zoals Windows  XP of hoger) en servers opgenomen. Met Windows 8 zal Microsoft ook eindelijk een IIS versie op de markt brengen die SNI zal ondersteunen.

Typen SSL certificaten

SSL certificaten zijn er in verschillende vormen voor verschillende toepassingen. De meest bekende zijn bedoeld voor het beveiligen van internet diensten zoals websites. Daarnaast zijn er onder andere ook persoonlijke certificaten (voor het ondertekenen van e-mail) en zogenoemde CodeSigning certificaten (voor het ondertekenen van software). Ik wil hieronder even ingaan op de verschillende beveiligingsniveaus en dus certificaat typen voor webdiensten.

  •  Domein Validatie (DV)

Domeinnaam gevalideerde SSL certificaten zijn certificaten welke zeer snel kunnen worden uitgegeven, meestal binnen enkele minuten. Iedereen kan een aanvraag indienen voor een SSL certificaat.

Certificaat aanvragen dienen echter te worden goedgekeurd door iemand die controle heeft over de domeinnaam. Doorgaans is dit de webmaster of de persoon die de domeinnaam heeft geregistreerd. Men heeft hier meestal de keuze uit een 10-tal vooraf gedefinieerde mailadressen (info@, ssl@, administrator@) en uit het mailadres welke in de whois-gegevens van de domeinnaam te vinden is.

  • Organisatie validatie (OV)

Bij deze validatie worden onder andere de gegevens van de organisatie gecontroleerd door middel van externe bronnen en wordt de contactpersoon van de organisatie gebeld.

Het telefoonnummer dat gebruikt wordt voor dit gesprek moet zijn verkregen via een erkende instantie. Daarna zullen de bedrijfsgegevens in het SSL certificaat opgenomen worden. Dit geeft de klant extra vertrouwen omdat men kan zien dat het bedrijf deze validatie met goed gevolg heeft doorlopen.

OV certificaten zitten in rang boven ‘domein gevalideerde’ certificaten, en onder ‘uitgebreide gevalideerde’ certificaten.

Bij OV certificaten is het belangrijk dat een contactpersoon de CA te woord kan staan. Als dit direct lukt duurt de procedure tussen aanvraag en uitgifte van het certificaat doorgaans slechts enkele dagen.

  • Uitgebreide validatie (EV)

Eén van de  belangrijkste eigenschappen van een Extended Validation SSL certificaat is dat deze de adresbalk van bijvoorbeeld Internet Explorer 7 en hoger, groen laat kleuren. Dit houdt in dat de identiteit van de eigenaar van de website, welke in het SSL certificaat vermeldt staat, is gevalideerd door middel van de zeer strenge Extended Validation richtlijnen.

SSL EV browser adres balk

De adresbalk van bijvoorbeeld de Internet Explorer 7 en 8 browser laat bij een geldig Extended Validation SSL Certificaat tevens de naam van de gevalideerde partij in beeld zien. Ook toont het de Certificaat Autoriteit (CA)  welke de validatie heeft verstrekt. Bezoekers zullen door deze duidelijke identificatie eerder geneigd zijn om de site als vertrouwd of veilig te bestempelen.

Voor de uitgifte van een EV certificaat zal er vanuit de CA contact gezocht worden met een tekeningsbevoegd persoon zoals geregistreerd in openbare registers (in Nederland de Kamer van Koophandel).

Omdat de validatie procedure een stuk uitgebreider is duurt het proces van aanvraag tot en met uitgifte in de praktijk vaak 5 tot 10 werkdagen.

CA’s, een zaak van vertrouwen!

In de PKI spelen CA’s zoals de bekende namen GlobalSign, Thawte, Symantec (voorheen Verisign) en Geotrust een belangrijke en verantwoordingsvolle rol. Zij voeren op basis van het type certificaat de juiste controles uit en geven uiteindelijk het certificaat uit.

Een CA heeft afspraken met partijen die client software ontwikkelen zoals Microsoft, Mozilla (Firefox), Google (Chrome), Apple en zorgt ervoor dat deze partijen de door hun verstrekte certificaten kunnen herkennen en vertrouwen. Dit gaat via CA-root certificaten die meegeleverd worden in de software.  Wereldwijd zijn rond de 60 algemeen geaccepteerde CA’s. Een nieuwe CA beginnen is lastig omdat bijvoorbeeld Microsoft geen update meer voor Windows 2000 uit zal brengen waarmee het CA en de daardoor ondertekende certificaten door Windows 2000 niet meer herkend zouden worden. Dit is vooral in de oudere mobiele apparaten een uitdaging, daar werden zelden updates voor uitgebracht. Veel, goedkope, relatief jonge  CA’s werken dan ook niet goed op dergelijke apparaten of maken afspraken met bestaande, oudere, CA’s.

Als een CA gehackt wordt, of fouten maakt in zijn validatie procedures, zijn er 2 mogelijke situaties die kunnen ontstaan:

  • Het CA kan aantonen/benoemen welke certificaten illegaal ondertekend zijn en zet deze op een aparte lijst waardoor clients deze toch afkeuren. (Dit gebeurt overigens ook als je zelf bij het CA aangeeft dat je de private key kwijt geraakt bent). Andere certificaten van hetzelfde CA werken dan nog goed.
  • Het CA kan niet aantonen dat er geen andere, onbekende, certificaten ondertekend zijn met hun key. Dit is een erg heftige situatie, zoals tijdens de zomer van 2011 bij DigiNotar is gebeurd, en betekent meestal binnen enkele uren of dagen het volledig schrappen van de CA in clients. Alle door het CA verstrekte certificaten verliezen dan hun geldigheid.

De laatste situatie is erg heftig en betekend waarschijnlijk ook een zo groot vertrouwensverlies voor het CA dat zij hun deuren kunnen sluiten.

SSL CA alternatieven

Omdat er in 2011 diverse voorvallen zijn geweest bij een aantal CA’s zijn er verschillende initiatieven ontstaan die een alternatief willen bieden voor de CA’s in een PKI. De 2 belangrijkste zal ik hier behandelen:

  • DANE (DNS-based Authentication of Named Entities)

DANE gaat er vanuit dat DNSSEC geïmplementeerd is en de inhoud van de DNS dus te vertrouwen is. Door controle getallen van gebruikte publieke sleutels te publiceren in de DNS. CA’s zijn dan overbodig, zeggen de ontwikkelaars van DANE.

Vanuit verschillende TLD’s (Top-Level-Domain’s zoals SIDN van .NL) is hier echter al negatief op gereageerd. De meeste TLD’s doen namelijk geen controle op de eigenaar van een domein. De groene balk, zoals bekend van EV-SSL, met daarin de NAW gegevens van de eigenaar van de website die je bezoekt is dan dus niet te realiseren. In combinatie met IDN (Internationalized Domain Names) kan dit erg gevaarlijk zijn.

DANE kan wel goed werken tegen man-in-the-middle aanvallen.

  • Convergence

Convergence is een systeem dat werkt met zogenoemde notaries. Notaries zijn servers/diensten die zelf ook verbinding leggen met de internet dienst en hashes van het certificaat dat zij aantreffen opslaan. Je eigen client kan dan bij één of (bij voorkeur) meerdere notaries controleren of zij hetzelfde certificaat zien. Zo wordt dus ook een man-in-the-middle aanval snel herkend. Binnen Convergence blijft de CA een (optionele) rol spelen voor de verificatie van de certificaat eigenaar.

In beide PKI uitbreidingen/alternatieven gaat het uiteindelijke ook weer om een derde (DNS of notaries) die je moet vertrouwen.

Uiteindelijke gaat het dus ook in de SSL wereld puur om vertrouwen dat jij en je klanten/gebruikers in een of meerdere derden partijen hebben. Net zoals je ook in de fysieke wereld mensen vertrouwd op basis van een controle die anderen voor jou gedaan hebben.

Bron vermelding: