Begin jaren negentig begon Netscape met de ontwikkeling van SSL; daarom werd een eerste ontwerp ingediend voor SSL v2.0 in 1995. SSL v2.0 had grote beveiligingslekken die leidden tot de ontwikkeling van SSL v3.0. Het concept voor SSL v3.0 werd in 1996 ingediend bij de IETF. Volgens Netscape zou SSL v3.0 een beveiligingsprotocol kunnen zijn dat afluisteren, knoeien of vervalsing van berichten via internet voorkomt. De IETF publiceerde RFC 61012 (Request for Comment) als specificatie voor SSL v3.0.
SSL werd bekend als TLS en de volgende versie van TLS kwam in 1999 met RFC 22463. Kort gezegd hebben SSL v3.0 en TLS 1.0 geen variaties waar een ontwikkelaar zich zorgen over hoeft te maken; het is echter beter om TLS 1.0 te gebruiken. De volgende versie van TLS, TLS 1.1, verscheen in 2006 en is beschreven in RFC 43464. TLS 1.1 bevat verbeteringen ten opzichte van TLS 1.0. De volgende versie, TLS 1.2, werd uitgebracht in 2008 en is gedefinieerd in RFC 52465.
TLS 1.2 heeft grote veranderingen ondergaan sinds TLS 1.1 en bevat ondersteuning voor nieuwere en veiligere cryptografische algoritmen. In augustus 2018 werd TLS 1.3 uitgebracht. De verschillen tussen TLS 1.2 en 1.3 zijn uitgebreid en significant, en verbeteren zowel de prestaties als de beveiliging. Tegelijkertijd wordt TLS 1.2 nog steeds veel gebruikt vanwege de afwezigheid van bekende kwetsbaarheden en het voortdurende gebruik ervan in zakelijke omgevingen.
Verouderde TLS-versies
Gevoelige gegevens vereisen altijd robuuste bescherming. TLS-protocollen bieden vertrouwelijkheid, integriteit en vaak ook authenticiteitsbescherming voor informatie tijdens de overdracht via een netwerk. Dit kan worden bereikt door een beveiligd kanaal te bieden tussen een server en een client om tijdens een sessie te communiceren. Na verloop van tijd worden er nieuwe TLS-versies ontwikkeld en raken sommige van de vorige versies verouderd vanwege kwetsbaarheden of technische redenen; ze mogen daarom niet langer worden gebruikt om gegevens te beschermen.
TLS 1.2 of TLS 1.3 moet worden gebruikt en geen enkele organisatie mag SSL 2.0, SSL 3.0, TLS 1.0 of TLS 1.1 gebruiken.
Verouderde cipher suites
In TLS 1.2 verwijst de term "cipher suites" naar de onderhandelde en overeengekomen set cryptografische algoritmen voor de TLS-transmissie. De TLS-client biedt een lijst met cipher suites aan en de server selecteert de onderhandelde cipher suites uit de lijst. De cipher suites in TLS 1.2 bestaan uit een encryptie algoritme, een sleuteluitwisselingsalgoritme, een authenticatiemechanisme en een sleutelafleidingsmechanisme.
Cipher suites worden als verouderd aangemerkt wanneer een of meer van de mechanismen zwak zijn. Fragiele encryptiealgoritmen in TLS 1.2 zijn gedefinieerd als NULL, RC2, RC4, DES, IDEA en TDES/3DES; organisaties dienen geen cipher suites met deze algoritmen te gebruiken. TLS 1.3 verwijdert deze cipher suites, maar implementaties die TLS 1.3 ondersteunen en organisaties dienen TLS 1.2 te controleren op verouderde cipher suites.
Verouderde sleuteluitwisselingsmechanismen
Zwakkere sleuteluitwisselingsmechanismen die door de coderingssuite worden aangegeven, zijn onder meer die welke zijn aangeduid als EXPORT of ANON. Coderingssuites die deze sleuteluitwisselingsmechanismen gebruiken, mogen niet worden gebruikt. In TLS-sessies kunnen sleuteluitwisselingsmechanismen, zelfs als de coderingssuite acceptabel is, zwakke sleutels gebruiken die misbruik mogelijk maken. TLS-sleuteluitwisselingsmethoden omvatten RSA-sleuteltransport en DH- of ECDH-sleutelvaststelling.
DH en ECDH hebben zowel statische als efemere mechanismen. NSA adviseert RSA Sleuteltransport en ephemeral DH (DHE) of ECDH (ECDHE) mechanismen, waarbij RSA- of DHE-sleuteluitwisseling gebruikmaakt van sleutels van ten minste 3072 bits en ECDHE-sleuteluitwisselingen de elliptische curve secp384r1. Voor RSA-sleuteltransport en DH/DHE-sleuteluitwisseling mogen geen sleutels van minder dan 2048 bits worden gebruikt en mag geen ECDH/ECDHE met aangepaste curven worden gebruikt.
Risico van verouderde TLS-protocollen
Verouderde TLS-protocollen gebruiken coderingssuites die niet worden ondersteund of aanbevolen. Het gebruik van oudere TLS-versies zou inspanningen vergen om de bibliotheken te onderhouden en de kosten voor productonderhoud opdrijven. Naast het hierboven besproken scenario kunnen er nog andere scenario's zijn:
- Als organisaties verouderde TLS-versies gebruiken, moeten ze verouderde, kwetsbare cipher suites gebruiken en geen ondersteuning bieden voor de nieuwere aanbevolen cipher suites.
- TLS 1.0 en 1.1 zijn kwetsbaar voor downgrade-aanvallen omdat ze afhankelijk zijn van de SHA-1-hash voor de integriteit van uitgewisseld berichten. Zelfs authenticatie van handshakes gebeurt op basis van SHA-1, waardoor het voor een aanvaller gemakkelijker is om zich voor te doen als een server voor MITM-aanvallen. TLS 1.1 en lager bieden niet de mogelijkheid om robuustere hashing-algoritmen te selecteren, wat de nieuwere protocollen wel doen.
- Ondersteuning van oudere protocollen leidt tot hogere kosten, omdat alle kwetsbaarheden moeten worden gepatcht, bibliotheken moeten worden ondersteund en het aanvalsoppervlak groter wordt.
Identificeren en analyseren van verouderde TLS-protocollen
Omdat verouderde TLS-configuraties op veel manieren in het verkeer kunnen worden weergegeven, wordt de volgende detectiestrategie aanbevolen. Met deze strategie kunnen handtekeningen worden vereenvoudigd:
- Identificeer eerst het aanbod van de klant en de servers die gebruikmaken van verouderde TLS-versies. Als een klant SSL 2.0, SSL 3.0 of een verouderde TLS-versie aanbiedt of een server hiermee werkt, is verdere verkeersanalyse niet nodig en moeten herstelstrategieën worden ingezet.
- Vervolgens moeten organisaties voor sessies met TLS 1.2 apparaten identificeren en herstellen die verouderde coderingssuites gebruiken. Identificeer clients die alleen verouderde TLS-coderingssuites aanbieden en servers die ermee werken, en werk hun configuraties bij zodat ze voldoen aan de vereisten.
- Tot slot moeten organisaties apparaten identificeren en verhelpen die gebruikmaken van zwakke sleuteluitwisselingsmethoden voor sessies met TLS 1.2 of TLS 1.3 en aanbevolen cipher suites.
Voordelen van upgraden naar nieuwere protocollen
Naast het feit dat kwetsbaarheden worden geëlimineerd en de beveiliging van de omgeving wordt verbeterd, profiteren organisaties doorgaans ook van een aantal voordelen door te upgraden naar nieuwere protocollen:
- Verbeter de prestaties in de algehele omgeving.
- Verbeterde beveiliging.
- Betere ondersteuning en patches voor de gevonden kwetsbaarheden, samen met onderzoek naar nieuwe kwetsbaarheden.
- Betere hash-algoritmen voor integriteitscontrole en authenticatie van handshakes.
Conclusie
Organisaties versleutelen netwerkverkeer om gegevens tijdens de overdracht te beschermen. Het gebruik van verouderde TLS-configuraties geeft echter een vals gevoel van veiligheid, omdat het lijkt alsof de gegevens beschermd zijn, ook al is dat niet zo. Organisaties moeten ervoor zorgen dat verouderde TLS-configuraties in de omgeving worden verwijderd door verouderde TLS-versies, coderingssuites en sleuteluitwisselingsmethoden te detecteren, te herstellen en vervolgens te blokkeren.
