Even wat verduidelijkingen op het artikel:
De handshake is compacter gemaakt zodat er met minder latency (1-RTT i.p.v. 2-RTT) een veilige sessie tot stand kan worden gebracht. Voorheen moesten er vier berichten heen en weer, met TLS 1.3 volstaat het om twee berichten heen en weer te sturen waarna informatie veilig uitgewisseld kan worden. Dit staat los van de wijziging waardoor meer onderdelen van de handshake versleuteld is. Onder andere het certificaat is nu niet meer onversleuteld te zien, maar het domeinnaam (SNI) waarmee je verbindt is nog wel zichtbaar.
Dat TLS 1.3 forward secrecy heeft is niet nieuw, dit kon ook al in TLS 1.2. Het nieuwe is er onder geen enkele mogelijkheid nog verouderde cipher suites gebruikt kunnen worden, simpelweg omdat de oude cipher suite definities niet in TLS 1.3 passen vanwege technische redenen. Voorheen kon je de cipher suite definities uit SSL 3.0 bijvoorbeeld gewoon gebruiken in TLS 1.2 wat soms voor onveilige situaties zorgen. Dit betekende dat server beheerders dus ook per ongeluk een verkeerde configuratie kunnen hebben, maar dat is dus verleden tijd wanneer
alleen TLS 1.3 is ingeschakeld. (Wanneer TLS 1.2 of ouder is ingeschakeld, dan kan de software dus worden geforceerd om die oude versie te gebruiken en ben je weer terug bij af.)
Forward secrecy heeft overigens niks met wachtwoorden te maken. Elke server heeft een certificaat ("hey, ik ben tweakers.net") dat een publieke RSA sleutel bevat. Met oudere cipher suites kon het zo zijn dat clients de "premaster secret" versleutelen met de publieke RSA sleutel van de server. De server (die dan toegang heeft tot een bijhorende unieke prive sleutel) kan dan de "premaster secret" gebruiken om de hele sessie te lezen. Wanneer deze prive sleutel (
geen wachtwoord!) uitlekt, dan kan echter iedereen al het verkeer uitlezen en aanpassen. Nieuwere cipher suites die van "Diffie-Hellman" gebruik maken hebben hier geen last van.
0-RTT modus zorgt ervoor dat een client (die eerder met de server contact heeft gehad) meteen met het eerste berichtje richting de server wat extra versleutelde data kan meesturen (denk aan een HTTP verzoek voor een pagina). Daarna volgt pas de
verificatie van de server identiteit (door middel van een certificaat) en uiteindelijk kunnen versleutelde berichten worden uitgewisseld. Voor deze berichten hoeft de identieit van de server niet natuurlijk niet opnieuw worden geverifieerd, maar dat wilt niet zeggen dat er geen verificatie van elk versleutelde bericht meer nodig is. Als onderdeel van het decrypten wordt een bericht automatisch geverifieerd. Ook is het niet zo dat er data wordt bespaard, het zorgt er simpelweg voor dat een verbinding sneller tot stand kan worden gebracht doordat er niet gewacht moet worden op een antwoord van de server voordat er versleutelde data verstuurd kan worden.
Overigens is het niet zo dat een groep eerst aan de specificatie werkt om daarna pas iedereen te overtuigen om deze standaard te implementeren. Ondertussen zijn er verschillende draft versies uitgekomen welke dus door onder andere door boringssl (voor Chrome) en NSS (voor Firefox) gebruikt worden. Een hele lijst van implementaties is hier te vinden:
https://github.com/tlswg/tls13-spec/wiki/Implementations
[Reactie gewijzigd door .Peter. op 25 maart 2018 13:37]