Transport Layer Security: verschil tussen versies

Uit Wikipedia, de vrije encyclopedie
Verwijderde inhoud Toegevoegde inhoud
Inventio (overleg | bijdragen)
→‎Externe links: dood linkje gereanimeerd
Regel 134: Regel 134:
* {{en}}[http://www.nyphp.org/content/presentations/SSL/presentation.html SSL/TLS presentaties]
* {{en}}[http://www.nyphp.org/content/presentations/SSL/presentation.html SSL/TLS presentaties]
* {{en}}[https://web.archive.org/web/20061121130407/http://www.ietf.org/html.charters/tls-charter.html The IETF TLS Workgroup]
* {{en}}[https://web.archive.org/web/20061121130407/http://www.ietf.org/html.charters/tls-charter.html The IETF TLS Workgroup]
* {{nl}}[https://www.ncsc.nl/actueel/whitepapers/ict-beveiligingsrichtlijnen-voor-transport-layer-security-tls.html ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS)] van het [[NCSC]]
* {{nl}}[https://www.ncsc.nl/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-transport-layer-security-tls ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS)] van het [[NCSC]]


{{Appendix|2=
{{Appendix|2=

Versie van 28 nov 2019 10:43

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 én symmetrisch, is dat de eerste relatief tijdrovend is en zich dus niet leent voor het uitwisselen van grote bestanden, maar grotere veiligheid biedt omdat de sleutel voor het vercijferen niet gelijk is aan die voor het ontcijferen.

In alledaags (onveilig) gebruik van TLS wordt alleen de authenticiteit van de server gecontroleerd, terwijl de client geheel onbekend blijft. Door het gebruik van PKI is het ook mogelijk om clients te authenticeren. De protocollen kunnen ook gebruikt worden om client/server-applicaties te beveiligen tegen bijvoorbeeld afluisteren.

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.

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.[2]

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

TLS 1.0

In 1999 werd RFC 2246 gepubliceerd, waarin TLS 1.0 werd beschreven.[4] 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 de nodige zwakheden. Zo zijn het symmetrische encryptie algoritme RC4[5] en de cryptografische hash MD5[6] onveilig gebleken.

In 2011 is deze versie door Thai Duong en Juliano Rizzo gekraakt, met deze aanval op TLS 1.0, BEAST genaamd[7], 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.[8] In 2002 werden er in OpenSSL al maatregelen getroffen om de kwetsbaarheid waarvan BEAST gebruik maakt te mitigeren[9], In reactie op BEAST werden onder andere aan Mozilla Firefox[10] Google Chrome[11], Internet Explorer[12] en na lange tijd ook in Apple's Safari Browser[13] 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.[14] Deze versie is een doorontwikkeling van versie 1.0, en biedt verschillende verbeteringen:

  • Bescherming tegen cipher block chaining aanvallen:
  • Voortijdig afgebroken sessies kunnen hervat worden.
  • Ondersteuning van IANA parameterregistratie.

Hoewel deze versie een betere veiligheid biedt (de aanval van Duong en Rizzo werkt niet), wordt deze versie nog nauwelijks gebruikt.[7]

TLS 1.2

In augustus 2008 werd TLS 1.2 gepubliceerd, gespecificeerd in RFC 5246.[15] Ten opzichte van TLS 1.1 zijn veel verbeteringen aangebracht, met name in de gebruikte cryptografische hashes, die onveilig waren gebleken[5][6] 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[16] 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.[17]

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.

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 en gecomprimeerd. 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

  • SSL 3.0, achteraf beschreven in RFC 6101: "The Secure Sockets Layer (SSL) Protocol Version 3.0".[18]
  • TLS 1.0 staat beschreven in RFC 2246: "The TLS Protocol Version 1.0".[19]
  • TLS 1.1 staat beschreven in RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1".[20]
  • De huidige goedgekeurde versie van TLS is versie 1.2, gespecificeerd in RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".[21]

Uitbreidingen op TLS 1.0

RFC's:

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

Uitbreidingen op TLS 1.1

RFC's:

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

Uitbreidingen op TLS 1.2

RFC's:

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

Externe links