De wereld komt eraan TLS 1.3, wat een heel goede zaak is! Dit artikel biedt een overzicht op hoog niveau van TLS 1.3, en een discussie over de effectiviteit van de nieuwe functies.
Transport Layer Security
Transport Layer Security, of TLS, is een cryptografisch protocol dat gegevens beschermt die via een computernetwerk worden uitgewisseld. TLS is beroemd geworden als de S in HTTPS. Specifieker, TLS wordt gebruikt om gegevens van webgebruikers te beschermen tegen netwerkaanvallen.
TLS is ontworpen als een veiliger alternatief voor zijn voorganger Secure Sockets Layer (SSL) In de loop der jaren hebben beveiligingsonderzoekers enorm veel kwetsbaarheden ontdekt die van invloed zijn op SSL, wat IETF motiveerde om te ontwerpen TLS in een poging ze te verzachten.
Ironisch genoeg, eerdere versies van TLS werden ook getroffen door gevaarlijke kwetsbaarheden, wat uiteindelijk leidde tot TLS 1.2 (dwz de standaardversie die wordt aanbevolen door professionals in de branche).
Het merendeel van de bekende protocolkwetsbaarheden is verholpen in TLS 1.2, maar dit beveiligingsniveau was nog steeds het resultaat van een reeks patches bovenop een gebrekkig ontwerp.
Als reactie TLS 1.3 is helemaal opnieuw opgesteld in een poging een modern en veilig ontwerp te ontwerpen TLS protocol. Vijf jaar later testen is het eindelijk goedgekeurd en is het nu bijna de standaard internetbeveiligingsstandaard.
TLS versies en hun respectievelijke RFC-documenten zijn te vinden in de onderstaande lijst:
- TLS 1.0 werd gepubliceerd als RFC 2246 in 1996
- TLS 1.1 werd gepubliceerd als RFC 4346 in 2006
- TLS 1.2 werd gepubliceerd als RFC 5246 in 2008
- TLS 1.3 is gepubliceerd als voorgestelde standaard in RFC 8446 in 2018.
Hoe ouder TLS versies werken?
Om de voordelen van effectief te bespreken TLS 1.3, we moeten eerst praten over hoe ouder TLS versies werken (en hoe ze niet werken).
TLS is een hybride cryptosysteem, wat betekent dat het beide gebruikt asymmetrisch (openbare sleutel) en symmetrisch (op wachtwoord / zin gebaseerde) codering. Dit is te wijten aan asymmetrische cryptografie ordes van grootte langzamer zijn dan zijn symmetrische equivalenten.
Bijgevolg TLS gebruikt alleen openbare sleutels, zodat clients en servers veilig een symmetrische sleutel kunnen uitwisselen. Deze sleutel kan vervolgens worden gebruikt om alle daaropvolgende communicatie te versleutelen, waardoor de overheadkosten die door asymmetrische versleuteling worden opgelegd, worden vermeden.
TLS 1.2 ondersteunt meerdere algoritmen voor sleuteluitwisseling (bijv. RSA, DH, etc.), samen met verschillende algoritmen (ook bekend als cijfers) gebruikt om berichten te versleutelen en ontsleutelen. Dit grote aantal alternatieve opties vereist dat klanten en servers onderhandelen, zodat alle partijen hetzelfde gebruiken TLS parameters.
Deze onderhandeling is gestandaardiseerd in een protocol genaamd handdruk. Als u er niet bekend mee bent, raadpleeg dan dit artikel voor meer informatie.
Dus wat is er mis met TLS 1.2?
Hoewel TLS Het is bewezen dat 1.2 in de meeste gevallen prima werkt, er zijn zorgen over het algehele niveau van beveiliging en privacy dat het biedt na jaren van patchen en revisies.
Afgezien van veiligheidsoverwegingen, TLS 1.2 legt ook onnodige prestaties en netwerkoverhead op.
TLS 1.2 beveiligingsproblemen
Door de jaren heen hebben onderzoekers (en aanvallers) bij velen een hele reeks kwetsbaarheden ontdekt TLS 1.2 componenten, inclusief algoritmen voor sleuteluitwisseling, cijfers en digitale handtekeningen. Sommige hiervan waren implementatiebugs waarvan je misschien wel eens hebt gehoord, zoals heartbleed or BERserk. Sommige waren echter kwetsbaar voor protocollen, dat wil zeggen dat ze misbruik maken van eerdere slechte ontwerpbeslissingen TLS versies (dwz eerder TLS 1.2).
Hoewel de meeste implementatie- en andere bugs waren opgelost TLS 1.2, helaas kunnen de kwetsbaarheden in het protocolontwerp niet worden verholpen met alleen een softwarepatch. Het bleek dat IETF daarvoor het handshake-protocol volledig opnieuw moest ontwerpen TLS 1.3.
Er zijn veel zorgen over geweest TLS beveiliging, maar een van de meest impactvolle was het besef dat TLS 1.2 (en alle eerdere versies, inclusief SSL) is kwetsbaar voor downgrade-aanvallen vanwege een fout in het handshake-protocolontwerp. Specifieker, TLS 1.2 gebruikt geen digitale handtekeningen om de integriteit van de handdruk te beschermen. Handtekeningen beschermen een deel van de handdruk, alleen na onderhandeling over de coderingssuite.
Dientengevolge kunnen aanvallers elke onderhandeling van derden over cijfersuites die in hetzelfde computernetwerk plaatsvindt (bijv. Wifi op luchthavens) manipuleren en het gebruik van een onveilig cijfer afdwingen. Ze kunnen dan dat kwetsbare cijfer doorbreken en ongerechtvaardigde toegang krijgen tot het hele gesprek.
TLS 1.2 prestatieproblemen
Naast deze beveiligingsoverwegingen, TLS 1.2's behoefte om tal van te onderhandelen TLS parameters kunnen een prestatieoverhead opleggen aan HTTPS (of andere TLS beveiligde) communicatie.
TLS 1.2's 4-staps handshake vereist twee retouruitwisselingen, eerst om de cijferreeks te selecteren en vervolgens om de certificaten en symmetrische sleutels (of sleutelaandelen) uit te wisselen.
Dit betekent dat voor iedereen TLS verbinding tot stand brengen, twee extra transacties met de server zijn vereist. Als gevolg, TLS verbindingen vereisen meer bandbreedte en stroom dan (niet-versleutelde) HTTP, wat bijzonder kostbaar kan zijn voor Internet-of-Things (IoT) -toepassingen, waar een laag stroomverbruik en bandbreedteverbruik harde beperkingen zijn.
TLS 1.2 privacykwesties
Tenslotte TLS 1.2 is bekritiseerd omdat het de privacy van webgebruikers schaadt.
Meer specifiek, TLS biedt een extensie bekend als Indicatie servernaam of SNI. Met SNI kan de hostnaam van een server worden opgenomen in de initiële SSL-handshake. Deze extensie wordt gebruikt voor virtuele hosting, waarbij servers meerdere domeinen op hetzelfde IP-adres en dezelfde poort kunnen bedienen, terwijl voor elk domein een ander certificaat wordt gepresenteerd.
In TLS 1.2, SNI's worden verzonden ongecodeerde, dus ondanks het gebruik van HTTPS kan een netwerkaanvaller deze informatie lekken en de webpagina's volgen die een gebruiker bezoekt.
Hoe werkt TLS 1.3 alles repareren?
TLS 1.2 (en eerdere versies) waren gericht op het behouden van achterwaartse compatibiliteit. Elke versie bouwde voort op de vorige met kleine revisies die probeerden tussen de gepubliceerde kwetsbaarheden te elimineren TLS versies.
Dit betekende helaas ook dat slechte ontwerpbeslissingen over het protocol (bijv. De onbeschermde handdruk) ook werden overgenomen in de nieuwere versies.
TLS 1.3 laat achterwaartse compatibiliteit los ten gunste van een goed beveiligingsontwerp. Het is helemaal opnieuw ontworpen om functionaliteit te bieden die vergelijkbaar is (maar niet compatibel) met TLS 1.2, maar met aanzienlijk verbeterde prestaties, privacy en beveiliging.
TLS 1.3-beveiliging
Een kernprincipe van TLS 1.3 is eenvoud. In de nieuwe versie zijn alle algoritmen voor sleuteluitwisseling, behalve de Diffie-Hellman (DH) sleuteluitwisseling, zijn verwijderd. TLS 1.3 heeft ook een set beproefde DH-parameters gedefinieerd, waardoor het niet meer nodig is om met de server te onderhandelen over parameters.
Wat nog meer, TLS 1.3 ondersteunt niet langer onnodige of kwetsbare cijfers, zoals CBC-modus en het RC4-cijfer. Deze cijfers staan bekend als vatbaar voor aanvallen, maar werden in de meeste gevallen nog steeds ondersteund TLS implementaties voor legacy compatibiliteit. Gelukkig heeft de recente stormloop van downgrade-aanvallen vroegtijdige gevolgen TLS versies motiveerden IETF om dergelijke cijfers volledig te verwijderen TLS 1.3.
Daarnaast, TLS 1.3 vereist dat servers de volledige handdruk cryptografisch ondertekenen, inclusief de onderhandeling over de codering, die voorkomt dat aanvallers handdrukparameters wijzigen. Dit betekent dat TLS 1.3 is architectonisch ongevoelig voor de eerdere downgrade-aanvallen TLS versies.
Ten slotte zijn ook de handtekeningen zelf verbeterd door het implementeren van een nieuwe standaard, genaamd RSA-PSS. RSA-PSS-handtekeningen zijn immuun voor cryptografische aanvallen die de eerder gebruikte handtekeningschema's beïnvloeden TLS versies.
TLS 1.3-prestaties
Naast verbeterde beveiliging, de gereduceerde set parameters en de vereenvoudigde handdruk TLS 1.3 draagt ook bij aan het verbeteren van de algehele prestaties. Aangezien er maar één algoritme voor sleuteluitwisseling is (met ingebouwde parameters) en slechts een handvol ondersteunde cijfers, is de absolute bandbreedte die nodig is om een TLS 1.3 kanaal is aanzienlijk minder dan eerdere versies.
Voorts TLS 1.3 ondersteunt nu een nieuw handshake-protocol, genaamd 1-RTT-modus. In 1-RTT kan de client DH-sleutelshares verzenden in het eerste handshakebericht, omdat het vrij zeker kan zijn van de parameters die de server zal gebruiken. In het zeldzame geval dat de server ze niet ondersteunt, kan dit een fout veroorzaken waardoor de client een andere configuratie zal sturen.
In plaats van eerst over de parameters te onderhandelen en vervolgens sleutels of sleutelaandelen uit te wisselen, TLS 1.3 stelt een klant in staat om een TLS kanaal met slechts één retourtransactie (in plaats van twee, zoals eerder werd gedaan). Dit kan een groot cumulatief effect hebben op de verwerkings-, stroom- en netwerkbronnen die een client nodig heeft om met een server te communiceren via TLS 1.3.
Prestatie-optimalisaties stoppen hier echter niet, met een andere TLS 1.3 functie, genaamd de 0-RTT-hervattingsmodus. Wanneer een browser voor het eerst een server bezoekt en met succes een TLS handdruk, kunnen zowel de client als de server een vooraf gedeelde coderingssleutel lokaal opslaan.
Als de browser de server opnieuw bezoekt, kan hij deze hervattingssleutel gebruiken om gecodeerde toepassingsgegevens in zijn eerste bericht naar de server te sturen. Dit heeft dezelfde latentie als niet-versleutelde HTTP, omdat initiële handshakes niet vereist zijn.
Opgemerkt moet worden dat er enige beveiliging is geweest zorgen over 0-RTT-modus in het verleden.
TLS 1.3 privacy
Leren van fouten uit het verleden, TLS 1.3 biedt nu een uitbreiding die SNI-informatie versleutelt. Bij correct gebruik voorkomt deze extensie dat aanvallers de domeinnaam van de externe server lekken, zodat ze geen methode hebben om HTTPS-gebruikersgeschiedenis bij te houden. Deze functie biedt internetgebruikers meer privacy dan eerdere versies van TLS.
Conclusie
Terwijl TLS 1.2 heeft al die jaren eervol gediend, TLS 1.3 is aantoonbaar veiliger en efficiënter. TLS 1.3 is uitgebreid getest in experimentele browserimplementaties en is nu klaar om te vervangen TLS 1.2 als het gekozen netwerkbeveiligingsprotocol. Publiceren TLS 1.3 is een grote stap dichter bij een sneller en veiliger internet voor iedereen.
Bedankt voor het kiezen van SSL.com, waar wij geloven dat veiliger Internet is een beter Internet.
