Beveiliging van transportlaag

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken
TLS op de TCP/IP-protocolstack
gebruik maken van
HTTPS IMAPS POP3S SMTPS ...
gebruik maken van TLS
vervoer- TCP
internet IP ( IPv4 , IPv6 )
Netwerktoegang Ethernet token
bus
token
ring
FDDI ...

Transport Layer Security (TLS, Engels voor Transport Layer Security), ook wel bekend onder de vroegere naam Secure Sockets Layer (SSL) is een coderingsprotocol voor veilige gegevensoverdracht op internet .

TLS bestaat uit de twee hoofdcomponenten TLS-handshake en TLS-record. In de TLS-handshake vindt een veilige sleuteluitwisseling en authenticatie plaats. TLS Record gebruikt vervolgens de symmetrische sleutel die is overeengekomen in de TLS-handshake voor veilige gegevensoverdracht - de gegevens worden versleuteld en verzonden met een MAC die is beveiligd tegen wijzigingen.

Voor de sleuteluitwisseling worden in de oudere TLS-versies verschillende algoritmen met verschillende veiligheidsgaranties gebruikt. De nieuwste versie TLS 1.3 [1] gebruikt alleen het Diffie-Hellman-sleuteluitwisselingsprotocol (DHE of ECDHE). Hier is een nieuwe verbinding voor elke onderhandelde sessiesleutel (sessiesleutel). Aangezien dit gebeurt zonder het gebruik van een sleutel voor de lange termijn, bereikt TLS 1.3 een perfecte voorwaartse geheimhouding .

TLS in de praktijk

TLS-codering wordt momenteel voornamelijk gebruikt met HTTPS . De meeste huidige webbrowsers en webservers geven de voorkeur aan TLS 1.3 en TLS 1.2, meestal worden ook TLS 1.1 en TLS 1.0 ondersteund, maar dit leidt tot een beveiligingswaarschuwing. [2] [3] [4] In de huidige browsers zijn SSLv3 en SSLv2 gedeactiveerd, [5] omdat deze protocolversie een aantal beveiligingslekken heeft, waaronder de Poedelaanval . [6] [7] De doorontwikkeling van TLS 1.3 wordt door alle noemenswaardige browsers op desktops en smartphones ondersteund [8] , TLS 1.2 wordt door 98,4 procent van alle gebruikte browsers ondersteund (met uitzondering van enkele jaren oude versies) (status 03/ 2021). [9]

Het Duitse Federale Bureau voor Informatiebeveiliging beveelt versies 1.2 en 1.3 aan bij het gebruik van TLS. Cipher-suites met Perfect Forward Secrecy hebben de voorkeur. [10]

Al geruime tijd maken steeds meer websitebeheerders gebruik van Extended Validation TLS-certificaten (EV-TLS-certificaten). Ook wordt in de adresregel van de browser een veld getoond waarin de certificaat- en domeinhouder afwisselt met de certificeringsinstantie . Daarnaast is, afhankelijk van de gebruikte browser en/of add-on, de adresregel (deels) groen gekleurd. Internetgebruikers zouden dus nog sneller moeten kunnen herkennen of de website die ze bezoeken echt is en beter beschermd zijn tegen phishing-pogingen . Technisch gezien bieden EV-TLS-certificaten geen uitgebreide bescherming; de encryptie en de sterkte ervan zijn identiek. Alleen de eigenaar wordt beter en uitgebreider geverifieerd. Sinds 2019 worden deze certificaten niet meer prominent in browsers uitgelicht omdat de verwachte veiligheidswinst voor de eindgebruiker niet is behaald. [11]

Sinds januari 2017 markeert de Chrome-webbrowser websites die informatie verzamelen zonder HTTPS te gebruiken als onveilig. Dit zal naar verwachting leiden tot een forse toename van het gebruik van HTTPS. In februari 2017 werd HTTPS geactiveerd voor 2,57% van alle geregistreerde Duitse internetdomeinen [12] , evenals 3,70% van de Oostenrijkse domeinen [13] en 9,71% van de Zwitserse domeinen [14] . Een onderzoek van ongeveer 40.000 websites van kleine en middelgrote bedrijven in Baden-Württemberg door de staatscommissaris voor gegevensbescherming en vrijheid van informatie in Baden-Württemberg heeft aangetoond dat ongeveer 7% van de onderzochte websites via HTTPS wordt aangeboden. Voor die websites die via HTTPS worden aangeboden, is server-side ondersteuning voor TLS 1.0 nog steeds zeer wijdverbreid (99%). [15]

Zonder authenticatie op basis van certificaten is TLS vatbaar voor man-in-the-middle-aanvallen : als de man-in-the-middle actief is voordat de sleutel wordt overhandigd, kan hij beide kanten van zijn sleutels voor de gek houden en zo alle dataverkeer in platte tekst en ongemerkt manipuleren. Vanwege het gebrek aan betrouwbaarheid van sommige certificeringsinstanties, wordt de veiligheid van TLS sinds begin 2010 in twijfel getrokken. [16] [17] [18] [19] Door dubieuze certificeringsinstanties in uw eigen browser uit te schakelen, kan dit risico echter grotendeels worden geëlimineerd.

In combinatie met een virtuele server , bijvoorbeeld met HTTP (bijvoorbeeld met de Apache HTTP-server via het VHost- mechanisme), is het fundamenteel een nadeel dat per combinatie van IP-adres en poort slechts één certificaat kan worden gebruikt, aangezien de daadwerkelijke gebruikersgegevens van het bovenstaande protocol (en dus de naam van de VHost) waren op het moment van de TLS-handshake nog niet verzonden. Dit probleem is verholpen met de TLS-extensie Server Name Indication (SNI) in juni 2003 door de RFC 3546 . De gewenste servernaam wordt verzonden wanneer de verbinding tot stand is gebracht. De oorspronkelijke extensie is beschreven voor TLS 1.0, vanwege de compatibiliteit van de afzonderlijke TLS-versies met elkaar, is SNI conform de aanbeveling ook geïmplementeerd voor TLS 1.1, versie 1.2 en 1.3. Versie 1.3 probeert ook de SNI te versleutelen om te voorkomen dat partijen ondanks de versleutelde verbinding informatie over de doelserver vrijgeven. Dit moet echter wel ondersteund worden door de browser, er moet een sleutel zijn opgeslagen in het Domain Name System (DNS) en er moet gebruik worden gemaakt van versleutelde DNS. [20]

In het Tor-netwerk zijn TLS-certificaten van bijzonder belang voor verbindingen met internet, aangezien een niet-versleutelde verbinding met behulp van een man-in-the-middle-aanval daar kan worden onderschept door de computer die de verbinding met internet tot stand brengt (aangeduid als "exit node ") zou heel eenvoudig zijn. Aangezien een verbinding tussen twee eindpunten in het Tor-netwerk echter versleuteld is, kan de versleutelde overdracht van gegevens binnen het netwerk als van secundair belang worden beschouwd, op voorwaarde dat men de routering van de verbindingen vertrouwt. Het belangrijkste kenmerk van TLS-codering is de authenticiteit van de andere kant.

Naast HTTPS als versleutelde variant van HTTP , zijn andere bekende use-cases voor TLS bijvoorbeeld:

Ook verbindingen met databasesystemen kunnen via TLS worden beveiligd. De identiteit van de server of de client wordt gecontroleerd en alle communicatie is versleuteld. [21]

versies

versie Jaar van uitgave Opmerkingen
Oudere versie; niet langer ondersteund: SSL 1.0 1994
Oudere versie; niet langer ondersteund: SSL 2.0 1995 Gebruik niet toegestaan ​​sinds maart 2011. [22]
Oudere versie; niet langer ondersteund: SSL 3.0 1996 Gebruik niet toegestaan ​​sinds juni 2015. [23]
Oudere versie; niet langer ondersteund: TLS 1.0 1999 Gebruik niet toegestaan ​​sinds maart 2021. [24]
Oudere versie; niet langer ondersteund: TLS 1.1 2006 Gebruik niet toegestaan ​​sinds maart 2021. [25]
Oudere versie; nog steeds ondersteund: TLS 1.2 2008
Huidige versie: TLS 1.3 2018 [26] RFC 8446 , bevat ook nieuwe vereisten voor TLS 1.2 [27]
Legende: Oudere versie; Niet langer gesteund Oudere versie; nog steeds ondersteund Huidige versie Huidige voorlopige versie Toekomstige versie

verhaal

  • In 1994, negen maanden na de eerste release van Mosaic , de eerste populaire webbrowser , voltooide Netscape Communications de eerste versie van SSL (1.0).
  • Vijf maanden later verscheen de volgende versie SSL 2.0 samen met een nieuwe editie van de Netscape Navigator.
  • Eind 1995 bracht Microsoft de eerste versie van zijn webbrowser Internet Explorer uit . Kort daarna werd ook de eerste versie van zijn SSL-tegenhanger, PCT 1.0 (Private Communication Technology), bekend. PCT had verschillende voordelen ten opzichte van SSL 2.0 die later in SSL 3.0 werden opgenomen.
  • In de zomer van 1996 droeg Netscape het versiebeheer van zijn SSL 3.0-protocol over aan de IETF om een ​​internetstandaard te ontwikkelen.
  • Vanaf november 1996 [28] ontwikkelde de IETF TLS WG het verbeterde "Transport Layer Security (TLS) Protocol versie 1.0" (interne versie 3.1) op basis van Netscape's SSL 3.0, dat uiteindelijk in januari 1999 werd gepubliceerd als RFC 2246 [29] . Het definitieve specificatiedocument voor Netscape's SSL 3.0 was jarenlang moeilijk te vinden en werd vervolgens in augustus 2011 gepubliceerd als RFC 6101 [30] .
  • TLS werd later uitgebreid met verdere RFC's :
    • RFC 2712 - Toevoeging van Kerberos Cipher Suites aan Transport Layer Security (TLS).
    • RFC 2817 - Upgraden naar TLS Within HTTP / 1.1 verklaart het gebruik van het upgrademechanisme in HTTP / 1.1 om Transport Layer Security (TLS) over een bestaande TCP- verbinding te initialiseren. Hierdoor is het mogelijk om voor zowel onveilig als beveiligd HTTP-verkeer dezelfde “bekende” TCP-poorten (80 en 443) te gebruiken.
    • RFC 2818 - HTTP Over TLS scheidt veilig van onveilig verkeer via afzonderlijke server-TCP-poorten.
    • RFC 3268 - Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) gebruikt de uitbreidbaarheid van TLS en voegt de symmetrische encryptie-algoritmen toe ( RC2 , RC4 , International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES) en Triple DES ) de Advanced Encryption Standard (AES).
    • RFC 3546 - Transport Layer Security (TLS) Extensions introduceert het concept van extensies, waarbij met name tijdens de eerste onderhandeling optionele gegevensvelden of headers kunnen worden verzonden. Een van deze extensies is Server Name Indication .
  • In april 2006 werd versie 1.1 van TLS gestandaardiseerd in RFC 4346, waardoor RFC 2246 overbodig werd. In TLS 1.1 zijn kleine verbeteringen aangebracht in de beveiliging en zijn onduidelijkheden geëlimineerd.
  • In augustus 2008 verscheen versie 1.2 van TLS met RFC 5246 , waardoor RFC 4346 overbodig werd. De definitie van MD5 / SHA-1 in de pseudo-willekeurige functie (PRF) en ondertekende elementen is vervangen door flexibelere oplossingen waarin de hash-algoritmen kunnen worden gespecificeerd.
  • In februari 2015 werd RFC 7465 [31] gepubliceerd, die RC4 voor encryptie verbiedt. [32]
  • In mei 2015 werden aanbevelingen voor een veilig gebruik van TLS en DTLS gepubliceerd met RFC 7525 [33] . Dienovereenkomstig mogen SSLv2, SSLv3, RC4 en andere versleutelingsalgoritmen die vanwege exportbeperkingen beperkt zijn tot een sleutellengte van minder dan 112 bits, niet worden gebruikt. Het gebruik van 3DES voor codering en RSA voor sleuteluitwisseling met statische parameters wordt niet aanbevolen. We raden coderingssuites aan die Ephemeral Diffie-Hellman gebruiken in combinatie met RSA voor sleuteluitwisseling, die voorwaartse geheimhouding biedt (tegen daaropvolgende daaropvolgende decodering), voor codering AES in Galois / Counter-modus met een 128- of 256-bits sleutellengte en dehash-functie SHA- 256 of SHA -384 voor de pseudo-willekeurige functie van TLS. [34]
  • In augustus 2018 werd TLS versie 1.3 gepubliceerd in RFC 8446 , dat sinds 2014 is ontwikkeld. [27]
  • In oktober 2018 verklaarden de fabrikanten van de Firefox-, Chrome-, Edge- en Safari-browsers dat ze vanaf maart 2020 de verouderde TLS 1.0- en 1.1-protocollen niet meer zouden ondersteunen. [2] [3] In Google Chrome 84 is daarom ondersteuning voor TLS 1.0 en 1.1 verwijderd. [4]

functionaliteit

De client brengt een verbinding met de server tot stand. De server authenticeert zichzelf bij de client met een certificaat . De client controleert de betrouwbaarheid van het X.509- certificaat en of de servernaam overeenkomt met het certificaat. Optioneel kan de client zich ook authenticeren bij de server met een eigen certificaat. Vervolgens stuurt de client de server een geheim willekeurig getal versleuteld met de openbare sleutel van de server, of de twee partijen gebruiken de Diffie-Hellman-sleuteluitwisseling om een gedeeld geheim te berekenen. Van het geheim wordt dan een cryptografische sleutel afgeleid. Deze sleutel wordt vervolgens gebruikt om alle berichten op de verbinding te versleutelen met een symmetrische versleutelingsmethode en om de berichtintegriteit en authenticiteit te beschermen met een berichtauthenticatiecode .

TLS-protocollen in de protocolstack

In het OSI-model is TLS gerangschikt in laag 5 (de sessielaag). In het TCP/IP-model bevindt TLS zich boven de transportlaag (bijvoorbeeld TCP ) en onder applicatieprotocollen zoals HTTP of SMTP . In de specificaties wordt dit dan bijvoorbeeld "HTTP over TLS" genoemd. Als beide protocollen echter samen moeten worden beschouwd, wordt meestal een "S" van Secure toegevoegd aan het protocol van de applicatielaag (bijvoorbeeld HTTP S ). TLS werkt transparant, zodat het eenvoudig kan worden gebruikt om beveiligde verbindingen beschikbaar te maken voor protocollen zonder eigen beveiligingsmechanismen. Het kan ook worden uitgebreid om flexibiliteit en toekomstige veiligheid voor de gebruikte coderingstechnieken te garanderen.

Het TLS-protocol bestaat uit twee lagen:

TLS-handshake-protocol TLS-coderingsspecificatie wijzigen. Protocol TLS-waarschuwingsprotocol TLS-toepassingsgegevensprotocol
TLS-opnameprotocol

TLS-opnameprotocol

Het TLS Record Protocol is de onderste van de twee lagen en wordt gebruikt om de verbinding te beveiligen. Het is direct gebaseerd op de transportlaag en biedt twee verschillende diensten die afzonderlijk of gezamenlijk kunnen worden gebruikt:

Bovendien worden de gegevens waarvan een back-up moet worden gemaakt, gefragmenteerd in blokken van maximaal 16.384 (2 14 ) bytes en bij de ontvanger weer in elkaar gezet. De norm schrijft voor dat de blokgrootte deze waarde niet overschrijdt, tenzij het blok gecomprimeerd of versleuteld is - dan mag de blokgrootte 1024 bytes (met compressie) of 2048 bytes (met encryptie) groter zijn. De gegevens kunnen ook worden gecomprimeerd vóór de codering en vóór de berekening van de cryptografische controlesom. De compressieprocedure wordt, net als de cryptografische sleutel, onderhandeld met behulp van het TLS-handshakeprotocol.

De structuur van een TLS-recordbericht is als volgt: Inhoudstype (1 byte: Change Cipher Spec = 20, Alert = 21, Handshake = 22, Application Data = 23) | Protocolversie major (1 byte) | Protocolversie minor (1 byte) | Lengte (1 korte of twee bytes)

TLS-handshake-protocol

TLS-handshake met tweerichtingsverificatie met behulp van certificaten en uitwisseling van RSA-sleutels

Het TLS Handshake Protocol is gebaseerd op het TLS Record Protocol en vervult de volgende functies nog voordat de eerste bits van de applicatiedatastroom zijn uitgewisseld:

  • Onderhandelen over te gebruiken cryptografische algoritmen en sleutels. TLS ondersteunt ook niet-versleutelde verzending.
  • Identificatie en authenticatie van communicatiepartners op basis van asymmetrische encryptiemethoden en public key cryptografie . Deze stap is optioneel een tweerichtingsauthenticatie (in dit geval wordt soms wederzijdse TLS gebruikt), maar meestal authenticeert alleen de server zichzelf bij de client .

De handdruk zelf kan in vier fasen worden verdeeld:

  1. De client stuurt een client hallo naar de server en de server antwoordt naar de client met een server hallo . De parameters van de berichten zijn:
    • de versie (de hoogste TLS-protocolversie die door de client wordt ondersteund)
    • een 32 bytes lange willekeurige informatie (4 bytes tijdstempel + 28 bytes lang willekeurig getal), die later wordt gebruikt om het pre-mastergeheim te creëren (het beschermt tegen replay-aanvallen )
    • een sessie-ID
    • de te gebruiken cipher suite (algoritmen voor sleuteluitwisseling, encryptie en authenticatie)
    • Optioneel, de gewenste FQDN voor Server Name Indication-ondersteuning
    • In de TLS 1.3-versie (met Diffie-Hellman-sleuteluitwisseling ) worden hier ook de sleutelaandelen die de gemeenschappelijke sleutel definiëren, overgedragen.
  2. De server identificeert zichzelf bij de client. Hiervoor wordt een X.509v 3- certificaat via C ertificate naar de klant gestuurd , gevolgd door een CertificateVerify (in sommige TLS-versies). Het C ertificateVerify- bericht bevat een handtekening van eerder uitgewisselde berichten. De server bewijst dus dat hij een geheime sleutel heeft die overeenkomt met de openbare sleutel op het servercertificaat. De klant controleert het certificaat en de handtekening. Lukt dit niet, dan verbreekt de client de verbinding. Daarnaast kan de server optioneel een certificaat voor client authenticatie aanvragen via CertificateRequest . Deze fase kan alleen worden overgeslagen als een anonieme cipher suite wordt gebruikt zonder authenticatie.
  3. Het eerder verkregen servercertificaat bevat de openbare sleutel van de server. Als een coderingssuite met RSA- sleuteluitwisseling wordt gebruikt (zie afbeelding), wordt het door de client gegenereerde pre-mastergeheim versleuteld met deze openbare sleutel en kan het opnieuw worden ontsleuteld door de server met de alleen aan hem bekende privésleutel. Als alternatief kan hier ook de Diffie-Hellman-sleuteluitwisseling worden gebruikt om een ​​gemeenschappelijk pre-mastergeheim te genereren. Als de Diffie-Hellman-geheimen van de server en de client tijdens de handdruk vers en willekeurig worden onderhandeld, wordt aan de vereisten voor Perfect Forward Secrecy voldaan. Nadat het premastergeheim is verzonden, identificeert de client zich bij de server door middel van een certificaat, mits de server een CertificateRequest heeft verzonden. Hiervoor stuurt de klant het klantcertificaat via certificaat, gevolgd door een CertificateVerify. Het CertificateVerify- bericht bevat een handtekening van alle eerder uitgewisselde berichten. De client bewijst dus aan de server dat hij een geheime sleutel heeft die overeenkomt met de openbare sleutel op het clientcertificaat. Vanaf hier weet de server met wie hij communiceert.
  4. Deze fase voltooit de handdruk. Geheim pre-mastergeheim uit de bestaande master kan worden afgeleid dat een eenmalige sessiesleutel ( Engelse sessiesleutel) vertegenwoordigt. Sleutels, die worden gebruikt voor het versleutelen en ontsleutelen van de gegevens en voor de integriteitscontrole , worden op hun beurt afgeleid van het hoofdgeheim . De berichten die de communicatiepartners nu naar elkaar sturen, worden alleen versleuteld verzonden. Als de server zichzelf niet heeft geverifieerd via CertificateVerify in stap 2, weet de client niet dat hij communiceert met de rechtmatige eigenaar van het certificaat totdat hij het eerste versleutelde bericht heeft ontvangen.

TLS-protocol voor coderingsspecificatie wijzigen

Het Change Cipher Spec Protocol bestaat slechts uit een enkel bericht. Dit bericht is één byte groot en heeft de inhoud 1. Met dit bericht informeert de afzender de ontvanger dat hij overschakelt naar de coderingssuite die in de actieve sessie in het handshake-protocol is onderhandeld. Een belangrijke reden voor het definiëren van een apart protocol voor dit bericht is dat TLS-implementaties meerdere berichten van een protocol in één record kunnen combineren (d.w.z. een TLS-gegevenseenheid). Dit is ongewenst voor het bericht "Change Cipher Spec". Omdat records van verschillende protocollen niet gecombineerd kunnen worden, wordt het probleem opgelost door een apart protocol te definiëren. [35]

TLS-waarschuwingsprotocol

Het Alert Protocol onderscheidt ongeveer twee dozijn verschillende berichten. Een van hen kondigt het einde van de sessie aan (close_notify). Anderen hebben bijvoorbeeld betrekking op de protocolsyntaxis of de geldigheid van de gebruikte certificaten. Er wordt onderscheid gemaakt tussen waarschuwingen en fouten, waarbij de laatste de verbinding onmiddellijk verbreekt.

De structuur van een foutmelding is als volgt: AlertLevel (1 byte: Warning = 1, Fatal = 2) | AlertDescription (1 byte: close_notify = 0, […], no_renegotiation = 100).

De volgende ernstige fouttypen zijn gedefinieerd in de specificatie van TLS:

onverwachte_bericht Er is een ongepast bericht ontvangen.
bad_record_mac Er is een onjuiste MAC ontvangen.
decompressie_mislukking Decompressie-algoritme heeft onjuiste gegevens ontvangen.
handshake_failure De afzender kon geen acceptabele set beveiligingsparameters bewerken.
illegale_parameter Een veld in het handshake-bericht was buiten bereik of conflicteerde met andere velden.

De volgende waarschuwingen zijn gedefinieerd in de specificatie van TLS:

close_notify Waarschuwt ontvangers dat de afzender geen verdere berichten op deze verbinding zal verzenden. Moet door elke partner in een verbinding als het laatste bericht worden verzonden.
geen_certificaat Kan worden verzonden als reactie op een certificaataanvraag als het juiste certificaat niet beschikbaar is. (Verwijderd in TLS 1.0 [36] )
bad_certificaat Ontvangen certificaat was onvolledig of onjuist.
niet-ondersteund_certificaat Het type van het ontvangende certificaat wordt niet ondersteund.
certificaat_ingetrokken Certificaat is ingetrokken door de ondertekenaar.
certificaat_verlopen Certificaat is verlopen.
certificaat_onbekend Andere, niet-gespecificeerde redenen deden zich voor terwijl het certificaat werd bewerkt, waardoor het certificaat als ongeldig werd gemarkeerd.

De volgende waarschuwingen zijn toegevoegd aan de specificatie van TLS 1.0: [36]

decryption_failed Decodering is mislukt.
record_overflow
onbekende_ca Onbekende of niet-vertrouwde CA.
toegang geweigerd Toegang geweigerd.
decode_error Decoderingsfout.
decrypt_error Decodering mislukt.
export_restriction Exportbeperking.
protocol_versie Verouderde versie van TLS/SSL.
onvoldoende_beveiliging Onvoldoende beveiliging.
interne fout Interne fout.
gebruiker_geannuleerd Annulering door gebruiker.
geen_heronderhandeling

TLS-toepassingsgegevensprotocol

De applicatiegegevens worden via het Record Protocol getransporteerd, in delen opgesplitst, gecomprimeerd en, afhankelijk van de huidige status van de sessie, ook versleuteld. Inhoudelijk worden ze door TLS niet nader geïnterpreteerd.

Berekening van het hoofdgeheim

In eerdere protocolversies wordt het hoofdgeheim berekend uit het pre-mastergeheim met behulp van de hashfuncties SHA-1 en MD5 , in TLS 1.2 met behulp van een pseudo-willekeurige functie gespecificeerd door een coderingssuite . In deze berekening worden ook de willekeurige getallen uit fase 1 van de handdruk meegenomen. Het gebruik van beide hashfuncties moet ervoor zorgen dat het hoofdgeheim nog steeds wordt beschermd in het geval dat een van de functies wordt geacht te zijn gecompromitteerd. In TLS 1.2 is deze benadering vervangen door de flexibele uitwisselbaarheid van de functie.

veiligheid

Van een aantal aanvallen is bekend dat ze de veiligheidsgaranties op SSL en TLS ondermijnen. [37] De volgende lijst geeft een deel van de bekende aanvallen weer.

Oracle-aanvallen opvullen

De cryptoloog Serge Vaudenay ontdekte in 2002 dat een man-in-the-middle-aanvaller informatie kan verkrijgen uit de opvulling van een bericht dat is versleuteld met de Cipher Block Chaining Mode (CBC) die kan worden gebruikt om het bericht te decoderen. Door gerichte manipulatie van een versleuteld bericht komt de aanvaller erachter of de server een geldige padding meldt en dus een deel van de leesbare tekst correct is geraden. [38]

Als veiligheidsmaatregel moet de server ongeldige berichten weggooien zonder te onthullen of de opvulling of de authenticiteit van het bericht ongeldig was. Een aanvaller kan deze informatie echter ook afleiden door de reactietijden te analyseren (timing attack). SSL, TLS tot versie 1.2 en DTLS worden beïnvloed als een coderingssuite met CBC wordt gebruikt. Geverifieerde coderingssuites worden niet beïnvloed. [39]

In oktober 2014 demonstreerden beveiligingsonderzoekers de POODLE-aanval ( Padding Oracle On Downgraded Legacy Encryption ), waarmee een aanvaller een versie-downgrade van een TLS-verbinding forceert om een ​​Padding Oracle-aanval tegen SSL 3.0 uit te voeren. Om compatibiliteitsredenen werd SSL 3.0 nog steeds ondersteund door webbrowsers en andere implementaties, ondanks de destijds bekende beveiligingsproblemen. Als gevolg hiervan heeft de Internet Engineering Task Force SSL 3.0 als verouderd aangemerkt [40] en een methode gespecificeerd om te beschermen tegen downgrade-aanvallen op TLS. [41]

BEEST

SSL 3.0 en TLS 1.0 gebruiken een voorspelbare initialisatievector in CBC-modus. Een aanvaller kan een gekozen leesbare tekstaanval gebruiken om onbekende delen van de leesbare tekst te achterhalen. Een aanvalsscenario is het stelen van HTTP-cookies , die in versleutelde vorm worden verzonden. Om dit te doen, moet de aanvaller het slachtoffer van de aanval naar een kwaadaardige website lokken, die herhaaldelijk HTTP-verzoeken naar een vreemd domein activeert, waarbij de webbrowser automatisch de HTTP-cookies verzendt die voor het domein zijn ingesteld. De aanvaller kan de cookie karakter voor karakter raden door de deels zelfgekozen inhoud van de HTTP-verzoeken en door te luisteren naar de versleutelde TLS-berichten.

De basis van de aanval werd in 2004 beschreven [42] en in 2011 voor het eerst in de praktijk gedemonstreerd onder de naam BEAST ( Browser Exploit Against SSL/TLS ). [43] [44] TLS-versie 1.1 en hoger worden niet beïnvloed, omdat elk bericht is versleuteld met een pseudo-willekeurige initialisatievector.

Het cryptografische verschil tussen TLS 1.0 en TLS 1.1 is marginaal en er is een triviale en neerwaarts compatibele workaround met 1 / (n-1) TLS-recordsplitsing, waardoor dit marginale verschil tussen TLS 1.0 en TLS 1.1 formeel aantoonbaar niet relevant is. Dieser triviale Workaround wurde von allen von BEAST betroffenen Anwendungen im Laufe des Jahres 2011 eingebaut. BEAST betrifft nur Webbrowser, Java im Browser und SSL-VPNs, weil BEAST nur als Inside-Angriff möglich ist. [45]

Kompressionsangriffe

Die Verwendung der optionalen Kompression von Nutzdaten eröffnet eine Klasse von Angriffen, die das Erraten von Teilen des Klartexts ermöglichen. Das Angriffsszenario ist ähnlich wie beim BEAST-Angriff : der Angreifer führt einen Chosen-Plaintext-Angriff durch und beobachtet die verschlüsselten TLS-Nachrichten im Netz. Das Kompressionsverfahren entfernt Redundanzen aus den Nutzdaten, sodass der zu verschlüsselnde Klartext und damit auch der Geheimtext kürzer wird. Hat der Angreifer einen Teil des unbekannten Klartexts erraten, zum Beispiel ein Zeichen eines HTTP-Cookies, so erfährt er dies aus dem Längenunterschied einer verschlüsselten TLS-Nachricht.

Der Angriff wurde 2012 von den Urhebern des BEAST-Angriffs unter dem Namen CRIME ( Compression Ratio Info-leak Made Easy ) veröffentlicht. [46] Neben SSL und TLS ist auch das SPDY -Protokoll betroffen. Als Schutzmaßnahme wird von der Verwendung der Kompression abgeraten. TLS ab Version 1.3 unterstützt keine Kompression mehr. Der SPDY-Nachfolger HTTP/2 verwendet ein vereinfachtes Kompressionsformat ( HPACK ), das weniger effizient komprimiert als Deflate , dafür aber schwerer anzugreifen ist. [47]

TIME und BREACH sind verbesserte Varianten des Angriffs. TIME ( Timing Info-leak Made Easy ) leitet die Größe einer verschlüsselten TLS-Nachricht aus der Antwortzeit her, ohne dass der Netzwerkverkehr abgehört werden muss. [48] Beide Angriffe erlauben das Erraten von TLS-verschlüsselten Inhalten, wenn TLS-Kompression abgeschaltet ist und stattdessen HTTP-Kompression verwendet wird. Da TLS Kompressionsangriffe nicht grundsätzlich verhindern kann, müssen anwendungsspezifische Schutzmaßnahmen verwendet werden, zum Beispiel der vollständige Verzicht auf Kompression.

Downgrade auf Exportverschlüsselung

Als Folge der Exportbeschränkungen von Kryptographie aus den Vereinigten Staaten sind in TLS zahlreiche exporttaugliche Cipher Suites spezifiziert, die nur kurze Schlüssel verwenden. Trotz bekannter Sicherheitsschwächen wurden oder werden diese zum Teil noch von Implementierungen unterstützt. Der TLS-Handshake soll eigentlich verhindern, dass ein Man-in-the-Middle-Angreifer einen Downgrade auf eine nicht angefragte Cipher Suite erzwingen kann, indem die Handshake-Nachrichten authentifiziert werden. Die Sicherheit der Authentifizierung hängt allerdings auch von der ausgehandelten Cipher Suite ab, sodass der Angreifer den Schlüssel brechen kann.

Beim 2015 veröffentlichten FREAK-Angriff ( Factoring RSA Export Keys ) findet ein Downgrade auf RSA-basierte Cipher Suites mit 512 Bit langen Exportschlüsseln statt. [49] Der Angriff setzt einen Implementierungsfehler voraus, bei dem der Client den 512-Bit-Schlüssel anstatt des längeren Schlüssels aus dem Serverzertifikat verwendet. Der Fehler betraf unter anderem OpenSSL und SecureTransport (Apple). [50] [51]

Kurz darauf veröffentlichte ein Forscherteam den Logjam-Angriff, der einen Downgrade des Diffie-Hellman-Schlüsselaustauschs auf 512-Bit-Restklassengruppen ermöglicht. Ursache ist die Unterstützung von exporttauglichen Cipher Suites mit Ephemeral Diffie-Hellman. [52] Anders als bei FREAK handelt es sich um eine Protokollschwäche in TLS, die auch ohne Implementierungsfehler ausgenutzt werden kann. Der Logjam-Angriff kann in der Praxis performant durchgeführt werden, da ein Großteil der Rechenarbeit zum Brechen des Schlüssels schon vor dem Verbindungsaufbau durchgeführt werden kann. Der erforderliche Rechenaufwand während des eigentlichen Schlüsselaustauschs dauert etwa 70 Sekunden. Als Schutzmaßnahme sollten Server die Unterstützung für exporttaugliche Cipher Suites abschalten und mindestens 2048 Bit lange Gruppen verwenden. Clients sollten Gruppen verwerfen, die kürzer als 1024 Bit sind. [53]

Implementierungsfehler

Neben Sicherheitsschwächen im Protokoll sind TLS-Implementierungen in wiederkehrender Regelmäßigkeit von sicherheitsrelevanten Implementierungsfehlern betroffen. Einer der schwerwiegendsten Fehler war der 2014 entdeckte Heartbleed -Bug in OpenSSL .

Öffentlicher und vorsätzlicher Bruch der Verschlüsselung

Über die ETSI wurde ein sozialer Angriff auf den TLS-Standard gestartet, bei dem eine nachschlüsselfähige und daher als gebrochen anzusehende Version des Standards Eingang in allgemeine Kommunikationsprozesse finden soll.

Die Angreifer leiten eine Berechtigung für ihren Angriff auf die Verschlüsselung daraus ab, dass es in der Wirtschaft, insbesondere in der Finanzindustrie, sowie bei Behörden Möglichkeiten geben müsse, übergeordneten Einblick in verschlüsselte Kommunikation zu nehmen, ohne dass die Beteiligten davon erfahren. [54] Viele Fachleute und Organisationen, wie z. B. die EFF warnen aufgrund der möglichen Kollateralschäden sehr deutlich vor der Nutzung dieses Verfahrens. [55]

Der Versuch, diese defekte Verschlüsselung als „eTLS“ („Enterprise TLS“) [56] in die TLS-Familie einzuführen, wurde über die Namensrechte an TLS abgewehrt. [57] weshalb das Verfahren in ETS umbenannt werden wird.

Da ETS/eTLS als CVE von TLS anerkannt ist, kann man ETS/eTLS auch als (vorsätzlich) fehlerhafte Implementierung von TLS bezeichnen. [58]

Infolge dessen erhielt das Technical Committee CYBER des ETSI 2019 den Negativpreis BigBrotherAward :

„für seine Bemühung, das ‚Enterprise Transport Security' Protokoll (ETS) als Teil des neuen technischen Standards für die Verschlüsselung im Internet festzulegen und damit abgesicherte Verbindungen mit einer Sollbruchstelle auszustatten“

Frank Rosengart : Laudatio bei den BigBrotherAwards [59]

Vor- und Nachteile

Der Vorteil des TLS-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des TLS-Protokolls zu implementieren. Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet.

Der Nachteil der TLS-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist. Die Verschlüsselung selbst beansprucht je nach verwendetem Algorithmus nur wenig Rechenzeit.

Verschlüsselte Daten sind auf niedrigeren Schichten (etwa auf PPTP -Ebene) kaum durch Kompression zu verdichten.

TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen. Es sind Szenarien in serviceorientierten Architekturen denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird. Wenn jede Station nur einen Teil der Nachricht lesen darf, reicht TLS nicht aus, da jede Station alle Daten der Nachricht entschlüsseln kann. Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann.

Implementierungen

Zu den bekanntesten Programmbibliotheken , die Transport Layer Security implementieren, gehören:

Siehe auch

Literatur

  • Eric Rescorla: SSL and TLS. Designing and building secure systems. Addison-Wesley, New York NY ua 2001, ISBN 0-201-61598-3 .
  • Roland Bless ua: Sichere Netzwerkkommunikation. Grundlagen, Protokolle und Architekturen. Springer Verlag, Berlin ua 2005, ISBN 3-540-21845-9 , ( X.systems.press ).
  • Claudia Eckert : IT-Sicherheit. Konzepte – Verfahren – Protokolle. 6. überarbeitete Auflage. Oldenbourg, München ua 2009, ISBN 978-3-486-58999-3 .

Weblinks

Einzelnachweise

  1. Eric Rescorla <[email protected]>: The Transport Layer Security (TLS) Protocol Version 1.3. Abgerufen am 10. September 2020 (englisch).
  2. a b Christopher Wood: Deprecation of Legacy TLS 1.0 and 1.1 Versions. In: WebKit. 15. Oktober 2018, abgerufen am 18. August 2020 .
  3. a b Martin Thomson: Removing Old Versions of TLS. Abgerufen am 18. August 2020 (amerikanisches Englisch).
  4. a b TLS 1.0 and TLS 1.1 - Chrome Platform Status. Abgerufen am 18. August 2020 .
  5. Firefox kann keine sichere Verbindung aufbauen weil die Website eine ältere unsichere Version des SSL-Protokolls verwendet. Abgerufen am 19. Januar 2016 .
  6. SSLv2 insecure – should be disabled by default. Abgerufen am 19. Januar 2016 .
  7. On SSL 2 and older protocols. Abgerufen am 19. Januar 2016 .
  8. Can I use... Support tables for HTML5, CSS3, etc. Abgerufen am 29. März 2021 .
  9. Can I use... Support tables for HTML5, CSS3, etc. Abgerufen am 29. März 2021 .
  10. TR-02102-2 Kryptographische Verfahren: Empfehlungen und Schlüssellängen. Bundesamt für Sicherheit in der Informationstechnik , 22. Februar 2019, abgerufen am 6. März 2020 .
  11. Golem.de: IT-News für Profis. Abgerufen am 29. März 2021 .
  12. Deutsch Internet Statistiken reflecte.de. (Nicht mehr online verfügbar.) Archiviert vom Original am 14. Februar 2017 ; abgerufen am 22. Februar 2017 . Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis. @1 @2 Vorlage:Webachiv/IABot/www.reflecte.de
  13. Österreichisch Internet Statistiken reflecte.at. (Nicht mehr online verfügbar.) Archiviert vom Original am 14. Februar 2017 ; abgerufen am 22. Februar 2017 . Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis. @1 @2 Vorlage:Webachiv/IABot/www.reflecte.at
  14. Schweizerisch Internet Statistiken avidom.ch. (Nicht mehr online verfügbar.) Archiviert vom Original am 14. Februar 2017 ; abgerufen am 22. Februar 2017 . Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis. @1 @2 Vorlage:Webachiv/IABot/www.avidom.ch
  15. Ronald Petrlic, Klaus Manny: Wie sicher ist der Zugriff auf Websites im Internet? In: Datenschutz und Datensicherheit – DuD . Band   41 , Nr.   2 , 3. Februar 2017, ISSN 1614-0702 , S.   88–92 , doi : 10.1007/s11623-017-0734-y .
  16. EFF zweifelt an Abhörsicherheit von SSL. Abgerufen am 19. Januar 2016 .
  17. New Research Suggests That Governments May Fake SSL Certificates. Abgerufen am 19. Januar 2016 .
  18. Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL. (PDF) (Nicht mehr online verfügbar.) Archiviert vom Original am 16. Februar 2016 ; abgerufen am 19. Januar 2016 (englisch). Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis. @1 @2 Vorlage:Webachiv/IABot/files.cloudprivacy.net
  19. Law Enforcement Appliance Subverts SSL. Abgerufen am 19. Januar 2016 .
  20. Was ist verschlüsselte SNI? Cloudflare Inc., abgerufen am 30. März 2021 .
  21. PostgreSQL: Certificate Authentication. Abgerufen am 23. März 2021 .
  22. S. Turner, T. Polk: RFC 6176 . (englisch).
  23. R. Barnes, M. Thomson, A. Pironti, A. Langley: RFC 7568 . (englisch).
  24. K. Moriarty, S. Farrell: RFC 8996 . (englisch).
  25. K. Moriarty, S. Farrell: RFC 8996 . (englisch).
  26. [TLS] Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard. Abgerufen am 31. März 2018 (draft-ietf-tls-tls13-28.txt).
  27. a b RFC 8446 . – The Transport Layer Security (TLS) Protocol Version 1.3 . August 2018. (englisch).
  28. (draft-00)The TLS Protocol Version 1.0. IETF, 26. November 1996, abgerufen am 10. Dezember 2020 .
  29. RFC 2246 . – The TLS Protocol Version 1.0 . Januar 1999. (englisch).
  30. RFC 6101 . – The Secure Sockets Layer (SSL) Protocol Version 3.0 . August 2011. (englisch).
  31. RFC 7465 . – Prohibiting RC4 Cipher Suites . Februar 2015. (englisch).
  32. Jürgen Schmidt: IETF verbietet RC4-Verschlüsselung in TLS. Heise Security, 20. Februar 2015, abgerufen am 20. Februar 2015 .
  33. RFC 7525 . – Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) . Mai 2015. (englisch).
  34. Jürgen Schmidt: IETF spezifiziert Richtlinien für den Einsatz von Verschlüsselung. Heise Security, 8. Mai 2015, abgerufen am 10. Mai 2015 .
  35. Joshua Davies: Implementing SSL / TLS Using Cryptography and PKI. John Wiley and Sons, Indianapolis 2011, S. 344.
  36. a b Schwenk, Jörg (2010): Sicherheit und Kryptographie im Internet. Von sicherer E-Mail bis zu IP-Verschlüsselung , herausgegeben von Vieweg+Teubner Verlag / GWV Fachverlage GmbH, Wiesbaden. ISBN 978-3-8348-0814-1 .
  37. RFC 7457 . – Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) . Februar 2015. (englisch).
  38. Serge Vaudenay: Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS… In: Advances in Cryptology – EUROCRYPT 2002 (= Lecture Notes in Computer Science ). Band   2332 . Springer, Berlin / Heidelberg 2002, S.   535–545 , doi : 10.1145/586110.586125 ( iacr.org [PDF]).
  39. Nadhem J. AlFardan, Kenneth G. Paterson: Lucky Thirteen: Breaking the TLS and DTLS Record Protocols . In: IEEE Symposium on Security and Privacy . IEEE, 2013, S.   526–540 , doi : 10.1109/SP.2013.42 ( ieee-security.org [PDF]).
  40. RFC 7568 . – Deprecating Secure Sockets Layer Version 3.0 . Juni 2015. (englisch).
  41. RFC 7507 . – TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks . April 2015. (englisch).
  42. Gregory V. Bard: The Vulnerability of SSL to Chosen Plaintext Attack . In: Cryptology ePrint Archive . 2004, doi : 10.1145/586110.586125 ( iacr.org [PDF]).
  43. Thai Duong, Juliano Rizzo: Here Come The Ninjas. (PDF) 13. Mai 2011, abgerufen am 10. Januar 2016 .
  44. Juliano Rizzo, Thai Duong: Browser Exploit Against SSL/TLS. 3. Oktober 2011, abgerufen am 10. Januar 2016 .
  45. Eric Rescorla (EKR): Rizzo/Duong BEAST Countermeasures. 5. November 2011, abgerufen am 10. Dezember 2020 .
  46. Juliano Rizzo, Thai Duong: The CRIME attack. (PDF) 2012, abgerufen am 11. Januar 2016 (Präsentation bei der Ekoparty 2012.).
  47. RFC 7541 . – HPACK: Header Compression for HTTP/2 . Mai 2015. (englisch).
  48. Tal Be'ery, Amichai Shulman: A Perfect CRIME? Only TIME Will Tell. (PDF) 2013, abgerufen am 11. Januar 2016 .
  49. Cipher Suites mit „RSA_EXPORT“ im Namen.
  50. Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue: A Messy State of the Union: Taming the Composite State Machines of TLS . In: IEEE Symposium on Security and Privacy . IEEE, 2015, S.   535–552 , doi : 10.1109/SP.2015.39 ( research.microsoft.com [PDF]).
  51. Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue: A messy state of the union: Taming the Composite State Machines of TLS. (PDF) 2015, abgerufen am 11. Januar 2016 (Präsentationsfolien).
  52. Cipher Suites mit „DHE_EXPORT“ im Namen.
  53. David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, Paul Zimmermann: Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice . In: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security . ACM, New York 2015, S.   5–17 , doi : 10.1145/2810103.2813707 ( weakdh.org [PDF]).
  54. TLS-Standardisierung: Behörden und Banken wollen Verschlüsselung aushöhlen . Heise Online; abgerufen am 2. März 2019
  55. ETS Isn't TLS and You Shouldn't Use It . EFF, abgerufen am 2. März 2019
  56. ETSI TS 103 523-3: CYBER; Middlebox Security Protocol; Part 3: Profile for enterprise network and data centre access control (PDF) Technische Spezifikation der ETSI; abgerufen 2. März 2019
  57. IETF an ETSI: Finger weg von TLS . Heise Online; abgerufen am 3. Februar 2019
  58. CVE-2019-9191 The ETSI Enterprise Transport Security (ETS, formerly known as eTLS) protocol does not provide per-session forward secrecy . nist.gov; abgerufen am 2. März 2019
  59. Frank Rosengart: Laudatio Technik: „Technical Committee CYBER“ des Europäischen Instituts für Telekommunikationsnormen (ETSI). In: bigbrotherawards.de. 8. Juni 2019, abgerufen am 21. Juni 2019 .
  60. Google entwickelt eigene SSL-Bibliothek auf heise online