I början av 1990-talet började Netscape utveckla SSL; därför skickades ett första utkast in för SSL v2.0 år 1995. SSL v2.0 hade stora säkerhetsbrister som ledde till skapandet av SSL v3.0. Utkastet till SSL v3.0 lämnades in till IETF år 1996. Med Netscapes ord skulle SSL v3.0 kunna vara ett säkerhetsprotokoll som förhindrar avlyssning, manipulering eller meddelandeförfalskning över internet. IETF publicerade RFC 61012 (Request for Comment) som en specifikation för SSL v3.0.
SSL började bli känt som TLS, och nästa version av TLS kom 1999 med RFC 22463. Kort sagt har SSL v3.0 och TLS 1.0 inga variationer som en utvecklare behöver oroa sig för; det är dock bättre att använda TLS 1.0. Nästa version av TLS, TLS 1.1, kom till 2006 och beskrivs i RFC 43464. TLS 1.1 har förbättringar jämfört med TLS 1.0. Nästa version, TLS 1.2, släpptes 2008 och definieras genom RFC 52465.
TLS 1.2 har genomgått stora förändringar sedan TLS 1.1, och det inkluderar stöd för nyare och säkrare kryptografisk algoritmer. I augusti 2018 släpptes TLS 1.3. Skillnaderna mellan TLS 1.2 och 1.3 är omfattande och betydande, vilket förbättrar både prestanda och säkerhet. Samtidigt är TLS 1.2 fortfarande i stor utsträckning med tanke på dess avsaknad av kända sårbarheter och dess fortsatta användning i företagsmiljöer.
Föråldrade TLS-versioner
Känslig data kräver alltid robust skydd. TLS-protokoll ger konfidentialitet, integritet och ofta autenticitetsskydd för information som överförs över ett nätverk. Detta kan uppnås genom att tillhandahålla en säker kanal mellan en server och en klient för att kommunicera under en session. Med tiden utvecklas nya TLS-versioner, och några av de tidigare versionerna blir föråldrade på grund av sårbarheter eller tekniska skäl; därför bör de inte längre användas för att skydda data.
TLS 1.2 eller TLS 1.3 bör användas, och ingen organisation bör använda SSL 2.0, SSL 3.0, TLS 1.0 eller TLS 1.1.
Föråldrade Cipher Suites
I TLS 1.2 hänvisar termen "krypteringssviter" till den förhandlade och överenskomna uppsättningen kryptografiska algoritmer för TLS-överföringen. TLS-klienten erbjuder en lista över krypteringssviter, och servern väljer förhandlade krypteringssviter från listan. Krypteringssviterna i TLS 1.2 består av en kryptering algoritm, en nyckelutbytesalgoritm, en autentiseringsmekanism och en nyckelderiveringsmekanism.
Krypteringssviter identifieras som föråldrade när en eller flera av mekanismerna är svaga. Sköra krypteringsalgoritmer i TLS 1.2 definieras som NULL, RC2, RC4, DES, IDEA och TDES/3DES; organisationer bör inte använda krypteringssviter med dessa algoritmer. TLS 1.3 tar bort dessa krypteringssviter, men implementeringar som stöder TLS 1.3 och organisationer bör kontrollera TLS 1.2 för föråldrade krypteringssviter.
Föråldrade nyckelutbytesmekanismer
Svagare nyckelutbytesmekanismer som indikeras av chiffersviten inkluderar de som betecknas som EXPORT eller ANON. Chiffersviter som använder dessa nyckelutbytesmekanismer bör inte användas. I TLS-sessioner, även om chiffersviten är acceptabel, kan nyckelutbytesmekanismer använda svaga nycklar som möjliggör utnyttjande. TLS-nyckelutbytesmetoder inkluderar RSA-nyckeltransport och DH- eller ECDH-nyckelupprättande.
DH och ECDH har både statiska och kortlivade mekanismer. NSA rekommenderar RSA nyckeltransport och efemära DH (DHE) eller ECDH (ECDHE) mekanismer, med RSA- eller DHE-nyckelutbyte med minst 3072-bitars nycklar och ECDHE-nyckelutbyten med den elliptiska kurvan secp384r1. För RSA-nyckeltransport och DH/DHE-nyckelutbyte bör nycklar färre än 2048 bitar inte användas, och ECDH/ECDHE med anpassade kurvor bör inte användas.
Risk för föråldrade TLS-protokoll
Föråldrade TLS-protokoll använder krypteringssviter som inte stöds eller rekommenderas, och att använda äldre TLS-versioner skulle kräva ansträngning för att underhålla biblioteken och driva upp kostnaden för produktunderhåll. Förutom det ovan diskuterade scenariot kan några ytterligare vara:
- Att använda föråldrade TLS-versioner skulle tvinga organisationer att använda föråldrade, sårbara krypteringssviter och inte stödja nyare rekommenderade krypteringssviter.
- TLS 1.0 och 1.1 är sårbara för nedgraderingsattacker eftersom de förlitar sig på SHA-1-hash för integriteten hos utbytta meddelanden. Även autentisering av handskakningar görs baserat på SHA-1, vilket gör det enklare för en angripare att utge sig för att vara en server för MITM-attacker. TLS 1.1 eller lägre ger inte möjlighet att välja mer robusta hashalgoritmer, vilket de nyare protokollen gör.
- Att stödja äldre protokoll driver upp kostnaderna eftersom alla sårbarheter måste åtgärdas, bibliotek måste stödjas och attackytan ökar.
Identifiera och analysera föråldrade TLS-protokoll
Eftersom det finns många sätt som föråldrade TLS-konfigurationer kan visas i trafiken rekommenderas följande detekteringsstrategi. Signaturer kan förenklas med hjälp av denna strategi:
- Identifiera först klientens erbjudande och servrar som förhandlar om föråldrade TLS-versioner. Om en klient erbjuder eller en server förhandlar om SSL 2.0, SSL 3.0 eller en föråldrad TLS-version krävs ingen ytterligare trafikanalys, och åtgärder bör vidtas.
- För sessioner som använder TLS 1.2 bör organisationer identifiera och åtgärda enheter som använder föråldrade krypteringssviter. Identifiera klienter som endast erbjuder och servrar som förhandlar om föråldrade TLS-krypteringssviter och uppdatera deras konfigurationer så att de är kompatibla.
- Slutligen bör organisationer identifiera och åtgärda enheter med hjälp av svaga nyckelutbytesmetoder för sessioner som använder TLS 1.2 eller TLS 1.3 och rekommenderade krypteringssviter.
Fördelar med att uppgradera till nyare protokoll
Förutom att bli av med sårbarheter och få bättre säkerhet för miljön tenderar organisationer att få några fördelar genom att uppgradera till nyare protokoll:
- Öka prestandan i den övergripande miljön.
- Förbättrad säkerhet.
- Bättre support och patchar för de sårbarheter som upptäckts, tillsammans med forskning om nya sårbarheter.
- Bättre hashalgoritmer för integritetskontroll och autentisering av handskakningar.
Slutsats
Organisationer krypterar nätverkstrafik för att skydda data under överföring. Att använda föråldrade TLS-konfigurationer ger dock en falsk känsla av säkerhet eftersom det ser ut som att informationen är skyddad, trots att den inte är det. Organisationer bör planera för att avveckla föråldrade TLS-konfigurationer i miljön genom att upptäcka, åtgärda och sedan blockera föråldrade TLS-versioner, krypteringssviter och nyckelutbytesmetoder.
