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

Doelstellingen

Het doel van de TLS-protocollen is tweeledig.

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.

Toepassing

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 in de praktijk bij webhosting

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]

Geschiedenis en ontwikkeling

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.

SSL 1.0, 2.0 en 3.0

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]

TLS 1.0

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.

TLS 1.1

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:

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]

TLS 1.2

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.

TLS 1.3

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.


Werking

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.

Beschrijving

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:

Protocollen

TLS Protocol is samengesteld uit twee interne lagen:

TLS Protocol

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.

TLS Record Protocol

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.

TLS Handshake Protocol

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.

TLS Change Cipher Protocol

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

TLS Alert Protocol

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.

Standaarden

Uitbreidingen op TLS 1.0

RFC's:

Uitbreidingen op TLS 1.1

RFC's:

Uitbreidingen op TLS 1.2

RFC's:

Externe links

Categorieën