Transport Layer Security

Transport Layer Security (TLS) en diens voorganger Secure Sockets Layer (SSL), zijn encryptie-protocollen die de communicatie tussen computers (bijvoorbeeld op het internet) beveiligen.

Het doel van de TLS-protocollen is tweeledig.

• Ten eerste wordt de gevonden server geauthenticeerd door middel van een certificaat dat berust op asymmetrische cryptografie. Hierdoor kan de gebruiker zeker zijn dat de gevonden server ook inderdaad is wie hij zegt te zijn.
• Ten tweede wordt de communicatie tussen beide partijen versleuteld door gebruik te maken van symmetrische cryptografie. Dit gebeurt met een block-cipher zodat deze voor kwaadwillenden niet te volgen is. De sleutel voor deze fase wisselt en wordt door middel van een Diffie-Hellman sleuteluitwisseling (key exchange) afgesproken.

De reden voor het gebruik van twee afzonderlijke cryptografische methoden, asymmetrisch en symmetrisch, is dat de eerste relatief tijdrovend is en zich dus niet leent voor het uitwisselen van grote hoeveelheden data.

In alledaags gebruik van TLS wordt alleen de authenticiteit van de server gecontroleerd, terwijl de client geheel onbekend blijft. Het is mogelijk om ook de client via TLS te authenticeren maar dat gebeurt alleen bij een aantal specifieke toepassingen. De protocollen kunnen ook gebruikt worden om client/server-applicaties te beveiligen.

TLS wordt voornamelijk gebruikt in situaties waarin het nodig is te verifiëren of men inderdaad verbonden is met de gewenste server. Met name in bancaire toepassingen (internetbankieren) of communicatie met de overheid is dit van groot belang, aangezien vaak financiële belangen in het spel zijn, of persoonlijke of anderszins vertrouwelijke informatie wordt uitgewisseld.

Deze veiligheid berust in veel gevallen op een public key infrastructure (meestal X.509) die door een certification authority (CA) wordt ondersteund. In het recente verleden is echter gebleken dat verschillende bedrijven die zich als CA opwierpen minder betrouwbaar waren dan noodzakelijk, wat het vertrouwen in deze aanpak heeft ondermijnd. Met name het debacle rond DigiNotar heeft hierbij in Nederland een grote rol gespeeld, maar ook gevallen van rogue CA's zijn bekend en hebben internationaal opzien gebaard.^[1]

SSL en TLS zijn geïmplementeerd in veel vrije en opensourcesoftware-projecten. Programmeurs kunnen voor SSL- en TLS-functionaliteit gebruikmaken van o.a. PolarSSL, CyaSSL, OpenSSL, NSS en GnuTLS.

SSL is mede een standaard geworden in de communicatie binnen de webhostingindustrie. Alle hostingproviders communiceren of ze wel of niet SSL aanbieden bij de verschillende hostingpakketten en deze wordt bij de afname gekoppeld aan een domeinnaam binnen de hostingprovider. De benaming van TLS (Transport Layer Security) wordt tegenover consumenten en klanten binnen de communicatie nauwelijks gebruikt, er wordt altijd gesproken over wel of niet SSL-encryptie.^[2] De toename van SSL bij websites is ontstaan doordat Google in 2014 heeft aangegeven dat https-websites (die voorzien zijn van SSL) wordt gezien als een belangrijk SEO-rankingsignaal.^[3]

De eerste aanzet werd gegeven door de Secure Network Programming API die de gebruikelijke netwerk API's (met name Berkeley Sockets) nauwkeurig imiteerde om zo de ontwikkeling van veilige netwerksoftware gemakkelijk te maken.

Secure Sockets Layer werd in 1994 ontwikkeld door Netscape Communications Corporation op basis van het Kerberos-beveiligingsprotocol, als een protocol dat blijvende en veilige transacties toeliet. De eerste versie SSL 1.0 is nooit publiek uitgebracht, maar in 1995 kwam versie 2.0 op de markt. Deze versie bleek al snel cryptografische zwakheden te vertonen en werd in 1996 gevolgd door het compleet herschreven protocol SSL 3.0. Deze versie werd door de IETF in 2011 als een historisch document gepubliceerd in RFC 6101.^[4]

Alle drie deze versies moeten worden beschouwd als onveilig, sinds in oktober 2014 de POODLE-kwetsbaarheid bekend werd.^[5]

In 1999 werd RFC 2246 gepubliceerd, waarin TLS 1.0 werd beschreven.^[6] De verschillen met SSL 3.0 zijn, aldus de auteurs van de RFC, niet dramatisch, maar genoeg om interoperabiliteit tussen de twee te verhinderen. TLS 1.0 bevat een zogenaamd fallback-mechanisme waarmee een verbinding met SSL 3.0 kan worden gemaakt.

Deze versie, hoewel het de meest gebruikte is, vertoont zwakheden. Zo zijn het symmetrische encryptie algoritme RC4^[7] en de cryptografische hash MD5^[8] onveilig gebleken.

In 2011 is deze versie door Thai Duong en Juliano Rizzo gekraakt, met deze aanval op TLS 1.0, BEAST genaamd,^[9] kan de communicatie tussen twee partijen op een netwerk worden ontsleuteld. De BEAST aanval maakt gebruik van een destijds reeds bekende kwetsbaarheid in TLS 1.0, waarvan tot op dat moment gedacht werd dat misbruik van deze kwetsbaarheid praktisch gezien onmogelijk was.^[10] In 2002 werden er in OpenSSL al maatregelen getroffen om de kwetsbaarheid waarvan BEAST gebruik maakt te mitigeren,^[11] In reactie op BEAST werden onder andere aan Mozilla Firefox^[12] Google Chrome,^[13] Internet Explorer^[14] en na lange tijd ook in Apple's Safari Browser^[15] aanpassingen gedaan waarmee BEAST gemitigeerd werd. Hiermee vormt de BEAST aanval in de praktijk geen bedreiging meer voor de vertrouwelijkheid van TLS 1.0 verbindingen.

In april 2006 werd de opvolger van TLS 1.0 gepubliceerd, gespecificeerd in RFC 4346.^[16] Deze versie is een doorontwikkeling van versie 1.0, en biedt verschillende verbeteringen:

• Bescherming tegen cipher block chaining aanvallen:
  • een expliciete initialisatievector voor de blokvercijfering,
  • betere afhandeling van padding errors.
• Voortijdig afgebroken sessies kunnen hervat worden.
• Ondersteuning van IANA parameterregistratie.

Deze versie is niet vatbaar voor de aanval van Duong en Rizzo, maar werd nog nauwelijks gebruikt toen in 2011 de aanval werd ontdekt.^[9]

In augustus 2008 werd TLS 1.2 gepubliceerd, gespecificeerd in RFC 5246.^[17] Ten opzichte van TLS 1.1 zijn veel verbeteringen aangebracht, met name in de gebruikte cryptografische hashes, die onveilig waren gebleken^[7][8] en zijn vervangen door SHA-256. Ook ondersteunt deze versie modernere encryptiemethoden uit de Advanced Encryption Standard. In maart 2011 werd TLS 1.2 verder verfijnd: met RFC 6176^[18] werd de fallback-compatibiliteit met het onveilige SSL 2.0 verwijderd.

In maart 2018 werd TLS 1.3 gepubliceerd, gespecificeerd in RFC 8446.^[19] In TLS 1.3 is een aantal onveilige algoritmes uit versie 1.2 komen te vervallen. Daarnaast is de handshake vereenvoudigd.

Omdat SSL/TLS geïmplementeerd zijn als OSI-transport-layer (vandaar de naam) is het gebruik ervan grotendeels transparant voor het applicatieprotocol. Dat betekent in de praktijk dat het noch voor de http-server, noch voor de browser veel verschil maakt of TLS gebruikt wordt of niet, het applicatieprotocol (HTTP in dit geval, maar hetzelfde geldt voor andere protocollen) is hetzelfde.

Zowel TLS als SSL maakt gebruik van een aantal verschillende stadia:

Peer negotiation for algorithm support

In deze fase worden gebruikte versleutelmechanismen afgesproken en worden ondersteunde versies van het protocol vergeleken. Als incompatibiliteit wordt geconstateerd, wordt de verbinding verbroken.

Public-key encryption-based key exchange and certificate-based authentication

In deze fase worden gebruikte certificaten vergeleken en wordt, middels het Diffie-Hellman-mechanisme, de (willekeurige) sleutel voor de blokvercijfering afgesproken.

Symmetric cipher-based traffic encryption

De gegevensuitwisseling vindt plaats gebaseerd op de overeengekomen versleutelmethode en de afgesproken sleutel.

TLS is gebaseerd op Secure Socket Layer (SSL). Een voordeel van TLS is dat het onafhankelijk is van het applicatieprotocol. Het protocol loopt boven transport protocollen (TCP/IP) en onder applicatieprotocollen zoals HTTP of IMAP. Wanneer er gecommuniceerd wordt tussen server en gebruiker, zorgt TLS ervoor dat de data niet kan worden afgeluisterd of vervalst. Door middel van cryptografie en authenticatie levert TLS een beveiligde verbinding met het internet. Meestal wordt alleen de authenticiteit van de server gecontroleerd, terwijl de client onbekend blijft. Door het gebruik van PKI is het ook mogelijk om clients te authenticeren.

Transport Layer Security voorziet de volgende veiligheden voor de TCP/IP-verbindingen:

• Authenticatie: een applicatie toestaan om de identiteit van een andere applicatie waarmee deze communiceert te verifiëren.
• Privacy: gegevens die tussen applicaties worden overgebracht, kunnen niet worden misbruikt of bekeken.
• Integriteit: applicaties detecteren wanneer gegevens zijn gewijzigd tijdens de transmissie.

TLS Protocol is samengesteld uit twee interne lagen:

• Onderste laag: Record Protocol wordt gebruikt om alle gegevens van de bovenste laag over te brengen (gegevens van applicatielaag en bovenste laag van TLS).
• Bovenste laag: Bestaat uit drie verschillende sub-protocollen: Handshake Protocol, Change Cipher Protocol en Alert Protocol. Zij zorgen voor het tot stand brengen en beheer van veilige verbindingen tussen client/server-applicaties.

TLS Protocol gebruikt certificaten om de uitgewisselde gegevens te authenticeren en privacy te garanderen. Elk certificaat bevat een publieke sleutel. De eigenaar van het certificaat bezit een privésleutel die geassocieerd is met de publieke sleutel in het certificaat. Omdat voor cryptografie gebaseerd op de publieke sleutel, relatief veel rekentijd nodig is, gebruikt TLS Protocol een session key. Deze wordt gebaseerd op de publieke sleutel en een willekeurig getal. Dit willekeurige getal wordt uitgewisseld in het eerste bericht van het protocol (Client hallo en Server hallo). In de vervolgcommunicatie wordt vervolgens de afgeleide session key gebruikt, wat minder rekentijd kost.

Record Protocol is verantwoordelijk voor de fragmentatie en groeperen van gegevens die uit de bovenste lagen verzonden worden. De gegevens worden eerst gefragmenteerd (tot en met TLS versie 1.2 bestaat ook de mogelijkheid voor compressie, maar dat veroorzaakt beveiligingsrisico's en kan dus beter niet gebruikt worden). Daarna zal een message authentication code (MAC) toegevoegd worden. Ten slotte wordt er nog een TLS record header geplaatst voor het ontvangen en herkennen van de gegevens.

Handshake Protocol maakt het mogelijk om vertrouwelijke informatie tussen client/server-applicaties te versturen zodanig dat als een derde partij de informatie mocht onderscheppen deze niet leesbaar zal zijn.

Change Cipher Protocol is een zeer eenvoudig protocol. Het wordt gebruikt om onderbrekingen te verhinderen bij het opzetten van de TLS-sessie.

Alert Protocol verstuurt alarm bij verbindingen tussen client/server-applicaties. Er zijn twee niveaus: waarschuwing en fataal. Wanneer een fataal alarm wordt gesignaleerd, wordt de verbinding verbroken.

• SSL 3.0, achteraf beschreven in RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0^[20]
• TLS 1.0 staat beschreven in RFC 2246: The TLS Protocol Version 1.0^[21]
• TLS 1.1 staat beschreven in RFC 4346: The Transport Layer Security (TLS) Protocol Version 1.1^[22]
• TLS 1.2 staat beschreven in RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2^[23]
• TLS 1.3 staat beschreven in RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3^[19]

RFC's:

• 2595: Using TLS with IMAP, POP3 and ACAP.^[24]
• 2712: Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).^[25]
• 2817: Upgrading to TLS Within HTTP/1.1.^[26]
• 2818: HTTP Over TLS.^[27]
• 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security.^[28]
• 3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS).^[29]
• 3546: Transport Layer Security (TLS) Extensions (obsoleet door RFC 4366).^[30][31]
• 3749: Transport Layer Security Protocol Compression Methods.^[32]
• 3943: Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS).^[33]
• 4132: Addition of Camellia Cipher Suites to Transport Layer Security (TLS).^[34]
• 4162: Addition of SEED Cipher Suites to Transport Layer Security (TLS).^[35]
• 4217: Securing FTP with TLS.^[36]
• 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS).^[37]

RFC's:

• 4347: Datagram Transport Layer Security.^[38]
• 4366: Transport Layer Security (TLS) Extensions.^[31]
• 4492: Elliptic curve cryptography (ECC) Cipher Suites for Transport Layer Security (TLS).^[39]
• 4507: Transport Layer Security (TLS) Session Resumption without Server-Side State.^[40]
• 4680: TLS Handshake Message for Supplemental Data.^[41]
• 4681: TLS User Mapping Extension.^[42]
• 4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS).^[43]
• 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication.^[44]
• 5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication (obsoleet door RFC 6091).^[45][46]

RFC's:

• 5746: Transport Layer Security (TLS) Renegotiation Indication Extension.^[47]
• 5878: Transport Layer Security (TLS) Authorization Extensions.^[48]
• 6091: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication.^[46]
• 6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0.^[49]
• 6209: Addition of the ARIA Cipher Suites to Transport Layer Security (TLS).^[50]

• (en) SSL/TLS presentaties
• (en) The IETF TLS Workgroup
• (nl) ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) van het NCSC