abonneren

Online beveiligingsstandaard TLS door de jaren heen

Ieder van ons gebruikt dagelijks TLS. Het protocol beveiligt communicatie op internet en krijgt zelfs een plaats in de interface van webbrowsers in de vorm van de ‘groene slotjes’. Het is ondertussen al 25 jaar oud.

De eerste vijf jaar van zijn bestaan heette het encryptieprotocol dat browserontwikkelaar Netscape ontwikkelde SSL (Secure Sockets Layer), en velen noemen het ook nu nog zo, omdat certificaatautoriteiten zijn blijven spreken over SSL-certificaten om hun klanten niet in verwarring te brengen. In 1999 werd de opvolger TLS (Transport Layer Security) ontwikkeld. TLS is vooral bekend van zijn toepassing in websites, en dan spreekt men over HTTPS (HTTP over TLS). Maar het protocol wordt ook gebruikt om e-mailverbindingen en VoIP-verbindingen te beveiligen, virtual private networks (vpn’s) op te zetten (via OpenVPN of OpenConnect) enzovoort.

TLS verenigt twee taken voor de beveiliging van internetcommunicatie: authenticatie en encryptie. De authenticatie gebeurt via een certificaat, waardoor de gebruiker er zeker van kan zijn dat de server waarmee hij communiceert de juiste server is. Optioneel kun je ook gebruikmaken van een clientcertificaat, waardoor de server er zeker van kan zijn dat het aan de clientkant om de juiste persoon gaat. De communicatie tussen client en server wordt versleuteld via symmetrische encryptie.

Aanvallen tegen TLS

TLS heeft zijn reputatie wat tegen omdat er in de laatste jaren talloze kwetsbaarheden in zijn gevonden, waarvan de exploits catchy namen kregen en daardoor breed uitgesmeerd werden in de media. Zo kwam in 2011 BEAST (Browser Exploit Against SSL/TLS) ter wereld, dat een lang bekende kwetsbaarheid in TLS 1.0 uitbuitte, in 2012 CRIME (Compression Ratio Info-leak Made Easy) en in 2013 BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext).

In de jaren erna waren ‘downgrade attacks’ populair. Die verplichten een server ertoe om een onveilige TLS-verbinding op te zetten. Zo publiceerden onderzoekers van Google in 2014 een kwetsbaarheid in SSL 3.0. Maar hun exploit POODLE (Padding Oracle On Downgraded Legacy Encryption) werkte ook bij de nieuwere TLS-versies doordat de belangrijkste webbrowsers standaard naar SSL 3.0 downgraden als er iets fout loopt bij het opzetten van de TLS-verbinding. En in 2015 kwamen FREAK (Factoring RSA Export Keys) en Logjam uit. Een gelijkaardige aanval was het in 2016 ontdekte DROWN (Decrypting RSA with Obsolete and Weakened eNcryption), dat een veilige TLS-configuratie kan kraken als de server ook SSL 2.0 ondersteunt met dezelfde publieke sleutel.

Ondertussen werden er ook fouten ontdekt in specifieke implementaties van TLS. De bekendste was Heartbleed, dat in 2014 ontdekt werd in OpenSSL 1.0.1 en toeliet om gegevens van een server of client te stelen. In 2017 dook een gelijkaardige fout op in de reverse proxy’s van Cloudflare: Cloudbleed.

Om te voorkomen dat er varianten van deze kwetsbaarheden blijven opduiken, heeft de Internet Engineering Task Force (IETF) TLS in versie 1.3 op de schop genomen: het is helemaal van de grond af opnieuw ontwikkeld.

Zwakke configuraties en algoritmes worden niet meer ondersteund in TLS 1.3. Zo zijn SHA-1, RC4, DES, 3DES, AES-CBC, MD5 en de ‘export-grade’-algoritmes die de NSA kon kraken eruit gegooid. Er is nu gewoonweg een veel kleiner aanvalsoppervlak, waardoor we minder aanvallen op TLS 1.3 zouden moeten zien dan op zijn voorgangers. Bovendien heeft TLS 1.3 een expliciete downgradebescherming ingebouwd.

Een andere extra beveiliging is dat TLS 1.3 ‘forward secrecy’, dat in oudere versies van TLS ook al beschikbaar was, nu verplicht maakt. Zonder forward secrecy kan iemand die de geheime sleutel van een TLS-server buitmaakt, versleutelde gegevens die hij vroeger onderschepte ontcijferen. Met forward secrecy in TLS 1.3 is dat niet meer mogelijk, omdat er voor elke sessie een nieuwe sleutel aangemaakt wordt.

Van nul naar twee stappen

Nu meer en meer websites versleuteling gebruiken, en dat ook vaak op mobiele netwerken die al met extra vertraging te maken krijgen, is het belangrijk dat de overhead van TLS beperkt blijft. Ook op dit gebied is TLS 1.3 een grote verbetering.

Bij TLS 1.2 gebeurt de verbindingsopbouw (de ‘TLS handshake’) in twee stappen. Dat noemen we 2-RTT (Round Trip Time). In de eerste stap zegt de client hallo tegen de server, die zijn certificaat terugstuurt. De client controleert dat certificaat aan de hand van de publieke sleutel, en als het klopt, spreekt de client met de server een sessiesleutel af. Daarna kan de versleutelde verbinding beginnen, bijvoorbeeld een HTTP/1.1-aanvraag van een webpagina.

TLS 1.3 kort die verbindingsopbouw in tot één stap, waarin de client in één keer hallo zegt en vraagt om een sessiesleutel af te spreken, en de server geeft in die ene stap zijn certificaat terug en spreekt de sessiesleutel af, waarna de versleutelde verbinding kan beginnen.

Die 1-RTT levert gemiddeld al 100 ms snelheidsverbetering op, maar TLS 1.3 maakt in sommige gevallen zelfs 0-RTT mogelijk: je kunt dan onmiddellijk versleuteld met de server communiceren zonder voorafgaande verbindingsopbouw. Dat werkt door sleutelmateriaal van eerdere sessies te hergebruiken, en gaat dus alleen als je al eens met die server een TLS 1.3-verbinding hebt opgezet. Standaarden zoals DNS over TLS of DNS over HTTPS profiteren sterk van 0-RTT.

Chrome, Firefox en Safari ondersteunen TLS 1.3 al. Op Can I use vind je een overzicht van de ondersteuning van het protocol in allerlei webbrowsers. Aan de serverkant is het voorlopig iets minder gesteld met de ondersteuning, maar daar wordt ook aan gewerkt.

Geschreven door: Koen Vervloesem op

Category: Nieuws, Security

Tags: Encryptie, Tls

Laatste Vacatures

Uitgelicht: Technisch Applicatiebeheerder - CGI