Förstå TLS 1.2 och TLS 1.3 

Som ni vet överförs känsliga uppgifter som personlig information, finansiella transaktioner och affärskommunikation via internet, och det är nödvändigt att säkra dem. Att säkerställa att dessa uppgifter är skyddade från avlyssning, manipulering eller obehörig åtkomst är en utmaning som TLS-protokollet (Transport Layer Security) utformades för att hantera. TLS skapades 1999 av Internet Engineering Task Force (IETF). TLS hänvisar till ett kryptografiskt protokoll som skapats för att tillhandahålla säker kommunikation över ett datornätverk.

Det garanterar att data som överförs mellan en klient och en server är krypterad och gör det svårt för obehöriga att läsa eller ändra informationen. TLS bygger på SSL 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 POODLE och BEAST. Det introducerar också funktioner som forward secrecy och sessionsåterupptagning. Syftet är att ge ett säkrare sätt att skydda onlinekommunikation. 

Äldre versioner av TLS, såsom TLS 1.0 och TLS 1.1, hade säkerhetsbrister som gjorde dem sårbara för attacker. Dessa brister kunde göra det möjligt för angripare att stjäla känsliga uppgifter som kreditkortsuppgifter, lösenord eller annan personlig information. Till exempel kunde vårdgivare som använde dessa föråldrade protokoll göra patientjournaler sårbara för obehörig åtkomst och utsätta privata medicinska historier för risk. Det är därför TLS behövde ständiga förbättringar för att göra det starkare, säkrare och mer tillförlitligt för att säkra onlinekommunikation. Senare introducerades TLS 1.2 och TLS 1.3. Det förbättrade säkerheten genom att använda starkare kryptering, åtgärda sårbarheter och förbättra prestanda för en säkrare onlineupplevelse. 

National Institute of Standards and Technology (NIST) föreskriver att alla myndigheters TLS-servrar och klienter måste stödja TLS 1.2 konfigurerat med FIPS-kompatibla krypteringssviter. Dessutom krävs stöd för TLS 1.3 från och med den 1 januari 2024. Detta direktiv beskrivs i detalj i NIST. Specialpublikation 800-52 Revision 2. 

TLS 1.2 och dess handskakning 

TLS 1.2 är en version av TLS-protokollet som tillhandahåller säker kommunikation över internet. Det introducerades i augusti 2008 som en del av IETF:s RFC 5246Det utformades för att åtgärda begränsningarna och sårbarheterna i tidigare versioner som TLS 1.0 och TLS 1.1. Detta protokoll används ofta för att säkra aktiviteter, inklusive internetbank, e-postkommunikation och filöverföringar. Jämfört med tidigare versioner introducerade det starkare krypteringsalgoritmer, bättre prestanda och förbättrade säkerhetsfunktioner. 

TLS 1.2-handskakningen upprättar en säker anslutning mellan en klient och en server genom två meddelandeutbyten eller rundresor (2-RTT).  

• Det börjar med att klienten skickar ett "Client Hello"-meddelande, vilket inkluderar dess stödda TLS-versioner, chiffersviter, ett slumpmässigt nummer för generering av krypteringsnycklar och ett valfritt sessions-ID för att återuppta en tidigare session.  
• Servern svarar med ett ”Server Hello” genom att välja en TLS-version och chiffer-svit från listan som anges i meddelandet ”client Hello”, med ett eget slumptal och ett signerat certifikat med sin publika nyckel. Om klienten inkluderade ett sessions-ID söker servern efter en cachad session. Annars genererar den ett nytt sessions-ID. Efter att ha skickat ett ”Server Hello”-meddelande väntar servern på att klienten ska fortsätta. 
• Klienten validerar sedan serverns certifikat för att säkerställa att det är betrott av en certifikatutfärdare. Om ömsesidig autentisering krävs, till exempel i företagsmiljöer, begär servern en klient certifikatKlienten skickar sitt certifikat, vilket valideras av servern med hjälp av en betrodd certifikatutfärdare. Detta bekräftar klientens identitet. 
• Offentlig nyckelkryptografi används i handskakningsprocessen för att säkert utbyta sessionsnyckeln, vilket garanterar konfidentialitet. När autentiseringen är klar skickar klienten ett "Key Exchange"-meddelande med en pre-master-nyckel krypterad med serverns publika nyckel. Även om en angripare fångar upp meddelandet kan de inte dekryptera pre-master-nyckeln utan serverns privata nyckel. Endast servern kan dekryptera denna nyckel eftersom den privata nyckeln som motsvarar den publika nyckeln lagras säkert på servern och kryptografiska enheter som – Hårdvarusäkerhetsmodul (HSM) och nyckelvalv och överförs aldrig. Både klienten och servern använder denna pre-masternyckel och deras slumptal för att generera en delad masterhemlighet. Sedan används den delade masterhemligheten för att generera sessionsnycklar. 
• Slutligen utbyter klienten och servern meddelanden som ”Ändra krypteringsspecifikation” och ”Klar”. Det bekräftar att de är redo att byta till symmetrisk kryptering med sessionsnyckeln. Från och med denna punkt är all kommunikation säkert krypterad, och sessionsnycklarna gäller bara under sessionens varaktighet.

Viktiga funktioner i TLS 1.2 

TLS 1.2 medförde flera förbättringar för säker kommunikation över datornätverk. Viktiga funktioner inkluderar: 

• Förbättrad hashalgoritm

  Kombinationen av MD5 och SHA-1 som användes i den färdiga meddelandehashen ersattes med säkrare alternativ som SHA-256 och SHA-384. Den färdiga meddelandehashen måste dock fortfarande vara minst 96 bitar stor.

• AES Cipher Suites

  TLS 1.2 introducerad Advanced Encryption Standard (AES) krypteringssviter, som erbjuder starkare krypteringsalternativ genom att stödja 128-bitars och 256-bitars nycklar. Det skyddar också data under överföring och bidrar till förbättrad säkerhet överlag.

• Stöd för autentiserad kryptering

  TLS 1.2 utökade stödet för autentiserade krypteringschiffer, särskilt Galois/Counter Mode (GCM) och Counter with CBC-MAC (CCM)-lägen i AES. Det ger bättre dataintegritet och konfidentialitet. 

• Förbättrad klient- och serverförhandling

  Både klienter och servrar kan ange acceptabla hash- och signaturalgoritmer under handskakningsprocessen, vilket ökar flexibiliteten och säkerheten. Detta säkerställer kompatibilitet samtidigt som det minskar sårbarheter i samband med föråldrade eller svaga algoritmer. Om till exempel en specifik algoritm blir osäker (t.ex. SHA-1) kan klienter och servrar välja starkare alternativ som SHA-256 eller SHA-384.

TLS 1.3 och dess handskakning 

TLS 1.3 är den senaste versionen av TLS-protokollet och är utformad för att förbättra säkerhet och prestanda jämfört med sin föregångare. TLS 1.3 introducerades officiellt i augusti 2018 med publiceringen av RFC 8446 av IETF. Protokollet är ett resultat av det ökande behovet av starkare kryptering, snabbare anslutningsinställningar och förbättrade sekretessfunktioner. TLS 1.3 introducerade stora förbättringar inom säkerhet, hastighet och sekretess. Det effektiviserade handskakningsprocessen, tog bort svagare kryptografiska algoritmer och förbättrade krypteringsmetoder. Dessa förändringar ger ett säkrare och effektivare kommunikationsramverk för moderna internetprotokoll. 

TLS 1.3-handskakningsprocessen sker på bara en tur och retur (1-RTT), vilket gör den snabbare än tidigare versioner. Den minskade latensen hos 1-RTT i TLS 1.3 är viktig för branscher som kräver realtidskommunikation. Inom onlinespel ger det smidigt spelande med mindre fördröjning. Livestreamingplattformar är beroende av snabba anslutningar för att leverera innehåll utan avbrott. Finansiella applikationer, inklusive internetbank och handel, drar nytta av snabbare transaktionshastigheter. Dessutom behöver röst- och videokommunikationsplattformar, som VoIP och videokonferenser, låg latens för sömlösa interaktioner. 

• Det börjar med att klienten skickar ett "Client Hello"-meddelande. Detta meddelande innehåller viktig information som vilken version av TLS som klienten stöder (i det här fallet TLS 1.3), listan över chiffersviter och nyckelutbytesmetoder som den stöder, ett slumptal som genereras av klienten och eventuella extra tillägg som klienten vill inkludera. Klienten skickar sitt certifikat om klientautentisering är aktiverad. Servern kan validera detta certifikat mot listan över betrodda certifikatutfärdare. Detta bevisar att klienten är legitim. 
• Som svar genererar servern huvudhemligheten med hjälp av slumptalet "ClientHello", sitt eget genererade slumptal, klientparametrar och valda krypteringssviter. Servern skickar sedan ett "Server Hello"-meddelande tillsammans med ett "Server Finished"-meddelande. Detta inkluderar protokollversionen som valts av servern, krypteringssviterna, nyckelutbytesmetoden, det servergenererade slumptalet, SSL/TLS-certifikatoch eventuella valfria parametrar. 
• När klienten tar emot serverns svar verifierar den serverns certifikat mot sin lista över betrodda CA för att säkerställa att den kommunicerar med den legitima servern. Klienten genererar en huvudhemlighet med hjälp av sitt slumptal och informationen från servern. Därefter skickar både klienten och servern ett "Klart"-meddelande för att bekräfta att de är redo för säker kommunikation. Vid denna tidpunkt delar både klienten och servern samma hemlighet och kan börja utbyta data säkert med hjälp av kryptering för att skydda sin kommunikation. 

Viktiga funktioner i TLS 1.3 

TLS 1.3 introducerar flera viktiga funktioner som förbättrar säkerhet, hastighet och effektivitet jämfört med tidigare versioner. 

• 0-RTT-data

  TLS 1.3:s 0-RTT-datafunktion (Zero Round-Trip Time) gör det möjligt för klienter att skicka data under handskakningen, vilket minskar latensen vid anslutningsupprättande. Detta är fördelaktigt för realtidsapplikationer som videostreaming och spel. I sådana applikationer är snabb anslutningsupprättning avgörande för smidiga användarupplevelser. Det kan också vara användbart i scenarier där upprepade anslutningar till samma server sker, till exempel i IoT-enheter som ofta återansluter till en central server. Det är dock sårbart för replay-attacker och bör användas försiktigt i känsliga scenarier där replay-attacker effektivt kan förhindras. Detta är ett problem eftersom 0-RTT-data inte skyddas av samma sessionsnycklar som resten av kommunikationen.

• Eliminerar RSA-nyckelutbytet

  I TLS 1.3, den RSA-baserade nyckelutbyte Metoden har tagits bort till förmån för starkare metoder som ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), vilket ger bättre säkerhet och prestanda.

• Sekretess framåt

  Det är en viktig säkerhetsfunktion i TLS 1.3 och säkerställer att sessionsnycklarna aldrig överförs eller lagras över nätverket och kasseras när sessionen avslutas. Även om en servers privata nyckel komprometteras i framtiden förblir tidigare kommunikation säker och kan inte dekrypteras. Denna funktion skyddar långsiktig kommunikation genom att säkerställa att varje session krypteras oberoende med unika sessionsnycklar som genereras för den specifika sessionen och förhindrar att kompromettering av en nyckel påverkar sekretessen för tidigare data.

Jämförelse mellan TLS 1.2 och TLS 1.3 

Övergången från TLS 1.2 till TLS 1.3 representerar ett betydande språng när det gäller säkerhet, prestanda och protokolleffektivitet. Nedan följer en tabelljämförelse som presenterar de viktigaste skillnaderna mellan TLS 1.2 och TLS 1.3. 

Leverans	TLS 1.2	TLS 1.3	Utmaningar
Handskakningsprocess	Två tur- och returtider (2-RTT).	En tur- och returresa (1-RTT).	Hög latens i TLS 1.2 och TLS 1.3:s 0-RTT-data ökar risken för replay-attacker om de inte implementeras på ett säkert sätt.
Cipher sviter	Stöder ett brett utbud av chiffersviter, inklusive svagare.	Endast AEAD-krypteringssviter (Authenticated Encryption with Associated Data) är tillåtna, vilket säkerställer starkare säkerhet.	Äldre system som förlitar sig på svagare krypteringssviter kräver uppdateringar för TLS 1.3-kompatibilitet.
Nyckelutbyte	Stöds för RSA, DHE och ECDHE.	Endast ECDHE stöds.	Borttagning av RSA och DHE i TLS 1.3 komplicerar integrationen för system som förlitar sig på dessa metoder.
Framåtsekretess	Frivillig.	Obligatorisk och framåtriktad sekretess tillämpas som standard.	Äldre system som inte är konfigurerade för framåtriktad sekretess behöver omkonfigureras, vilket potentiellt ökar migreringsinsatserna.
Krypteringsalgoritmer	Inkluderar föråldrade algoritmer som RC4 och CBC.	Kräver starkare algoritmer som AES-GCM och ChaCha20-Poly1305.	Övergången från föråldrade algoritmer kräver uppdatering av bibliotek och applikationer.
Session återupptas	Använder sessions-ID:n eller sessionsbiljetter för återupptagning.	Stöder återupptagning av sessioner med 0-RTT-data, vilket minskar latensen.	TLS 1.3:s 0-RTT-data riskerar replay-attacker, medan sessionsbiljetter i TLS 1.2 kanske inte hanteras säkert.
Säkerhetsförbättringar	Sårbar för attacker som BEAST, POODLE och Heartbleed.	Förbättrad säkerhet med krypterade handskakningsmeddelanden och eliminerar osäkra protokoll.	Att migrera säkert kräver att man identifierar och minskar sårbarheter i äldre TLS-versioner.
Validering av certifikat	Stöder certifikatvalidering men kan exponera vissa handskakningsdetaljer.	Säkrare, eftersom handskakningsmeddelanden är krypterade.	Att uppdatera befintlig infrastruktur för att hantera krypterade handskakningar utan kompatibilitetsproblem är avgörande.
0-RTT-data	Stöds inte.	Stödde och tillät att data skickades under handskakningen (men var mottaglig för replay-attacker).	0-RTT-data riskerar att utsättas för replay-attacker och kräver noggrann validering och begränsad användning endast i känsliga scenarier.
Prestanda	Långsammare på grund av 2-RTT-handskakning och ytterligare bearbetningssteg.	Snabbare tack vare en effektiv handskakning och optimerat nyckelutbyte.	Nätverk med hög latens drar större nytta av TLS 1.3, men implementeringen måste säkerställa korrekt stöd för optimerat flöde.

TLS 1.3 anses allmänt vara ett bättre protokoll jämfört med TLS 1.2 på grund av flera viktiga förbättringar inom säkerhet, prestanda och effektivitet. För det första förbättrar TLS 1.3 säkerheten genom att eliminera föråldrade och sårbara algoritmer (RC4, DES, MD5 och SHA1) och genom att tillämpa framtida sekretessDet gör att tidigare kommunikation förblir säker även om en servers privata nyckel senare komprometteras. Samtidigt stöder TLS 1.2 svagare kryptografiska metoder och kräver inte framåtriktad sekretess. När det gäller prestanda erbjuder TLS 1.3 en snabbare anslutningsuppsättning genom att reducera handskakningsprocessen till bara en tur-retur-tid (1-RTT), jämfört med de två eller flera RTT:er som krävs av TLS 1.2. Denna snabbare handskakning förbättrar latensen avsevärt, särskilt för applikationer som onlinespel.

Dessutom minskar TLS 1.3 beräkningskostnaden genom att förenkla protokollet, då det effektiviserar nyckelutbytesprocessen genom att använda Ephemeral Diffie-Hellman och eliminerar behovet av separata nyckelutbytesmekanismer som RSA, vilka användes i TLS 1.2. Denna minskning av komplexiteten förbättrar inte bara effektiviteten utan minskar också risken för implementeringsfel. TLS-versioner före 1.3 stödde komprimering, men den här funktionen var sårbar för attacker. I TLS 1.3 tas komprimeringen bort genom att skicka en nullbyte i fältet legacy_compression_methods. Dessa faktorer gör TLS 1.3 till det föredragna valet för modern, säker och effektiv webbkommunikation. 

Från och med maj 2024, en skanning av Qualys SSL Labs visar att TLS 1.2 fortsätter att ha en bred användning. Det betyder att 99.9 % av webbplatserna stöder version 1.2, medan TLS 1.3 används av 70.1 % av webbplatserna, en ökning från 67.5 % i januari 2024. Den ständiga ökningen av TLS 1.3-användningen återspeglar dess förbättrade säkerhet och minskade latens, vilket gör det till det föredragna valet för moderna applikationer.  

Att migrera från TLS 1.2 till TLS 1.3 innebär flera betydande utmaningar. Många äldre system och enheter är inkompatibla med TLS 1.3 och kan kräva kostsamma uppgraderingar eller utbyten för att stödja det nyare protokollet. Detta kan vara särskilt svårt för branscher som är starkt beroende av äldre infrastruktur. TLS 1.3 tar bort vissa kryptografiska funktioner, såsom RSA-nyckelutbyte, vilket tvingar organisationer att omkonfigurera system för att använda säkrare metoder som Elliptic Curve Diffie-Hellman Ephemeral-nyckelutbyte. Detta kan störa applikationer som är beroende av algoritmer som inte längre stöds av det nya protokollet. 

TLS 1.3 introducerar förändringar i handskakningsprocessen och mekanismerna för återupptagande av sessioner. Dessa förändringar kräver uppdateringar av applikationslogiken, särskilt i system med komplexa autentiserings- eller anslutningsflöden. Testning och validering blir avgörande för att garantera att migreringen inte stör befintliga arbetsflöden eller leder till prestandaproblem. Dessa utmaningar kräver betydande tid, ansträngning och samordning mellan IT-team för att tillhandahålla kompatibilitet och smidig integration. 

sårbarheter  

Även om TLS 1.2 och TLS 1.3 kan mildra många av riskerna som är förknippade med deras föregångare, är inget protokoll helt perfekt, och båda har sina sårbarheter. TLS 1.2 kräver inte användning av MD5 eller SHA-1, men stöder dem för bakåtkompatibilitet. Protokollet tillåter deras användning om en server eller klient uttryckligen väljer dem. TLS 1.2, även om det är allmänt antaget, är sårbart på grund av sitt stöd för svagare kryptografiska algoritmer som MD5 och SHA-1. Dessa är benägna att utsättas för kollisioner och brute force. attacker.  

TLS 1.2 har utnyttjats genom olika uppmärksammade attacker som riktar sig mot dess sårbarheter. BEAST-attacken (Browser Exploit Against SSL/TLS) utnyttjade svagheter i Cipher Block Chaining-läget och gjorde det möjligt för angripare att dekryptera delar av avlyssnad krypterad trafik. På liknande sätt gjorde Heartbleed-sårbarheten i OpenSSLs implementering av TLS det möjligt för angripare att extrahera känslig information, som privata nycklar och sessionsdata, från serverminne med hjälp av skadliga heartbeat-förfrågningar. POODLE-attacken (Padding Oracle on Downgraded Legacy Encryption) utnyttjade brister i utfyllnad i CBC-läge och utnyttjade scenarier där servrar stödde reservfunktioner till mindre säkra protokoll som SSL 3.0. 

Dessutom riktar sig Raccoon-attacken mot Diffie-Hellman-nyckelutbytesprocessen genom att använda tidsbaserade sidokanaltekniker för att mäta små variationer i beräkningstiderna för nyckelutbytet. Detta kan göra det möjligt för angripare att återställa delar av sessionsnyckeln och äventyra kommunikationens sekretess. Att upprätthålla bakåtkompatibilitet och stark säkerhet är svårt. 

TLS 1.3 åtgärdar många av dessa svagheter genom att ta bort föråldrade kryptografiska algoritmer och förenkla handskakningsprocessen, men den är inte helt immun mot implementeringsspecifika sårbarheter. Dessa sårbarheter uppstår ofta på grund av hur olika bibliotek, servrar eller applikationer implementerar protokollet. Till exempel kan brister uppstå om nonces – slumptal eller initialiseringsvektorer (IV) – som används för att initiera vissa krypteringsalgoritmer som CBC eller AES-GCM – är inte korrekt randomiserade. Det kan leda till förutsägbara krypteringsmönster som kan utnyttjas. Felaktig hantering av nyckelutbytesmekanismer kan exponera privata nycklar om parametrarna är svaga eller återanvänds. Felkonfigurationer, som att välja svaga krypteringssviter eller att inte korrekt konfigurera forward secrecy, kan också minska säkerheten. 

För att minska riskerna i samband med TLS 1.3-implementeringsspecifika sårbarheter är det viktigt att säkerställa användningen av starka kryptografiska parametrar. Konfigurationer som att välja elliptiska kurvor av hög kvalitet, använda säker nyckelrotation, korrekt generering av slumpmässiga tal och undvika svaga eller föråldrade krypteringssviter som RC4 och DES är avgörande. Det är också avgörande att inaktivera reservfunktioner till äldre protokoll som TLS 1.2 eller SSL, vilka kan exponera sårbarheter. Regelbundna patchar och uppdateringar av TLS-bibliotek bör prioriteras för att åtgärda nyupptäckta brister. Detaljerade säkerhetsrevisioner och kontinuerlig sårbarhetsskanning är avgörande för att upptäcka felkonfigurationer, svaga nycklar eller föråldrade komponenter och säkerställa att TLS 1.3-implementeringar förblir säkra och uppdaterade. 

Ocuco-landskapet NIST har uppmärksammat en sårbarhet i Cisco Firepower Threat Defence (FTD)-programvarans TLS 1.3-policy med URL-kategorifunktionalitet, vilket kan göra det möjligt för oautentiserade angripare att kringgå konfigurerade URL-blockeringspolicyer. Denna situation orsakas av ett logiskt fel i Snorts hantering av TLS 1.3-anslutningar och kan utnyttjas med hjälp av specialutformade TLS 1.3-förfrågningar. Det ger åtkomst till begränsade URL:er som vanligtvis skulle blockeras.  

Hur kan krypteringskonsultation hjälpa till?

På Encryption Consulting hjälper vi organisationer att hantera utmaningarna med att övergå från TLS 1.2 till TLS 1.3 genom att erbjuda skräddarsydda krypteringslösningar. Dessa lösningar hjälper till att möta våra kunders unika säkerhetsbehov. Vårt team av högkvalificerade experter erbjuder ett brett utbud av tjänster, inklusive djupgående bedömningar, granskningar, strategiplanering och implementering av en smidig migreringsprocess. Vi hjälper kunder att identifiera kompatibilitetsproblem, konfigurera stöd för dubbla protokoll och optimera krypteringsinställningar för att förbättra säkerheten. Genom att erbjuda personlig vägledning under hela övergången säkerställer vi att migreringen till TLS 1.3 överensstämmer med kundens specifika säkerhetsmål samtidigt som vi minimerar risker och störningar. 

Slutsats 

TLS är viktigt för att skydda data när de överförs över nätverk. Det använder kryptering med offentlig nyckel och en handskakning process för att säkra kommunikationen mellan klienter och servrar. Medan TLS 1.2 fortfarande används flitigt eftersom det fungerar bra med många system, blir TLS 1.3 alltmer populärt. Detta beror på att TLS 1.3 erbjuder snabbare anslutningar, bättre säkerhet och en enklare design. Det minskar fördröjningar, gör webbplatser snabbare och förbättrar användarupplevelsen. Det tar också bort svaga funktioner och åtgärdar sårbarheter från tidigare versioner, vilket gör det mycket svårare för hackare att utnyttja.

Organisationer som övergår från TLS 1.2 till TLS 1.3 bör först bedöma sin infrastruktur för kompatibilitet och säkerställa att kritiska system stöder det nya protokollet. En etappvis strategi bör vidtas, där TLS 1.3 initialt aktiveras i en testmiljö och föråldrade protokoll tas bort. Säkerhetsteam bör utbildas i bästa praxis för TLS 1.3, och bakåtkompatibilitet med TLS 1.2 bör upprätthållas tillfälligt tills fullständig migrering har uppnåtts. Bakåtkompatibilitet krävs under migreringsperioden eftersom det säkerställer att system och klienter som ännu inte stöder TLS 1.3 fortfarande kan kommunicera säkert med hjälp av TLS 1.2. Detta garanterar att användare och tjänster fortsätter att fungera smidigt under övergången samtidigt som avbrott minskas. 

Utan bakåtkompatibilitet riskerar organisationer att bryta anslutningar med äldre system, enheter eller klienter som förlitar sig på äldre protokoll, vilket kan leda till avbrott i tjänsten eller säkerhetsproblem. Dessutom är regelbundna tester och sårbarhetsbedömningar avgörande under hela processen. TLS 1.3 är inte direkt bakåtkompatibel med TLS 1.2, vilket innebär att den inte kan användas direkt med system som förlitar sig på äldre versioner av TLS. På grund av detta rekommenderas företag att stödja båda versionerna under övergången. Denna metod säkerställer säkra datatransaktioner för äldre system samtidigt som den möjliggör implementering av det förbättrade och säkrare TLS 1.3-protokollet för nyare applikationer och webbplatser.