Världen rör sig till TLS 1.3, vilket är mycket bra! Den här artikeln ger en översikt på hög nivå TLS 1.3, och en diskussion om effektiviteten hos de nya funktionerna.
Transport Layer Security
Transportlagers säkerhet, eller TLS, är ett kryptografiskt protokoll som skyddar data som utbyts via ett datornätverk. TLS har blivit känd som S in HTTPS. Mer specifikt, TLS används för att skydda webbanvändardata från nätverksattacker.
TLS designades som ett säkrare alternativ till föregångaren Secure Sockets Layer (SSL). Under åren har säkerhetsforskare upptäckt massor av sårbarheter som påverkar SSL, vilket motiverade IETF att designa TLS i ett försök att mildra dem.
Ironiskt nog, tidigare versioner av TLS påverkades också av farliga sårbarheter, vilket i slutändan ledde till TLS 1.2 (dvs standardversionen rekommenderas av branschfolk).
Majoriteten av de kända protokollsårbarheterna dämpades TLS 1.2, men denna säkerhetsnivå var fortfarande resultatet av en serie lappar ovanpå en felaktig design.
Som ett svar, TLS 1.3 utarbetades från grunden i ett försök att rent utforma ett modernt och säkert TLS protokoll. Fem års test senare har den äntligen godkänts och är nu nära att vara standardsäkerhetsstandarden för Internet.
TLS versioner och deras respektive RFC-dokument finns i listan nedan:
- TLS 1.0 publicerades som RFC 2246 i 1996
- TLS 1.1 publicerades som RFC 4346 i 2006
- TLS 1.2 publicerades som RFC 5246 i 2008
- TLS 1.3 publicerades som föreslagen standard i RFC 8446 i 2018.
Hur äldre TLS versioner fungerar?
För att effektivt diskutera fördelarna med TLS 1.3, måste vi först prata om hur äldre TLS versioner fungerar (och hur de inte fungerar).
TLS är en hybrid kryptosystem, vilket betyder att det använder båda asymmetrisk (offentlig nyckel) och symmetrisk (lösenord / frasbaserad) kryptering. Detta beror på asymmetrisk kryptografi är storleksordningar långsammare än dess symmetriska ekvivalenter.
Följaktligen, TLS använder bara offentliga nycklar så att klienter och servrar säkert kan utbyta en symmetrisk nyckel. Den här nyckeln kan sedan användas för att kryptera all efterföljande kommunikation och undvika prestandakostnaderna som påförs genom asymmetrisk kryptering.
TLS 1.2 stöder flera nyckelutbytesalgoritmer (t.ex. RSA, DH, etc.), tillsammans med flera algoritmer (även känd som chiffer) som används för att kryptera och dekryptera meddelanden. Denna stora mängd alternativa alternativ kräver att kunder och servrar ska förhandla, så att alla parter använder samma sak TLS parametrar.
Denna förhandling är standardiserad i ett protokoll som heter handskakning. Om du inte är bekant med det, vänligen hänvisa till den här artikeln för mer information.
Så vad är fel med TLS 1.2?
Även TLS 1.2 har visat sig fungera bra i de flesta fall, det finns oro för den totala säkerhetsnivån och integriteten som den ger efter många års patchning och revideringar.
Bortsett från säkerhetshänsyn, TLS 1.2 innebär också onödig prestanda och nätverkskostnader.
TLS 1.2 säkerhetsproblem
Under åren har forskare (och angripare) upptäckt en mängd sårbarheter hos många TLS 1.2 komponenter, inklusive nyckelutbytesalgoritmer, chiffer och digitala signaturer. Några av dessa var implementeringsfel som du kanske har hört talas om, till exempel heartbleed or Bärsärk. Vissa var dock protokollsårbarheter - det vill säga de utnyttjar dåliga designbeslut tidigare TLS versioner (dvs. tidigare TLS 1.2).
Även om majoriteten av implementeringen och andra buggar fixades i TLS 1.2, tyvärr kan sårbarheterna i protokolldesignen inte åtgärdas med bara en programvarupatch. Som det visar sig, måste IETF göra om handskakningsprotokollet helt igenom TLS 1.3.
Det har varit många farhågor om TLS säkerhet, men en av de mest påverkande var insikten att TLS 1.2 (och alla tidigare versioner, inklusive SSL) är sårbara för nedgraderingsattacker på grund av en brist i designen för handskakningsprotokoll. Mer specifikt, TLS 1.2 använder inte digitala signaturer för att skydda handskakningen. Signaturer skyddar en del av handskakningen, först efter chiffer-förhandlingen.
Som en följd av detta kan angripare manipulera alla tredjeparts chiffer-förhandlingar som inträffar i samma datornätverk (t.ex. flygplats wifi) och tvinga användningen av ett osäkert chiffer. De kan sedan bryta det sårbara chifferet och få orättvis åtkomst till hela konversationen.
TLS 1.2 prestationsproblem
Förutom dessa säkerhetshänsyn, TLS 1.2 behöver förhandla många TLS parametrar kan införa en prestandakostnad på HTTPS (eller annat TLS skyddad) kommunikation.
TLS 1.2: s 4-stegs handskakning kräver två tur och retur-utbyten, först för att välja krypteringssvit och sedan för att utbyta certifikat och symmetriska nycklar (eller nyckeldelar).
Detta betyder att för alla TLS anslutning som ska upprättas, två ytterligare transaktioner med servern krävs. Som ett resultat, TLS anslutningar kräver mer bandbredd och effekt än (okrypterad) HTTP, vilket kan vara särskilt kostsamt för Internet-of-Things (IoT) -applikationer, där låg effekt och bandbreddförbrukning är hårda begränsningar.
TLS 1.2 sekretessproblem
Slutligen, TLS 1.2 har kritiserats för att äventyra sekretess för webbanvändare.
Mer specifikt, TLS erbjuder en tillägg känd som Servernamnindikering eller SNI. SNI tillåter att värdnamnet på en server inkluderas i den första SSL-handskakningen. Denna tillägg används för virtuell värd, där servrar kan betjäna flera domäner på samma IP-adress och port, samtidigt som de presenterar ett annat certifikat för varje domän.
In TLS 1.2, SNI skickas okrypterad, så trots användning av HTTPS kan en nätverksangripare läcka denna information och spåra webbsidorna som en användare besöker.
Hur fungerar TLS 1.3 fixa allt det?
TLS 1.2 (och tidigare versioner) fokuserade på att upprätthålla bakåtkompatibilitet. Varje version bygger på de tidigare med mindre revisioner som försöker eliminera sårbarheter publicerade mellan TLS versioner.
Tyvärr innebar detta också att dåliga protokolldesignbeslut (t.ex. det oskyddade handskaket) också ärvdes i de nyare versionerna.
TLS 1.3 överger kompatibilitet bakåt till förmån för en korrekt säkerhetsdesign. Det har utformats från grunden för att tillhandahålla funktioner som liknar (men är inte kompatibla) till TLS 1.2, men med avsevärt förbättrad prestanda, integritet och säkerhet.
TLS 1.3-säkerhet
En grundläggande princip om TLS 1.3 är enkelhet. I den nya versionen är alla nyckelutbytealgoritmer, förutom Diffie-Hellman (DH) nyckelbyte avlägsnades. TLS 1.3 har också definierat en uppsättning testade DH-parametrar, vilket eliminerar behovet av att förhandla om parametrar med servern.
Vad mer, TLS 1.3 stöder inte längre onödiga eller sårbara chiffer, t.ex. CBC-läge och RC4-chiffer. Det är känt att dessa chiffer är mottagliga för attacker, men stöttes fortfarande i de flesta TLS implementeringar för äldre kompatibilitet. Lyckligtvis den senaste tidens rusa av nedgraderingsattacker som drabbar TLS versioner motiverade IETF att helt ta bort sådana cifrar från TLS 1.3.
Dessutom, TLS 1.3 kräver servrar att kryptografiskt underteckna hela handskakningen, inklusive chifferförhandling, vilket förhindrar angripare från att ändra eventuella handskakningsparametrar. Detta innebär att TLS 1.3 är arkitektoniskt ogenomträngligt för nedgraderingsattackerna som drabbade tidigare TLS versioner.
Slutligen förbättrades själva signaturerna genom att implementera en ny standard, kallad RSA-PSS. RSA-PSS-signaturer är immun mot kryptografiska attacker som påverkar de signaturprogram som använts tidigare TLS versioner.
TLS 1.3-prestanda
Förutom förbättrad säkerhet, den reducerade uppsättningen av parametrar och den förenklade handskakningen TLS 1.3 bidrar också till att förbättra den totala prestanda. Eftersom det bara finns en nyckelutbytealgoritm (med inlagda parametrar) och bara en handfull stödda ciprar, krävs den absoluta bandbredden för att ställa in en TLS 1.3-kanalen är betydligt mindre än tidigare versioner.
Dessutom, TLS 1.3 stöder nu ett nytt handskakningsprotokoll, kallat 1-RTT-läge. I 1-RTT kan klienten skicka DH-nyckelandelar i det första handskakningsmeddelandet, eftersom det kan vara ganska säkert av parametrarna som servern kommer att använda. I det sällsynta fallet att servern inte stöder dem kan den ge ett fel så att klienten skickar en annan konfiguration.
Istället för att förhandla fram parametrarna först och sedan byta ut nycklar eller nyckelandelar, TLS 1.3 tillåter en klient att ställa in en TLS kanal med endast en tur-retur-transaktion (istället för två, som tidigare gjordes). Detta kan ha en stor kumulativ effekt i processerna för behandling, ström och nätverk som krävs för att en klient ska kommunicera med en server över TLS 1.3.
Prestandaoptimeringar slutar dock inte här, med en annan TLS 1.3-funktion, kallad 0-RTT återupptagningsläge. När en webbläsare besöker en server för första gången och fullbordar en TLS handskakning kan både klienten och servern lagra en fördelad krypteringsnyckel lokalt.
Om webbläsaren besöker servern igen kan den använda denna återupptagningsnyckel för att skicka krypterad applikationsdata i sitt första meddelande till servern. Detta har samma latens som okrypterad HTTP, eftersom initiala handskakningar inte krävs.
Det bör noteras att det har varit viss säkerhet oro ungefär 0-RTT-läge tidigare.
TLS 1.3 integritet
Att lära av tidigare misstag, TLS 1.3 erbjuder nu en förlängning som krypterar SNI-information. När den används korrekt förhindrar denna tillägg angripare att läcka fjärrservern domännamn, så de har ingen metod för att spåra HTTPS-användarhistorik. Den här funktionen ger internetanvändare större integritet än tidigare versioner av TLS.
Slutsats
Medan TLS 1.2 har tjänat hederligt alla dessa år, TLS 1.3 är sannolikt säkrare och effektivare. TLS 1.3 har testats omfattande i experimentella webbläsarimplementeringar och är nu redo att ersättas TLS 1.2 som valfritt nätverkssäkerhetsprotokoll. publicering TLS 1.3 är ett stort steg närmare ett snabbare och säkrare internet för alla.
Tack för att du valde SSL.com, där vi tror a säkrare Internet är en bättre Internet.
