Förstå TLS 1.2 och TLS 1.3

TLS (Transport Layer Security) är det kryptografiska protokoll som krypterar och autentiserar data som överförs mellan klienter och servrar över ett nätverk. Det skyddar personlig information, finansiella transaktioner, API-trafik och affärskommunikation från avlyssning, manipulering och identitetsstöld. TLS 1.3 är den för närvarande rekommenderade versionen. Den minskar antalet handskakningar från 2-RTT till 1-RTT, kräver framåtriktad sekretess via ECDHE för alla anslutningar, tar bort alla äldre svaga krypteringssviter och krypterar mer av handskakningen än TLS 1.2. Den rekommenderade åtgärden: aktivera TLS 1.3 på alla servrar omedelbart, inaktivera TLS 1.0 och 1.1, begränsa TLS 1.2 till endast ECDHE-AEAD-krypteringssviter under övergångsperioden och behåll båda versionerna parallellt tills analys av äldre klienter bekräftar att TLS 1.2 kan tas bort.

Snabbt svar: TLS 1.2 vs TLS 1.3 – Vilken ska man använda och varför

TLS 1.3 är rätt val för alla nya distributioner. Det är snabbare (1-RTT-handskakning kontra 2-RTT), säkrare (obligatorisk forward secretty, krypterad handskakning, borttagning av alla äldre algoritmer) och enklare (5 chiffersviter istället för hundratals). TLS 1.2 är fortfarande endast nödvändig för bakåtkompatibilitet med klienter och system som ännu inte stöder TLS 1.3. NIST kräver att alla TLS-servrar hos den amerikanska federala regeringen stöder både TLS 1.2 (med FIPS-kompatibla chiffersviter) och TLS 1.3 enligt NIST SP 800-52 Revision 2 , med TLS 1.3 som krävs från och med den 1 januari 2024. TLS 1.0 och TLS 1.1 får inte användas; de har kända sårbarheter som kan utnyttjas och ingen aktuell legitim användning.

Vad är TLS?

Transport Layer Security (TLS) är ett kryptografiskt protokoll som standardiserades av IETF år 1999. TLS bygger på SSL (Secure Sockets Layer) genom att åtgärda dess sårbarheter och förbättra säkerheten genom starkare krypteringsalgoritmer, förbättrad certifikatvalidering och skydd mot attacker som finns i SSL-versioner. Äldre TLS-versioner (1.0 och 1.1) hade säkerhetsbrister som gjorde det möjligt för angripare att stjäla känsliga data. TLS skyddar data genom tre mekanismer som arbetar tillsammans:

• Authentication: Servern presenterar ett TLS-certifikat utfärdat av en betrodd certifikatutfärdare (CA) under handskakningen. Klienten verifierar detta certifikat för att bekräfta att det kommunicerar med den legitima servern, inte en imitatör.
• kryptering: Efter att handskakningen etablerat en delad sessionsnyckel krypteras all överförd data med en symmetrisk chiffer (AES-GCM eller ChaCha20-Poly1305 i TLS 1.3), vilket förhindrar att avlyssnare läser innehållet.
• Integritet: AEAD-krypteringssviter inkluderar autentiseringstaggar som upptäcker alla modifieringar av krypterad data, vilket säkerställer att en angripare inte kan ändra data under överföring utan att bli upptäckt.

TLS 1.2 och dess handskakning

TLS 1.2, introducerad i augusti 2008 (IETF RFC 5246), åtgärdade begränsningarna i TLS 1.0 och 1.1 genom starkare krypteringsalgoritmer, förbättrad certifikatvalidering och stöd för AEAD-chiffreringssviter. Dess handskakning kräver två returer (2-RTT):

• Klienten skickar ett ClientHello med stödda TLS-versioner, chiffersviter, ett slumpmässigt klient-ID och ett valfritt sessions-ID.
• Servern svarar med ett ServerHello som väljer TLS-version och chiffersvit, sitt eget slumpmässiga värde och sitt signerade certifikat med publik nyckel. Om ömsesidig autentisering krävs begär servern ett klientcertifikat.
• Klienten validerar serverns certifikat mot betrodda certifikatutfärdare. I ömsesidig TLS (mTLS) validerar servern även klientens certifikat.
• Offentlig nyckelkryptografi säkrar nyckelutbytet: klienten skickar en pre-master-hemlighet krypterad med serverns publika nyckel. Endast servern kan dekryptera den med sin privata nyckel, som förvaras säkert i en HSM eller nyckelvalv. Båda parter härleder sessionsnycklar från premaster-hemligheten och deras slumpmässiga värden.
• Klient och server utbyter meddelanden av typen ChangeCipherSpec och Finished som bekräftar att de är redo för symmetrisk kryptering. All efterföljande kommunikation använder de härledda sessionsnycklarna.

Viktiga funktioner i TLS 1.2

• Förbättrad hashning: ersatte MD5+SHA-1-kombinationen som användes i tidigare versioner med konfigurerbara hashalgoritmer inklusive SHA-256 och SHA-384.
• Stöd för AES-krypteringssvit: introducerade AES chiffersviter med 128-bitars och 256-bitarsnycklar, vilket erbjuder betydligt starkare symmetrisk kryptering än de DES-baserade sviterna den ersatte.
• Stöd för autentiserad kryptering (AEAD): utökat stöd för AEAD-lägen inklusive AES-GCM och AES-CCM, vilka ger både konfidentialitets- och integritetsverifiering i en enda operation.
• Överlåtbara hash- och signaturalgoritmer: Både klient och server kan ange vilka hash- och signaturalgoritmer som stöds under handskakningen, vilket gör att den starkaste ömsesidigt stödda kombinationen kan väljas och möjliggör smidig migrering bort från svaga algoritmer som SHA-1.

TLS 1.3 och dess handskakning

TLS 1.3, publicerad i augusti 2018 (RFC 8446), representerar en betydande omdesign av protokollet. Det prioriterar säkerhet genom att ta bort sårbara äldre alternativ snarare än att lägga till riskminskningar ovanpå dem. TLS 1.3-handskakningen slutförs på en enda tur och retur (1-RTT):

• Klienten skickar ett ClientHello som inkluderar stödda TLS-versioner, krypteringssviter, klientens slumpmässiga värden och nyckeldelningar för dess föredragna ECDHE-grupper. Om klientautentisering är aktiverad inkluderar klienten även certifikatinformation.
• Servern väljer krypteringssviten och ECDHE-gruppen, genererar huvudhemligheten från ClientHello-slumpmässiga och servergenererade slumpmässiga värden i kombination med de valda nyckeldelarna och skickar ett ServerHello med de valda parametrarna plus ett ServerFinished-meddelande. Serverns certifikat och alla efterföljande handskakningsmeddelanden krypteras.
• Klienten verifierar serverns certifikat, genererar samma huvudhemlighet med sin egen nyckeldelning och serverns svar, skickar ett ClientFinished-meddelande och båda parter börjar krypterat utbyte av applikationsdata. Hela handskakningen är klar på en enda gång.

Viktiga funktioner i TLS 1.3

• Obligatorisk framåtriktad sekretess: TLS 1.3 kräver ECDHE för alla nyckelutbyten, vilket gör forward secrecy obligatorisk för varje anslutning. Även om en servers långsiktiga privata TLS-nyckel senare komprometteras, kan tidigare sessioner inte dekrypteras eftersom de kortlivade sessionsnycklarna är borta.
• Endast AEAD-krypteringssviter tillåtna: TLS 1.3 tillåter endast fem krypteringssviter, alla AEAD: AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20-Poly1305-SHA256, AES-128-CCM-SHA256 och AES-128-CCM-8-SHA256. Alla erbjuder autentiserad kryptering som upptäcker manipulering.
• Krypterad handskakning: TLS 1.3 krypterar mer av handskakningen än TLS 1.2, inklusive servercertifikatet. Passiva observatörer kan inte se vilket certifikat en server presenterar.
• 0-RTT-återupptagning: Klienter som återansluter till en server de har anslutit till tidigare kan skicka applikationsdata med det första meddelandet (0-RTT), vilket minskar latensen för återkommande anslutningar. Obs: 0-RTT-data är sårbara för replay-attacker och bör inte användas för icke-idempotenta operationer (tillståndsändrande förfrågningar som finansiella transaktioner).
• Borttagning av algoritm: TLS 1.3 tar bort RC4, DES, 3DES, MD5, SHA-1, RSA-nyckelutbyte, statisk DH, CBC-krypteringssviter och TLS-komprimering – som alla var attackvektorer i TLS 1.2-implementeringar.

Jämförelse: TLS 1.2 vs TLS 1.3

Leverans	TLS 1.2	TLS 1.3	Inverkan
Handskakning tur och retur	2-RTT	1-RTT (0-RTT för återupptagande av session)	TLS 1.3 snabbare anslutningsetablering; 0-RTT har risk för replay-attacker
Tillåtna krypteringssviter	Hundratals, inklusive svaga (RC4, DES, CBC)	Endast fem AEAD-sviter	TLS 1.2 kräver noggrann konfiguration för att undvika svaga konfigurationssviter; TLS 1.3 är säkert till sin natur.
Nyckelutbyte	RSA, DHE, ECDHE (alla stöds)	Endast ECDHE	TLS 1.3 tillhandahåller framåtriktad sekretess för varje anslutning; TLS 1.2 RSA-nyckelutbyte har ingen framåtriktad sekretess
Sekretess framåt	Valfritt (beroende på chiffersviten)	Obligatorisk	TLS 1.3 skyddar tidigare sessioner även om en långsiktig nyckel har komprometterats
Handskakningskryptering	Certifikat exponeras i klartext under handskakning	Certifikat krypterat i handskakning	TLS 1.3 döljer serveridentitet från passiva observatörer
Borttagning av algoritm	Stöder RC4, MD5, SHA-1, 3DES (måste explicit inaktiveras)	Dessa algoritmer tog bort helt	TLS 1.3 eliminerar hela attackklasser (POODLE, BEAST, CRIME) genom att ta bort de sårbara primitiverna.
Återupptagande av session	Sessions-ID:n och sessionsbiljetter	PSK med 0-RTT-alternativ	TLS 1.3-sessionsbiljetter ger framåtriktad sekretess; TLS 1.2-sessionsbiljetter kanske inte
Certifikatvalidering	Vissa handskakningsdetaljer exponerade	Fullständig handskakning krypterad efter ServerHello	TLS 1.3 förbättrar sekretessen för certifikatinnehåll
Prestanda	Långsammare (2-RTT-handskakning)	Snabbare (1-RTT; 0-RTT för återupptagning)	TLS 1.3 minskar latensen, särskilt för nätverk med hög latens och mobila klienter
NIST-mandat	Obligatoriskt; endast FIPS-kompatibla krypteringssviter	Krävs från och med 1 januari 2024 (NIST SP 800-52 Rev. 2)	Båda krävs för federala system; TLS 1.3 är den nuvarande standarden

Val av krypteringssvit för TLS 1.2

TLS 1.3 har en fast lista med fem AEAD-chiffreringssviter; det finns inget att välja mellan. TLS 1.2 stöder ett mycket bredare utbud, inklusive osäkra alternativ som måste inaktiveras explicit. Rekommenderade TLS 1.2-chiffreringssviter enligt NIST SP 800-52 Rev. 2 (i preferensordning):

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (bäst: ECDHE forward secrecy, ECDSA-certifikat, AES-256-GCM AEAD)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ECDHE-vidarebefordranssekretess, RSA-certifikat, AES-256-GCM AEAD)
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Inaktivera uttryckligen i TLS 1.2: alla sviter som innehåller RC4, DES, 3DES, NULL-kryptering, EXPORT, MD5 eller anonym (anon) nyckelutbyte. Inaktivera alla RSA-nyckelutbytessviter (TLS_RSA_*): de tillhandahåller ingen framåtriktad sekretess. Undvik CBC-sviter där det är möjligt på grund av känslighet för padding oracle-attacker (POODLE, BEAST).

Sårbarheter: TLS 1.2 och TLS 1.3

TLS 1.2 har utsatts för flera uppmärksammade attacker, de flesta utnyttjar dess stöd för äldre algoritmer:

• ODJURET (2011): utnyttjade CBC IV-förutsägbarhet i TLS 1.0; delvis mildrad i TLS 1.2 genom AES-GCM och AEAD-krypteringssviter.
• PUDEL (2014): utnyttjade SSL 3.0-utfyllnad i Oracle via protokollnedgraderingsattacker; åtgärdat genom att inaktivera SSL 3.0 och TLS 1.0/1.1.
• Hjärtblödning (2014): Sårbarhet för avslöjande av OpenSSL-minne; inte i själva TLS-specifikationen men påverkade TLS 1.2-implementeringar.
• Tvättbjörnsattack (2020): tidsbaserad sidkanalattack på DHE-nyckelutbyte; TLS 1.3:s användning av ECDHE eliminerar statisk DH helt.
• BROTT och INTRÅNG: utnyttjade TLS-komprimering för att extrahera hemligheter; TLS 1.3 tar bort komprimering helt.

TLS 1.3 eliminerar de flesta av dessa attackytor genom att ta bort de sårbara primitiverna (CBC-lägen, DH, komprimering, RSA-nyckelutbyte) istället för att patcha runt dem. TLS 1.3 är inte immun mot implementeringssårbarheter: felkonfigurationer som förutsägbara nonces i AES-GCM, felaktigt 0-RTT-återspelningsskydd och svag nyckelgenerering kan fortfarande skapa sårbarheter. NIST CVE-databasen har dokumenterat TLS 1.3-implementeringsbrister i specifika produkter. Regelbunden patchning, säkerhetsrevisioner och granskning av TLS-konfigurationen är fortfarande viktiga även med TLS 1.3.

Implementeringsexempel: Enterprise TLS-migrering

En finansiell tjänsteorganisation med 200 offentliga tjänster implementerar en strukturerad TLS-migrering:

1. Revision och inventering: TLS-konfigurationsskanning över alla 200 slutpunkter identifierar: 12 tjänster som fortfarande kör TLS 1.0 eller 1.1; 85 tjänster som använder TLS 1.2 med RSA-nyckelutbyteskrypteringssviter (ingen framåtriktad sekretess); 40 tjänster som använder svaga CBC-krypteringssviter; 63 tjänster som redan använder TLS 1.2 med ECDHE-AEAD-sviter. TLS-certifikat: 140 RSA-2048, 60 ECDSA P-256.
2. Omedelbar inaktivering av TLS 1.0/1.1: De 12 tjänsterna som kör TLS 1.0/1.1 uppdateras för att inaktivera dessa versioner inom 30 dagar, den maximala risken i miljön.
3. TLS 1.3-aktivering på alla servrar: TLS 1.3 är aktiverat tillsammans med TLS 1.2 på alla servrar. Moderna webbläsare och API-klienter börjar omedelbart använda TLS 1.3; äldre klienter fortsätter att använda TLS 1.2.
4. Härdning av TLS 1.2-krypteringssvit: Alla RSA-nyckelutbyten och CBC-krypteringssviter är inaktiverade i TLS 1.2-konfigurationer. Endast ECDHE-AEAD-sviter förblir aktiverade, vilket ger framåtriktad sekretess för TLS 1.2-anslutningar under övergångsperioden.
5. Certifikatmigrering: RSA-2048-certifikat migreras till ECDSA P-256 vid certifikatförnyelse med hjälp av CertSecure-hanterare för att automatisera förnyelse och spåra lager. ECDSA P-256 minskar TLS-handskakningsstorleken och certifikatdatavolymen.
6. TLS 1.2 pensionsplanering: Analys av åtkomstloggen visar att TLS 1.2-användningen minskar månad för månad i takt med att klienterna uppdaterar. En plan är att inaktivera TLS 1.2 när användningen sjunker under 1 % av anslutningarna, vilket förväntas ske inom 12 månader.

Nyckelhanteringsberoenden för TLS

• TLS-skydd för privata nycklar: TLS-serverns privata nyckel är den känsligaste komponenten i en TLS-distribution. Om denna nyckel komprometteras kan tidigare sessioner dekrypteras utan framåtriktad sekretess (TLS 1.2 RSA-nyckelutbyte) och serverimitation. Lagra privata TLS-nycklar i FIPS 140-2 nivå 2 eller högre HSM:er eller hårdvarunyckellager där det är möjligt. Se HSM som en tjänst.
• Automatisering av certifikatlivscykeln: TLS-certifikat är maskinidentiteter med utgångsdatum. Manuell certifikathantering i stor skala misslyckas: CA/Browser Forum har föreskrivit att certifikatens livslängd ska sänkas till 47 dagar år 2029. CertSecure-hanterare automatiserar identifiering, förnyelse och policytillämpning för hela TLS-certifikatinventeringen.
• Valuta för certifikatalgoritm: RSA-2048-certifikat föreslås bli avvecklade efter 2030 enligt NIST IR 8547. Organisationer bör utfärda ECDSA P-256-certifikat för alla nya distributioner och migrera RSA-certifikat vid förnyelse.

Migrationsutmaningar

• Inkompatibilitet med äldre system: Äldre system, inbyggda enheter och viss mellanprogramvara för företag kanske inte stöder TLS 1.3. Dessa kräver uppdateringar eller utbyte, vilket kan vara kostsamt för branscher med tung äldre infrastruktur.
• Borttagning av RSA-nyckelutbyte: TLS 1.3:s eliminering av RSA-nyckelutbyte förstör system som är beroende av det. Nätverksinspektionsenheter som utför TLS-inspektion genom att fånga upp och omsignera anslutningar kan behöva omkonfigureras för att fungera med TLS 1.3:s tillfälliga nyckelutbyte.
• Handskakningsändringar som kräver programuppdateringar: TLS 1.3:s modifierade mekanismer för handskakning och sessionsåterupptagning kräver uppdateringar av applikationslogiken i system med komplexa autentiserings- eller anslutningsflöden.
• Balansering av bakåtkompatibilitet under övergången: Att underhålla TLS 1.2 tillsammans med TLS 1.3 under migreringsperioden är nödvändigt men tillfälligt. TLS 1.2 med ECDHE-AEAD-sviter ger acceptabel säkerhet under övergången; vanlig TLS 1.2 med RSA-nyckelutbyte gör det inte och bör inaktiveras även medan TLS 1.2 underhålls.

Hur krypteringskonsulting kan hjälpa

På Encryption Consulting hjälper vi organisationer att hantera utmaningar med TLS-migrering med anpassade lösningar som är anpassade till deras specifika infrastruktur. Våra tjänster omfattar utvärdering och granskning av TLS-konfiguration (identifiering av svaga krypteringssviter, föråldrade protokollversioner och certifikatgap i er miljö), migreringsplanering och implementering (strukturerad metod för att aktivera TLS 1.3 och dra tillbaka svagare konfigurationer med minimala tjänsteavbrott) och hantering av certifikatlivscykeln via CertSecure Manager (automatisering av identifiering, förnyelse och policytillämpning för TLS-certifikat, inklusive det kommande kravet på 47 dagars livslängd för certifikat). Våra PKI-tjänster täcker även infrastrukturen för certifikatutfärdare som utfärdar TLS-certifikat, vilket säkerställer att förtroendekedjan är korrekt utformad och styrd.

Slutsats

TLS är det grundläggande protokollet som säkrar data som överförs över internet. TLS 1.3 är den nuvarande standarden: snabbare än TLS 1.2, obligatorisk forward secrecy, krypterad handskakning och inget bagage från äldre algoritmer. Organisationer bör omedelbart aktivera TLS 1.3 på alla servrar, inaktivera TLS 1.0 och 1.1 utan dröjsmål, endast hårdgöra TLS 1.2 till ECDHE-AEAD-sviterna under övergångsperioden och planera för pensionering av TLS 1.2 när analys av äldre klienter bekräftar att det inte längre behövs.

Certifikatdimensionen inom TLS-hantering intensifieras: 47-dagars certifikatlivslängder år 2029 kräver automatiserad livscykelhantering snarare än manuell spårning. Algoritmdimensionen förändras också: RSA-2048-certifikat föreslås utfasas efter 2030, vilket gör ECDSA P-256 till rätt val för all nyutfärdande av TLS-certifikat nu. För relaterat innehåll, se våra guider om att förstå ECC- och SSL/TLS-certifikat.

Vanliga frågor om partihandel med mat och dryck

Vad är TLS och vad skyddar det?

TLS är ett kryptografiskt protokoll som tillhandahåller konfidentialitet, integritet och autentisering för nätverksdata. Det skyddar data från avlyssning (kryptering), manipulering (integritet via AEAD) och personifiering (servercertifikatautentisering via CA). Används i HTTPS, SMTP, IMAP, API-trafik, databasanslutningar och VPN-protokoll.

Vad är skillnaden mellan TLS 1.2 och TLS 1.3?

TLS 1.3 är snabbare (1-RTT vs 2-RTT), kräver framåtriktad sekretess via ECDHE, tillåter endast 5 AEAD-chiffreringssviter (jämfört med hundratals i TLS 1.2 inklusive svaga), krypterar mer av handskakningen och tar bort alla äldre algoritmer (RC4, 3DES, RSA-nyckelutbyte, CBC, komprimering) som var attackvektorer i TLS 1.2.

Vilka krypteringssviter ska användas med TLS 1.2?

NIST SP 800-52 Rev. 2 rekommenderar ECDHE-AEAD-sviterna: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 och TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 är att föredra. Inaktivera alla RSA-nyckelutbytessviter (ingen forward secrecy), alla RC4/DES/3DES-sviter, MD5/SHA-1-sviter och CBC-sviter där det är möjligt.

Vad är forward secrecy och varför kräver TLS 1.3 det?

Framåtriktad sekretess innebär att kompromettering av den långsiktiga privata TLS-nyckeln inte kan dekryptera tidigare sessioner, eftersom sessionsnycklarna var efemära. TLS 1.3 kräver detta via ECDHE för alla anslutningar. Utan framåtriktad sekretess (TLS 1.2 RSA-nyckelutbyte) kan en angripare som registrerar dagens trafik dekryptera den retroaktivt om de senare får tag på den privata nyckeln.

Hur bör organisationer migrera från TLS 1.2 till TLS 1.3?

Aktivera TLS 1.3 på alla servrar tillsammans med TLS 1.2 (inte istället för det). Inaktivera omedelbart TLS 1.0 och 1.1. Härda TLS 1.2 endast till ECDHE-AEAD-sviterna. Övervaka TLS-protokolldistributionen i åtkomstloggar. Planera att TLS 1.2 tas ur bruk när övervakningen visar minimal användning av aktiva klienter.

Vilka attacker påverkar TLS 1.2 och är de åtgärdade i TLS 1.3?

BEAST-, POODLE- och liknande attacker utnyttjade TLS 1.2:s stöd för CBC-chiffreringssviter och svaga algoritmer. TLS 1.3 tar bort CBC-chiffreringssviter helt och hållet, vilket eliminerar dessa attackklasser. Raccoon riktade in sig på DHE; TLS 1.3 använder endast ECDHE. CRIME utnyttjade komprimering; TLS 1.3 tar bort komprimering. TLS 1.3 är inte immun mot implementeringsbrister men eliminerar de sårbara primitiver som möjliggjorde de flesta kända attacker på protokollnivå.