Uitgelegd: SSL-beveiligde pagina’s ophalen

Onlangs wonnen Whitfield Diffie en Martin E. Hellman de Turing Award voor hun bijdrage aan cryptografie. Het winnen van deze nobelprijs voor de informatica is een mooie aanleiding om dieper in te gaan op SSL. Om een totaalbeeld te krijgen, nemen we ook de omliggende protocollen mee. Voor de duidelijkheid, wij regelen dit allemaal voor je. Ben je echter iemand die interesse heeft in de technische diepgang, lees dan vooral door!

UPDATE
Sinds 11 april 2017 hebben alle domeinnamen, subdomeinen, aliassen en pointers bij Antagonist gratis SSL en HTTP/2 gekregen. Dit geldt voor iedere klant, ongeacht hun webhostingpakket, inclusief Resellers. Lees hier meer!

SSL vs. TLS?

Om te beginnen is het goed om te weten dat we tegenwoordig eigenlijk allemaal ‘TLS’ (Transport Layer Security) gebruiken, maar de naam ‘SSL’ (Secure Sockets Layer) is blijven hangen. We ondersteunen al enkele maanden enkel TLS op onze hosting servers, omdat SSL sinds POODLE bewezen onveilig is. In de rest van het artikel zal ik dus ook spreken over TLS.

SSL en TLS uitgelegd: OSI model

Als een client, zoals een webbrowser, een met TLS beveiligde pagina wil ophalen, dan worden een aantal stappen doorlopen. Het internet is volgens het OSI-model in zeven lagen op te delen. We gaan niet alle lagen doorlopen, maar beperken ons tot de Host-lagen. Hoewel de Media-lagen zeer boeiend zijn, is dat een verhaal op zich.

Transportlaag

De eerste laag waar we naar kijken, is de transportlaag met als belangrijkste protocollen ‘TCP‘ (Transmission Control Protocol) en ‘UDP‘ (User Datagram Protocol). Het grote verschil tussen de twee is dat TCP een verbinding is en daarmee garanties geeft dat pakketten altijd onaangepast in de juiste volgorde binnenkomen. Hiervoor worden verloren of corrupte pakketten opnieuw verzonden.

UDP doet daar niet aan. Het stuurt een pakket zonder enige garantie of het aankomt en zo ja, in wat voor manier. Hoewel een onbetrouwbaar netwerkprotocol onhandig klinkt, wordt het bijvoorbeeld veel gebruikt voor audio- en videoconferencing waar je liever hebt dat een pakketje verloren gaat dan dat je moet wachten tot het opnieuw verzonden is en daarmee een vertraging opbouwt.

Er zal eerst een DNS-lookup plaatsvinden, omdat een TCP-verbinding altijd via een IP-adres werkt en de meeste mensen met namen werken. Dat gebeurt voornamelijk via UDP, maar kan ook over TCP werken. Voor het begrip is het voldoende om te weten dat een naam als www.antagonist.nl wordt omgezet in het IP-adres 195.211.73.208. Een completere uitleg vind je in dit blog waar mijn collega Bart de werking van DNS toelicht.

SSL en TLS uitgelegd: TCP handshake

Met het IP-adres kunnen we beginnen de TCP-verbinding op te zetten. Om te beginnen stuurt de client een SYN-pakket waarop de server reageert met een SYN-ACK-pakket. Met een ACK-bericht van de client naar de server hebben we een TCP-verbinding.

We maken nog geen onderscheid tussen beveiligde en onbeveiligde verbindingen omdat dat in een hogere laag van het OSI-model zit. De Sessielaag regelt het besturingssysteem voor ons en slaan we over.

Presentatielaag

Op laag 6 in het OSI-model vinden we de presentatielaag. Hier bevindt zich TLS en is de moeilijkste. Een TLS-handshake begint met eens worden over een encryption key (sleutel) en een cipher (cijfer). We laten client-certificaten buiten beschouwing en in het voorbeeld heeft alleen de server een certificaat.

SSL en TLS uitgelegd: handshake

De client begint met een ClientHello-bericht waarin staat wat de hoogst ondersteunde TLS-versie is, een willekeurig getal, een lijst van ondersteunde cipher suites (hoe de client en server veilig kunnen communiceren) en ondersteunde compressiemethoden. Ook kan de client een sessie ID meegeven om een vorige sessie te hervatten.

De server kan keuzes maken, omdat de server weet wat hij ondersteunt. Deze worden in een ServerHello-bericht naar de client gestuurd. Dit vermeldt de gekozen protocolversie, cipher suite en compressiemethode. Ook staat er weer een willekeurig getal in en kan er een sessie ID in staan om een vorige sessie te hervatten.

Verder wordt een Certificate-bericht gestuurd en afhankelijk van de gekozen cipher suite een ServerKeyExchange-bericht. Om aan te geven dat de server klaar is, wordt ook nog een ServerHelloDone-bericht gestuurd. De client antwoordt met een ClientKeyExchange-bericht waar we later dieper op in gaan.

Nu de onderhandeling is voltooid, stuurt de client een ChangeCipherSpec-bericht waarmee wordt aangegeven dat vanaf nu alles veilig verstuurd moet worden. De client bevestigt dit met een Finished-bericht waarin verificatie staat van de vorige berichten zodat de server weet dat er niemand tussen zit.

De server bevestigt dit met een eigen ChangeCipherSpec-bericht en ook een Finished-bericht met verificatie van de vorige berichten. Daarmee is de handshake voltooid en kan de Applicatielaag verder. Wij gaan eerst nog wat verder inzoomen op de ClientKeyExchange.

Key exchange

Het is belangrijk om te realiseren dat de hele handshake onversleuteld plaatsvindt en dat iedereen het kan meelezen. Hoe krijg je dan toch een veilige verbinding tot stand? Dat hebben Diffie en Hellman in 1976 uitgevonden. De video-uitleg van Khan Academy is een aanrader.

Stel dat Alice en Bob nog nooit contact hebben gehad, maar wel veilig willen communiceren. Hoe kunnen ze voorkomen dat Eve ze kan afluisteren? De truc is gebaseerd op een one-way function. Een methode die gemakkelijk is te berekenen, maar moeilijk  is terug te draaien. Het is bijvoorbeeld gemakkelijk om geel en blauw te mengen, maar vanuit groen is het moeilijk af te leiden dat geel en blauw zijn gebruikt. Hoe kunnen Alice en Bob dan het eens worden over een kleur zonder dat Eve het ook weet?

SSL en TLS uitgelegd: DH private colors

Eerst spreken Alice en Bob een gezamenlijke kleur af, bijvoorbeeld geel. Ook kiezen Alice en Bob ieder een geheime kleur. Het is belangrijk dat Alice haar kleur voor zich houdt en met niemand deelt. Hetzelfde geldt voor Bob met zijn kleur. Beiden mengen ze de gezamenlijke kleur met hun eigen geheime kleur. Vervolgens sturen ze het resulterende mengsel naar de ander.

SSL en TLS uitgelegd: DF shared colors

Nu kunnen ze aan het mengsel van de ander hun eigen geheime kleur toevoegen. Beiden komen op dezelfde kleur uit en dus hebben Alice en Bob een gezamenlijk geheim. Merk op dat Eve alleen mengsels heeft gezien en niet weet welke geheime kleuren Alice en Bob hebben gekozen. De kracht van Diffie-Hellman zit er dus in dat twee volstrekt vreemden met een afluisterende partij nog steeds een geheim kunnen opbouwen terwijl iemand meekijkt.

Computers werken echter niet met kleuren, maar met getallen. Een meer wiskundig voorbeeld is dus om 19 en 31 te vermenigvuldigen, wat gemakkelijk is. Als iemand je vraagt welke twee getallen samen 589 vormen dan is dat moeilijk.

Uiteraard zijn de algoritmes, vaste stappenplannen, complexer en werken met veel grotere getallen, maar het principe van de one-way function blijft. In het geval van Diffie-Hellman is dat het Discrete Log Problem. Dit kan over een cyclische groep of een Elliptic Curve. Een compleet overzicht van key exchanges is uiteraard op Wikipedia te vinden. De uitleg door vooraanstaande wiskundigen DJB en Tanja Lange over EC is een aanrader.

Ciphers

Een cipher is een algoritme om ver- en ontsleuteling te doen. Een voorbeeld is de Caesar-cipher. Het illustreert de principes goed, omdat het een zeer simpele versleuteling is. De Caesarcijfer werkt op basis van roteren. Bij een rotatie van 3 verschuif je alle letters 3 posities in het alfabet. Daarmee wordt een ‘b’ dus versleuteld ‘e’. Om terug te gaan, verschuif je de letters weer 3 naar links.

SSL en TLS uitgelegd: caesar cipher

De Caesar-cipher heeft heel gemakkelijke ver- en ontsleutelfuncties, maar werkelijke cryptografische ciphers zijn veel complexer. Wikipedia heeft een Lijst van TLS ciphers. De afgelopen jaren zijn er vele kwetsbaarheden gevonden en is het een trend om die kwetsbaarheden namen als BEAST en POODLE te geven.

Applicatielaag

Op laag 7 is vinden we de applicatielaag. Dit zijn protocollen als DNSIMAPHTTPFTP en SMTP.

Laten we een hele simpele HTTP-interactie bekijken. We willen de eerste pagina ophalen van www.antagonist.nl. Linux- en Mac-gebruikers kunnen op de command line gemakkelijk met het onderstaande een onbeveiligde respectievelijk beveiligde verbinding opzetten om hetzelfde te doen: telnet www.antagonist.nl 80 of openssl s_client -connect www.antagonist.nl:443 -servername www.antagonist.nl.

Nu gaan we ons verzoek sturen:

GET / HTTP/1.1
Host: www.antagonist.nl

Dit wordt afgesloten met een lege regel. Op poort 80 (HTTP) krijgen we dan het volgende antwoord:

HTTP/1.1 301 Moved Permanently
Server: nginx/1.8.0
Date: Thu, 10 Mar 2016 13:38:01 GMT
Content-Type: text/html
Content-Length: 184
Connection: keep-alive
Location: https://www.antagonist.nl/

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.8.0</center>
</body>
</html>

De webserver reageert met een HTTP 301 response en vertelt ons via de Location header dat de pagina eigenlijk op https://www.antagonist.nl/ is te vinden. Daarnaast zijn er headers die de server en inhoud beschrijven. De inhoud is 184 bytes van het type text/html. Na de headers zien we deze simpele HTML-pagina ook staan.

Op poort 443 (HTTPS) krijgen we op hetzelfde verzoek een vergelijkbare reactie:

HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Thu, 10 Mar 2016 13:58:51 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.3.28

Hier vertelt de webserver dat het in orde  is. De HTML-inhoud is weggelaten maar volgt deze headers op. Alle verschillende status codes zijn wederom op Wikipedia te vinden.

Naar A+

SSL en TLS uitgelegd: A+De Qualys SSL Server Test kan je helpen te controleren of alles goed is ingesteld. Voor klanten die SSL-certificaten bij ons afnemen, zorgen wij voor een Qualys A-rating. Een A+ krijg je door HSTS in te stellen. Daarmee vertel je clients dat ze een bepaalde tijd mogen aannemen gaan dat de website via HTTPS gebruikt moet worden.

Als de website niet langer via HTTPS wordt aangeboden, dan kan het dus nog lang duren voordat terugkerende bezoekers weer kunnen verbinden. Het voordeel is dat bezoekers niet eerst via HTTP hoeven te verbinden en het dus sneller is. Daarom willen wij die keuze dus niet maken voor onze klanten, maar het is eenvoudig via .htaccess in te stellen:

# 15768000 seconden = 6 maanden
Header set Strict-Transport-Security "max-age=15768000" env=HTTPS

Certificaten en hun verificatie

Afsluitend is het ook goed om nog even de certificaten en hun verificatieprocedures te noemen. Er zijn drie niveaus: domeinvalidatie (DV), organisatievalidatie (OV) en uitgebreide validatie (EV). De verificatie wordt gedaan door een Certificate Authority (CA) zoals Comodo. Ze zijn oplopend, wat wil zeggen dat organisatieverificatie ook domeinverificatie omvat en uitgebreide verificatie omvat weer organisatieverificatie.

Domeinvalidatie vindt typisch plaats via e-mail, DNS of HTTP. Bij e-mail wordt een mail gestuurd naar een e-mailadres van bijvoorbeeld de domeinhouder of hostmaster@domein. Voor onze klanten hebben we dit waar mogelijk geautomatiseerd, maar er zijn gevallen waar ze zelf moeten reageren op de mail van Comodo.

Bij DNS-verificatie moet een DNS-record aanwezig zijn en bij HTTP-verificatie moet een bestand met een zekere inhoud op te halen zijn via HTTP. Het ACME-protocol is een voorstel om deze procedure te standaardiseren, maar is nog niet breed geïmplementeerd.

Bij organisatievalidatie wordt er nog een stapje bij bovenop gedaan. Antagonist verkoopt alleen OV-certificaten van Comodo dus hier wordt hun procedure toegelicht. Eerst probeert de CA het telefoonnummer van de organisatie te vinden. Bijvoorbeeld via de telefoongids of Kamer van Koophandel. De klant krijgt dan een e-mail waarmee ze kunnen afspreken wanneer ze gebeld worden. Zodra dit is voltooid, dan heeft Comodo voldoende vertrouwen dat ze met de juiste organisatie te maken hebben en geven het certificaat uit.

Voor uitgebreide validatie zijn er ook nog formulieren die ingevuld moeten worden om werkelijk aan te tonen dat je het juiste bedrijf bent. Hierbij wordt bijvoorbeeld een KvK-uittreksel gebruikt.

Samenvattend

We hebben gezien dat we dankzij het OSI-model abstracter kunnen nadenken. Ook gebruiken veel netwerkprotocollen een handshake die meerdere vaste stappen omvat. Verder verandert HTTP niet of we TLS wel of niet gebruiken, omdat de onderliggende laag dat al voor ons regelt. Khan Academy’s Journey into cryptography is aan te raden voor mensen die daar meer over willen leren, omdat de exacte algoritmes niet zijn behandeld. Het is een uitstekende en leuke interactieve manier waarin uitleg met opdrachten wordt gecombineerd.

Het moge duidelijk zijn dat dit alles complex is en alle instellingen zoals key exchanges en ciphers voor- en nadelen hebben. Het de taak van de systeembeheerder om dit goed in te stellen en voor de TLS-instellingen helpt Mozilla ze met een configuratie-generator.

Voor onze klanten zorgen wij dat het goed is ingesteld met een balans tussen veiligheid en compatibiliteit met oude platformen. Ook hebben we het bestellen van SSL-certificaten zo gemakkelijk mogelijk gemaakt zodat iedere klant zijn of haar websites veilig kan aanbieden.

Wil je graag weten hoe je jouw website over SSL beschikbaar kunt maken?

Klik hier voor meer informatie

P.S. Wil je op de hoogte blijven van alle artikelen, updates, tips en trucs die verschijnen op ons blog? Dat kan! Rechts bovenin via RSS, e-mail, het liken op Facebook, het +1’en op Google+ of het volgen op Twitter.

Deel Tweet +1 Deel