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. 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.
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.SSL broken, hackers create rogue CA certificate using MD5 collisions, op ZDNet.
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. 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.
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.: The Secure Sockets Layer (SSL) Protocol Version 3.0.
Alle drie deze versies moeten worden beschouwd als onveilig, sinds in oktober 2014 de POODLE-kwetsbaarheid bekend werd.
TLS 1.0 In 1999 werd RFC 2246 gepubliceerd, waarin TLS 1.0 werd beschreven.: The TLS Protocol Version 1.0. 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 RC4RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4, op rsa.com. en de cryptografische hash MD5MD5 considered harmfull today, op tue.nl. onveilig gebleken.
In 2011 is deze versie door Thai Duong en Juliano Rizzo gekraakt. Met deze aanval op TLS 1.0, BEAST genaamd,BEAST exploits paypal SSL, op The Register. 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.Beveiliging websites mogelijk in gevaar door ssl-kwetsbaarheid, op tweakers.net In 2002 werden er in OpenSSL al maatregelen getroffen om de kwetsbaarheid waarvan BEAST gebruik maakt te mitigeren,Changes between 0.9.6c and 0.9.6d 9 May 2002, openssl.org changelog In reactie op BEAST werden onder andere aan Mozilla FirefoxBug 665814 - (CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76), op bugzilla.mozilla.org, Google Chrome,Chromium Revision 97269, src.chromium.org Internet ExplorerMicrosoft-beveiligingsbulletin MS12-006 - Belangrijk, op technet.microsoft.com en na lange tijd ook in Apple's Safari BrowserApple Turns on Safari BEAST Attack Mitigation by Default in OS X Mavericks, op threatpost.com 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.: The Transport Layer Security (TLS) Protocol Version 1.1. 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.
TLS 1.2 In augustus 2008 werd TLS 1.2 gepubliceerd, gespecificeerd in RFC 5246.: The Transport Layer Security (TLS) Protocol Version 1.2. Ten opzichte van TLS 1.1 zijn veel verbeteringen aangebracht, met name in de gebruikte cryptografische hashes, die onveilig waren gebleken 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: Prohibiting Secure Sockets Layer (SSL) Version 2.0. 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.: The Transport Layer Security (TLS) Protocol Version 1.3. 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: 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.
Protocollen 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.
Bestand:TLS_protocol_stack.jpg
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.
Bestand:Client_server_handshake.jpg
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