TLS - Transportlaagbeveiliging (2024)

TLS is een protocol dat wordt gebruikt om internetverbindingen te verifiëren en te coderen. TLS is een aparte laag tussen TCP en de applicatie- en presentatielaagprotocollen. In de regel gaat het erom de authenticiteit van de gecontacteerde server te garanderen met een certificaat en de verbinding tussen client en server te versleutelen.

Hoewel TLS veel wordt gebruikt, is de term SSL nog steeds gebruikelijk. Beide termen worden vaak als synoniemen gebruikt.

• SSL - Beveiligde Socket Layer

TLS (versie 1.0) vindt zijn oorsprong in SSL, ontwikkeld door Netscape in de jaren negentig voor de "Netscape Navigator"-browser. De verdere ontwikkeling van SSL eindigde met versie 3. De IETF (Internet Engineering Task Force) nam vervolgens de verdere ontwikkeling en standaardisatie over. Dit resulteerde in 1999 in de TLS (Transport Layer Security) standaard.
TLS is identiek aan SSL, op enkele details na. De verschillen tussen TLS versie 1 en SSL versie 3 zijn echter voldoende om ze onderling incompatibel te maken. TLS gebruikt HMAC om de gegevens te authenticeren en genereert de sleutels met de PRF-functie.

De BSI, als autoriteit die verantwoordelijk is voor de beveiliging van federale IT-systemen, schrijft TLS 1.3 of TLS 1.2 met Diffie-Hellman-sleuteluitwisseling voor als minimumstandaard.

• TLS-versie 1.3

TLS in het OSI-lagenmodel

In het OSI-lagenmodel is TLS laag 5, de sessielaag. In het DoD-laagmodel dat voor TCP/IP wordt gebruikt, wordt TLS afgebeeld op de transportlaag als transportversleuteling via TCP en onder de toepassingsprotocollen. TLS werkt volledig transparant. In theorie kunnen alle denkbare applicatieprotocollen TLS gebruiken voor encryptie. Elk toepassingsprotocol moet TLS echter expliciet beheersen.
Niet-versleutelde HTTP (Hypertext Transfer Protocol) wordt bijvoorbeeld versleutelde HTTPS (Hypertext Transfer Protocol Secure). Ook is het mogelijk om via TLS versleutelde e-mails van de POP-server op te halen of versleuteld door te sturen naar de SMTP-server. Ook hier krijgen de protocollen een achtervoegsel "Secure" (SMTPS, POPS, IMAPS).
TLS is niet langer beperkt tot alleen HTTPS of een ander communicatieprotocol. Procedures zoals EAP-TLS, EAP-TTL, PEAP en ook het LDAP-protocol maken gebruik van TLS.

Toepassingsvoorbeeld: HTTPS

TLS is een optionele beveiligingscomponent voor HTTP en is daarom bedoeld voor websites die vertrouwelijke gegevens verwerken. Bijvoorbeeld met internetbankieren of online winkelen. Deze websites brengen meestal automatisch een versleutelde verbinding tot stand tussen de browser en de webserver. De gebruiker merkt dit pas als er een slot- of sleutelsymbool in de statusbalk wordt weergegeven of als de adresregel van kleur verandert.

• HTTPS / HTTP-beveiligd

Hoe TLS werkt

Onderdeel van TLS is de certificering (1.) van de publieke sleutel, de authenticatie van de server (2.), de validatie van het verzonden certificaat (3.) en de daaropvolgende versleutelde overdracht van gegevens tussen zender en ontvanger.
Certificaten worden gebruikt voor authenticatie. Onder andere om het distributieprobleem van authenticatie-informatie op te lossen en om identiteiten te authenticeren. Het doel hierbij is om zonder enige twijfel de authenticiteit van het remote station te kunnen vaststellen om geen verbinding met het verkeerde remote station aan te gaan.

certificaten

Versleuteling bestaat uit het versleutelen van de gegevens bij de afzender en het ontsleutelen van de gegevens bij de ontvanger. Bij TLS werk je met twee verschillende sleutels voor encryptie en decryptie. Het zogenaamde sleutelpaar bestaat uit een private sleutel en een publieke sleutel. De publieke sleutel van de ontvanger is bekend bij de afzender. Hij gebruikt het om de gegevens te versleutelen. De versleutelde gegevens kunnen dan echter niet meer worden ontsleuteld met de publieke sleutel. Hiervoor is de private sleutel nodig, die alleen bekend mag zijn bij de ontvanger en dus geheim moet worden gehouden. Alleen de server met de overeenkomende privésleutel kan de versleutelde gegevens ontsleutelen (asymmetrisch versleutelingsproces of proces met openbare sleutel).

Voordat de afzender gegevens mag versleutelen, moet hij echter onomstotelijk vaststellen of de publieke sleutel die hij van de ontvanger ontvangt, ook daadwerkelijk toebehoort aan de ontvanger naar wie hij de versleutelde gegevens wil sturen. Een via TLS versleutelde verbinding biedt geen bescherming, tenzij zeker is dat de publieke sleutel afkomstig is van de server waarmee een versleutelde verbinding tot stand moet worden gebracht.
Hier komt het certificaat om de hoek kijken, waarmee een server en zijn publieke sleutel zichzelf authenticeren. Om de geldigheid van de publieke sleutel te onderstrepen, kunnen de serveroperator en domeineigenaar een certificaat laten uitgeven waarop onder meer de domeinnaam, de publieke sleutel, een vervaldatum en welke instantie de betrouwbaarheid heeft bevestigd.
De ontvanger gebruikt het certificaat om zichzelf te authenticeren bij de afzender of de server bij de client. Tegelijkertijd kan de klant het certificaat controleren (validatie) en zo de betrouwbaarheid ervan bepalen (authenticiteit).

TLS werkt met PKIX-certificaten of met een public key-infrastructuur volgens X.509v3. De certificaten koppelen een identiteit aan een publieke sleutel die wordt gebruikt voor authenticatie en encryptie.
Er zijn in totaal drie soorten certificaten, die verschillen in de mate van testen die nodig zijn voor de certificering en dus een overeenkomstig verschillend niveau van authenticiteit garanderen.

• Domein gevalideerd certificaat (DV)
• Organisatie-Validatie-Zertifikat (OV)
• Uitgebreid validatiecertificaat (EV)

De meest voorkomende certificaten zijn DV- en EV-certificaten. Terwijl je DV-certificaten voor slechts een paar euro of zelfs gratis kunt krijgen, kosten EV-certificaten vanwege de aanzienlijke testinspanning enkele honderden of zelfs duizenden euro's. Men kan er echter van uitgaan dat EV-certificaten betrouwbaarder zijn.

Het is voor de gebruiker niet zo eenvoudig om te herkennen welk certificaat wordt gebruikt voor een versleutelde verbinding. Een versleutelde verbinding in een client is meestal alleen te herkennen aan een slotsymbool. Maar niet wat voor certificaat het is.
Certificaten worden uitgegeven en gewaarmerkt door een certificeringsinstantie (CA).

Certificeringsautoriteit (CA) / Certificeringsautoriteit

Wereldwijd zijn er meer dan 700 certificatie-instellingen. In het Engels ook wel Certificate Authority of Certification Authority genoemd. Meestal afgekort tot CA.
De Certificate Authorities (CA) zijn een belangrijke pijler voor de veiligheid op het internet. Iedereen die beveiligde diensten op internet aanbiedt, laat de authenticiteit van digitale sleutels en handtekeningen bevestigen door een certificeringsinstantie.

Hiervoor kan een bedrijf of organisatie na verificatie een digitaal certificaat laten uitgeven door een certificeringsinstantie. Deze kan dan bijvoorbeeld op een webserver worden opgeslagen. Met dit certificaat identificeert de website zich als de eigenaar van de browsers die toegang hebben. De browser van de bezoeker controleert de informatie in het certificaat en vraagt ​​indien nodig aan de uitgevende certificeringsinstantie of het certificaat geldig is.
Zo kunnen de klanten van een bank er bijvoorbeeld vanuit gaan dat ze daadwerkelijk verbonden zijn met de server van de bank en dat de gegevensuitwisseling versleuteld is als ze online bankieren.

De certificeringsinstantie heeft ook een certificaat waarin de openbare sleutel zich bevindt. Dit is een root- of rootcertificaat dat wordt opgeslagen in browsers en besturingssystemen. Deze rootcertificaten worden meestal onvoorwaardelijk vertrouwd. Op basis van de handtekening van de certificeringsinstantie en het basiscertificaat kan een browser bepalen of het certificaat van een domein daadwerkelijk is uitgegeven door de opgegeven certificeringsinstantie.

De zakelijke relatie tussen de certificeringsinstantie en het bedrijf, maar ook met de internetgebruikers, is gebaseerd op vertrouwen. Een CA moet er daarom alles aan doen om ervoor te zorgen dat de verificatieprocessen goed werken en gevrijwaard zijn van manipulatie.
Helaas is het voorgekomen dat indringers toegang hebben gekregen tot interne servers van certificeringsinstanties en daar certificaten hebben gegenereerd. Als een dergelijk certificaat wordt gebruikt, kan een internetgebruiker fraude niet verifiëren. En een bedrijf dat diensten op internet aanbiedt, kan evenmin vaststellen of een certificeringsinstantie niet-geautoriseerde certificaten heeft uitgegeven. Alleen de CA kan frauduleuze certificaten detecteren.
CA's zijn trustees die alleen leven van hun goede reputatie. Zodra bekend wordt dat een CA Schindluder draait of gehackt is, kan deze de shop sluiten.

certificering

Het certificaat wordt uitgegeven door een certificeringsinstantie, ook wel Certificate Authority (CA) genoemd. De certificeringsinstantie ondertekent het certificaat met zijn eigen privésleutel, die de authenticiteit van de gegevens bevestigt. De certificerende instantie controleert vooraf de gegevens in het certificaat en de identiteit van de aanvrager. Er zijn verschillende manieren om dit te doen. Bijvoorbeeld het Certificate Signing Request (CSR).

CSR - Certificaatondertekeningsverzoek / aanvraag voor certificering

Het Certificate Signing Request (CSR) is een gebruikelijke procedure om uw openbare sleutel te laten ondertekenen door een certificeringsinstantie. Daarvoor genereert de serveroperator een paar sleutels op zijn eigen server. Bijvoorbeeld met OpenSSL. Sommige certificeringsinstanties kunnen ook op afstand sleutelgeneratie starten op de computer van de klant. De browsers brengen de nodige cryptografische processen met zich mee.
Het CSR of de aanvraag van het certificaat wordt dan gedaan via bijvoorbeeld een webformulier. U moet informatie verstrekken die door de certificatie-instelling is gecontroleerd en in het certificaat is opgenomen. Nadat het certificaat is uitgegeven, kan de klant het certificaat en de private sleutel opslaan op de betreffende server.

1. De serveroperator genereert een paar sleutels dat bestaat uit een openbare en een persoonlijke sleutel. De privésleutel blijft op de server en wordt geheim gehouden.
2. De serveroperator geeft een CSR voor de openbare sleutel af aan een CA.
3. De CA controleert de details van de CSR en de publieke sleutel.
4. Als alles klopt, maakt de CA een certificaat aan en stuurt dit terug naar de serveroperator.

Validatie van een certificaat

Als een client of server een certificaat ontvangt van een andere server, dan moet deze zichzelf overtuigen van de authenticiteit ervan. Dus of het certificaat echt afkomstig is van de server waarmee contact is gemaakt.
Met de validatie van een certificaat wordt de identiteit bevestigd zonder dat de betrokken communicatiepartners vooraf authenticatie-informatie, zoals sleutels, hoeven uit te wisselen.

In het volgende voorbeeld wordt de validatie beschreven als voorbeeld voor een versleutelde HTTPS-verbinding. Validatie werkt in principe hetzelfde voor andere protocollen.
Nadat de browser een certificaat van de webserver heeft ontvangen, begint het met de validatie. De browser controleert eerst of hij de uitgever van het certificaat, de certificeringsinstantie of de certificeringsinstantie (CA) vertrouwt. Hiervoor moet het bijbehorende rootcertificaat van de certificeringsinstantie in de browser zijn opgeslagen (1e en 2e). De browser heeft een lijst met certificeringsinstanties die hij standaard vertrouwt.
In de tweede stap neemt de browser contact op met de opgegeven validatie-instelling of certificatie-instelling (3e en 4e). Deze controleert of het certificaat geldig is en rapporteert het resultaat terug naar de browser.
Indien het certificaat al bekend is, is validatie via de certificatie-instelling niet meer verplicht.

Authenticatie proces

Bij het eerste HTTPS-verzoek van de browser (client) gebruikt TLS asymmetrische encryptie. De server stuurt zijn openbare sleutel en een certificaat als eerste reactie. Op deze manier authenticeert de webserver zichzelf bij de client. Sleutel en certificaat worden door de opdrachtgever gecontroleerd op geloofwaardigheid. Afhankelijk van de instelling van de client, moet de gebruiker eerst de geloofwaardigheid bevestigen.
Na succesvolle serverauthenticatie genereert de browser een symmetrische sleutel, die wordt versleuteld met de openbare sleutel van de server. De browser stuurt vervolgens de symmetrische sleutel naar de server. De server kan het versleutelde pakket openen met zijn privésleutel. De daarin aanwezige browsersleutel wordt door de server gebruikt voor de symmetrische codering van de volgende verbinding. Veilige verzending is gegarandeerd. De inhoud van de HTTPS-pakketten is beveiligd tegen afluisteren en wijzigen.
Tijdens de gegevensoverdracht tussen client en server wordt herhaaldelijk een nieuwe sleutel onderhandeld, zodat een mogelijke aanvaller de verbinding slechts korte tijd kan verstoren.

Gewoonlijk authenticeert de client zichzelf niet. De mogelijkheid van wederzijdse authenticatie via handtekening is als optie opgenomen in de TLS-specificatie. Alleen bij een SSL VPN moet de klant zich in de regel ook legitimeren met een certificaat.
Gebruikersauthenticatie, indien vereist, vindt meestal plaats op applicatieniveau. Concreet betekent dit dat de klant zich registreert en inlogt in een online winkel of zich identificeert in online bankieren met een pincode, wachtwoord en TAN.

eTLS - Enterprise-TLS

Het Europees Instituut voor Telecommunicatie, kortweg ETSI, heeft een variant van TLS 1.3 gestandaardiseerd. Enterprise TLS, kortweg eTLS, omvat een opzettelijke verzwakking van de Transport Layer Security (TLS)-encryptiestandaard. eTLS biedt de mogelijkheid om dubbele sleutels te bewaren waarmee bedrijven of wetshandhavers versleuteld verkeer kunnen kraken. Hierdoor kunnen bedrijven, dienstverleners en netwerkoperators voldoen aan hun wettelijke verplichtingen om hun netwerken te beveiligen en te monitoren.

Bij eTLS werken servers met statische Diffie-Hellman-sleutels, die ze gedurende een langere periode gebruiken en die ze met regelmatige tussenpozen doorsturen naar middle boxes zodat ze het dataverkeer kunnen uitlezen. De cliënt hoeft er niet bij te zijn. Hij hoeft alleen TLS 1.3 te kennen.

eTLS mag alleen worden gebruikt binnen bedrijfsnetwerken.

Implementaties van SSL of TLS

• besturingssystemen
• Browser
• bibliotheken

Wanneer u implementaties voor TLS gebruikt, moet u vertrouwen op bewezen oplossingen. De betrouwbaarheid van de implementaties komt tot uiting in het feit dat de broncode openbaar is. Zodat je in principe de mogelijkheid hebt om de broncode te controleren op fouten en backdoors. Het is waar dat het niet uitgesloten kan worden dat bekende en populaire bibliotheken nog fouten en hiaten bevatten. Toch is de kans hier groter dat iemand in de broncode gaat kijken. Het speelt ook een rol hoe actief een software of product wordt onderhouden.

Hoe veilig is SSL of TLS?

Sinds de onthullingen rond het NSA-schandaal in de zomer van 2013 is bekend dat TLS definitief onveilig is en onveilige authenticatie bevat, waardoor encryptie slechts gedeeltelijk effectief is. Het probleem is niet de codering zelf, maar het concept van vertrouwen, dat hiërarchisch is gerangschikt.
Een geheime dienst als de NSA, die Google, Microsoft, Yahoo en Apple kan dwingen samen te werken, kan hetzelfde doen met een certificeringsinstantie zoals die door TLS wordt gebruikt om identiteiten te certificeren en te valideren. En daarom worden CA's die impliciet vertrouwd moeten worden, als gecompromitteerd beschouwd.

TLS is dus niet echt veilig! Toch kan TLS als veilig worden beschouwd. Maar dat betekent niet dat het veilig genoeg is voor alle toepassingen en in de toekomst. Dit betekent dat de gebruiker ondanks authenticatie en encryptie met een zekere mate van onveiligheid moet leven.

TLS is voldoende veilig voor de meeste vereisten. Er waren altijd beveiligingsproblemen die slechts gedeeltelijk worden verholpen. De meeste kunnen echter alleen worden uitgebuit door gerichte aanvallen, wat ook gepaard gaat met veel moeite. De meeste aanvallen op TLS zijn niet geschikt voor massasurveillance en houden een zeker risico op detectie in. Alleen aanvallen op basis van het vervangen van valse certificaten, die elke browser als geldig accepteert, zijn echt succesvol. Dat het CA-model voor authenticatie kapot is, is al lang bekend en we leven er al jaren mee. Er zijn oplossingen voor dit probleem. Maar ze komen heel langzaam op gang.

• Kwetsbaarheden van SSL en TLS
• Controleer de codering

Maak TLS veiliger

Let op: Met het huidige vertrouwensmodel (Certificate Authority) is het onmogelijk om authenticatie en encryptie voor alle applicaties veilig te maken. De enige mogelijkheid is om workarounds te bouwen, d.w.z. gedeeltelijke problemen van TLS en zijn gebroken vertrouwensmodel op te lossen om de beveiliging van het systeem op een redelijk geloofwaardige manier te laten werken.

• CA-Pinning / Certificatie Autoriteit Autorisatie
• DANE - DNS-gebaseerde authenticatie van benoemde entiteiten

Omdat de authenticatie fundamenteel gebrekkig is, probeert men de versleuteling in ieder geval zo ver te krijgen dat de communicatie achteraf niet ontsleuteld kan worden. Deze maatregelen zijn nodig omdat bekend is dat geheime diensten (bijvoorbeeld de NSA) versleuteld dataverkeer registreren. Geheime diensten proberen dan via officiële bevelen te eisen dat de sleutels worden afgegeven of op een andere manier toegang tot de sleutels te krijgen.
Bij gebruik van Perfect Forward Secrecy in combinatie met Diffie Hellman kan men de communicatie niet met terugwerkende kracht ontsleutelen. Daarom raadt TLS Perfect Forward Secrecy en Diffie-Hellman aan voor versleutelde verzending van persoonlijke of andere gevoelige gegevens.

• PFS - Perfecte voorwaartse geheimhouding

Om TLS veiliger te laten werken, is er ook geen ontkomen aan TLS versie 1.3.

• TLS-versie 1.3

Overzicht: TLS

• TLS - Transportlaagbeveiliging
• Kwetsbaarheden van SSL en TLS
• HTTPS / HTTP-beveiligd
• HSTS - HTTP Strikte transportbeveiliging
• OCSP - Online Certificaat Status Protocol
• PFS - Perfecte voorwaartse geheimhouding
• CA-Pinning / Certificatie Autoriteit Autorisatie
• DANE - DNS-gebaseerde authenticatie van benoemde entiteiten
• Analyse van SSL- en TLS-verbindingen

Meer gerelateerde onderwerpen:

• Basisprincipes van netwerkbeveiliging
• Beveiligingsconcepten in de informatie- en netwerktechnologie
• Hybride versleutelingsmethoden
• Cryptografische methoden en hun beveiliging (overzicht)