Internet Engineering Task Force brengt TLS 1.3 uit

De Internet Engineering Task Force heeft de ontwikkeling aan TLS 1.3 afgerond. De nieuwe versie van het beveiligingsprotocol bevat enkele nieuwe functies en sommige verouderde onderdelen zijn weggehaald.

De volledige lijst met veranderingen is te vinden op de website van de IETF. Een van de grootste veranderingen in het protocol is dat de handshake tussen de gebruiker en de server compacter is gemaakt, zodat er minder onversleutelde data wordt uitgewisseld. Een andere grote verandering is dat het concept van forward secrecy nu verplicht is, zodat oudere berichten niet kunnen worden gedecodeerd als een wachtwoord uitlekt. Cipher suites die dit niet ondersteunen, zijn niet langer toegestaan.

Andere aanpassingen zijn het verwijderen van enkele verouderde algoritmen waarvan misbruik gemaakt kon worden, en een 0-RTT-modus ofwel zero round-trip time, waarbij de cliënt en server niet voor elk bericht opnieuw geverifieerd hoeven te worden. Dit bespaart data ten koste van enkele beveiligingsfuncties. De verdwijning van bepaalde algoritmen heeft te maken met de eis van authenticated encryption, die in versie 1.3 is geïntroduceerd. Ook het bekende md5-hashingalgoritme is niet langer ondersteund.

Dat TLS 1.3 af is, betekent niet dat het meteen overal geïmplementeerd is. Daarvoor moet de ondersteuning eerst bij zowel de servers als de gebruikers worden doorgevoerd. Wanneer dit gebeurt, merkt de eindgebruiker waarschijnlijk weinig tot niets van de overstap.

Reacties (58)

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]

"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".

Als je er vanuit gaat dat je geen optimalisaties doorgevoerd hebt als tls session resumption en false start (waarbij het aantal benodigde roundtrips gereduceerd kan worden tot 2, waarbij in de laatste roundtrip al applicatiedata wordt uitgewisseld).

Correct me if im wrong

Met session resumption heb je inderdaad maar 1-RTT, maar dat werkt alleen als je eerder al contact hebt gehad met de server. Daarnaast kan het zijn dat sommige omgevingen met hoge veiligheidseisen session resumption uitschakelen. In TLS 1.2 en eerder is de "master secret" die wordt gebruikt voor de eerste sessie gelijk aan de "master secret" die wordt gebruikt voor de tweede sessie (met session resumption). Wanneer een van de twee sessies de "master secret", dan is het verkeer van de andere sessie ook gecompromitteerd. In TLS 1.3 is de "master secret" voor het versleutelen van het verkeer anders dan de "resumption secret" en is dus geen probleem. (Referenties: RFC 5246 - F.1.4, RFC 5077.)

TLS False Start kan onder veel voorwaarden gebruikt worden in TLS 1.2 en inderdaad het aantal roundtrips terugbrengen, maar zelfs onder die omstandigheden bleek het in de praktijk niet altijd te werken over het Internet vanwege "middleboxes" (firewalls, en dergelijke) die niet wisten wat ze ermee aan moesten. Daarop heeft Google afgezien van deze optimalisatie.

Hoe lang zou het nou ongeveer gaan duren voordat de meerderheid standaard gebruikt maakt van TLS1.3 nu dat dit uitgebracht is?

[Reactie gewijzigd door Yooo Kerol op 26 maart 2018 00:34]

Dat 0-RTT is best wel boeiend omdat het potentiëel veiligheidsproblemen met zich meebrengt! Zie voor info mijn reactie hier:
afraca in 'nieuws: Internet Engineering Task Force brengt TLS 1.3 uit'

Naast browsers is er nog genoeg andere software dat via het internet communiceert. Alle libraries/frameworks die daarvoor gebruikt worden moeten ook uitgebreid worden.

Bij een .NET-applicatie, met als target .NET 4.0, moet je bijvoorbeeld zelf regelen dat je HTTP requests via TLS1.2 mogen, standaard is alleen SSL3.0 en TLS1.0 ingeschakeld. Pas vanaf 4.6 wordt standaard ook geprobeerd via TLS1.1 en TLS1.2 te verbinden.

Browsers en andere clients moeten ook nog ondersteuning krijgen natuurlijk, Firefox en Edge hebben het nog niet, Chrome al wel, de stabiele versies van deze browsers.

Firefox heeft al wel (experimentele?) TLS 1.3 ondersteuning. Dat kan je aanzetten in about:config:
security.tls.version.max;4

Als je daarna een SSL test doet zal je zien dat TLS 1.3 ondersteund wordt. Bijvoorbeeld via:
https://www.ssllabs.com/ssltest/viewMyClient.html

Protocols
TLS 1.3 Yes

[Reactie gewijzigd door Rudie_V op 25 maart 2018 11:27]

Ik heb Firefox 60 (op het beta kanaal) en bij mij staat dat standaard aan. Een beetje zoeken leert mij dat het plan oorspronkelijk was om het standaard aan te zetten voor Firefox 52 in April vorig jaar maar dat daar op het laatst vanaf is gezien omdat er toch nog wat compatibiliteitsissues bleken te zijn. Kennelijk komen die issues inmiddels minder voor.

Tot aan firefox 59.0.1 staat het nog standaard uit. Misschien omdat TLS1.3 nu final is dat men het ook standaard aan gaat zetten, wat ik begreep waren er wat compatibiliteitsproblemen met de verschillende drafts van TLS1.3 en dat het daarom niet standaard aan is gezet, voor zover ik het goed begrepen heb.
Zie bijvoorbeeld: https://bugzilla.mozilla.org/show_bug.cgi?id=1310516

Chrome kan ook nog niet de complete implementatie hebben, als het net klaar is!

Tuurlijk kan dat wel. Als er al een tijdje een draft beschikbaar is, Chrome deze implementeert en de draft zonder wijzigingen final wordt zou dit prima kunnen.

Er zijn in totaal 28 drafts geweest, maar velen zijn niet geïmplementeerd door alle partijen. Chrome en Firefox zaten voor een jaar op draft 18, en de meest recente (developer?) versies draaien draft 22 of 23.

Versies 26-28 kwamen in enkele dagen na elkaar uit en waren niet zo spannend, alleen maar verduidelijkingen.

Als je echt de stand van zaken wilt weten, dan is er een lijst van implementaties en de ondersteunde (draft) versies van TLS 1.3: https://github.com/tlswg/tls13-spec/wiki/Implementations

Dat kan zeker wel.

Er komen vaak eerst een aantal drafts, die dan getest en geaudit moeten worden. In de tussentijd kan je die alvast implementeren.

Als er dan wijzigingen gemaakt moeten worden, maak je die, zo niet, dan heb je hem af voordat hij vrijgegeven is.

Bij wireless N bijvoorbeeld, zag je dat er al veel hardware op de markt was die een draft ondersteunde, voordat de standaard af was. Omdat er geen grote wijzigingen waren, waren die compatibel met de gewone N devices.

Nou, ik heb meegemaakt dat netwerk apparaten draft versies geïmplementeerd hadden en alleen met eigen merk werkten
Draft is en blijft draft totdat de final er is. En of die in dit geval gelijk is, ik lees in een andere post van niet. Ik bedoel maar.

Drafts wijzigen inderdaad. De reactie van .Peter is informatief hierover.

T.o.v. een eerste draft is er vanzelfsprekend veel gewijzigd. T.o.v. een laatste draft niet of nauwelijks. Maar als je up to date blijft met alle drafts, zal de final niks nieuws bevatten.

Natuurlijk ligt dit bij hardware anders. Ik heb draft-N devices die het nu nog prima doen met een moderne AC router. Maar eerdere devices kunnen inderdaad niet compatibel zijn.

Browsers en andere clients moeten ook nog ondersteuning krijgen natuurlijk,

En serversoftware.

Uit het artikel:

Webmasters moeten het protocol daarvoor eerst actief in hun eigen software verwerken.

Webmasters hebben hier niets mee te maken. Serverbeheerders zijn in de praktijk de laatste kritieke stap, omdat zij (handmatig) nieuwere versies van serversoftware moeten installeren en de configuratie aan moeten passen. Browsers updaten zichzelf, dus die ondersteuning komt vanzelf wel voor de massa.

[Reactie gewijzigd door The Zep Man op 25 maart 2018 11:25]

De vraag is dan welke server OS het zullen ondersteunen.
Mainstream support voor Windows 2012R2 eindigt op 9-10-2018.
Ik neem aan dat MS het nog voor 2012R2 (en nieuwer) zal ondersteunen.

Laat een heel groot deel van de wereld op Linux icm Apache of Nginx draaien en daar kan TLS1.3 al aan

Google eens op "Server OS market share".

Dan zie je inderdaad dat hij gelijk heeft:

https://news.netcraft.com...17-web-server-survey.html

1) Er is nog een enorm verschil tussen "all sites" en "active sites". Active sites zijn sites die niet parked or placeholder zijn. Er draaien dus veel in-active sites op Windows (GoDaddy is bijvoorbeeld een van de oorzaken)
2) De stats betreffen alleen public web servers. Achter de publiek toegankelijke webservers zitten nog veel meer andere servers.

Verder zget Snow_King "een heel groot deel", is natuurlijk ruimte voor interpretatie, maar ook al zou MS 51% van de server markt in handen hebben dan is "slechts" 49% nog steeds een groot deel.

Foute keuze, je moet zoeken achter het marktaandeel van webservers.

Waarom? TLS is niet alleen bedoeld voor HTTPS...

Snow_King heeft gelijk: de meeste web servers draaien een vorm van nginx en/of Apache, vaak onder Linux.

Het is ook niet slim om de SSL/TLS stack onlosmakelijk met het OS te verweven. Gelukkig is er ook voor Windows Server een workaround. Zo kan je ook onder Windows nginx gebruiken. Al heb je een webapplicatie die IIS nodig heeft, dan kan je nginx als reverse proxy en TLS offloader gebruiken. Zo kan je ook TLS 1.3 krijgen.

[Reactie gewijzigd door The Zep Man op 25 maart 2018 13:45]

Zal vast binnenkort wel toegevoegd worden aan schannel.

Ik verwacht van niet eigenlijk. Server 2003 zat nog ruim in de ondersteuning en kreeg geen ondersteuning voor TLS1.1 en TLS1.2.

De versie van TLS 1.3 in Chrome is een door Google aangepaste versie van een oud voorstel.
Er zijn wijzigingen aangebracht in de specificaties na implementatie door Google. Dus ik ga er niet zo maar vanuit dat Google Chrome werkt met deze versie van TLS 1.3. Hoogstwaarschijnlijk zal Google een nieuwe update uit moeten brengen om hun eigen implementatie volledig compliant te maken met de /voorgestelde/ standaard.

"Dat TLS 1.3 af is, betekent niet dat het meteen overal geïmplementeerd is. Webmasters moeten het protocol daarvoor eerst actief in hun eigen software verwerken."

Is dit een correcte beschrijving van hoe dat werkt?

Nope, is inderdaad wat vreemd geformuleerd. De pakketmakers (zoals Apache, nginx en de browser boeren) moeten het implementeren. En vervolgens moet de webmaster (of systeembeheerder) de webserver updaten. En als de eindgebruiker dan ook zijn browser update, kan iedereen TLS 1.3 met elkaar praten.

De serverbeheerder moet mogelijk ook de configuratie aanpassen na de upgrade.

In praktijk gebruiken de meesten gewoon de default instelling. Als die upgraden dan krijgen ze vanzelf ook TLS1.3

Mbt clients heb je waarschijnlijk gelijk, maar mijn apache virtualhosts heb ik toch geconfigureerd aan de hand van Qualys en andere testsuites, hoor. Ik mag er niet aan denken dat je met Debian stable moet wachten op de volgende versie opdat je ciphers worden vernieuwd...

TLS 1.3 is een ingrijpende verandering, veel meer dan 1.0 -> 1.1 -> 1.2. Apache op Debian stable (stretch) gebruikt OpenSSL 1.1.0 terwijl OpenSSL 1.1.1 (nog in beta) vereist is voor TLS 1.3. Verwacht maar niet dat de huidige Debian versie standaard TLS 1.3 gaat ondersteunen.

Debian is het probleem niet. Debian heeft een relatief korte lifecycle.
Zelfs bij operating systems met een lange lifecycle, bijvoorbeeld Windows en Red Hat, wordt het probleem wel opgelost doordat er veel mensen actief bezig zijn met het backporten van bugfixes en essentiele features.
De problemen zullen er vooral zijn met goedkope apparaatjes die verkocht worden en waarvan de fabrikant geen firmware updates uitbrengt.

Thanks, nu klopt de wereld weer

nginx heeft al sinds begin vorig jaar TLSv1.3 support. Dit toen ook getest en was al functioneel met een aanpassing in Chrome. Technisch is dit allemaal niet zo spannend, maar client support is hierbij erg belangrijk en dat het natuurlijk uit de draft fase is.

[Reactie gewijzigd door Tombastic op 25 maart 2018 16:00]

Vergeet niet dat ook pakketten zoals OpenSSL of LibreSSL bijgewerkt moeten worden.

En firewall-, load balancer-, mail appliances-, etc- fabrikanten de libraries nog moeten updaten. Het gaat jaren duren voordat 1.3 gemeengoed is.

[Reactie gewijzigd door kr4t0s op 25 maart 2018 20:49]

Daarnaast is het nog afwachten of men geen steken heeft laten vallen die het nieuwe protocol onverwacht kwetsbaar maken, dus voorlopig zal 1.2 nog wel de standaard blijven.

Ik vind dat het aantal ondersteunde symmertric ciphers in TLS drastisch moet worden ingeperkt, tot slechts 2 stuks. Dit zouden dan AES-256, waar veelal hardware ondersteuning is op zowel desktop als mobiele processoren, en Chacha20, als fallback op kleinere processoren, moeten zijn.

Ik heb het idee dat er zoveel ondersteunde algoritmen en protocollen zijn dat er te makkelijk fouten kunnen insluipen, wat de veiligheid niet ten goede komt.

De cipher suites in TLS 1.2 kunnen niet gebruikt worden in TLS 1.3. In TLS 1.3 kun je nu alleen maar AES (128/256-bit keys in GCM/CCM/CCM mode) en ChaCha20 gebruiken.

TLS 1.2 en TLS 1.3 delen wel dezelfde ruimte voor nummering, maar kunnen niet door elkaar gebruikt worden.. Zie ook https://tools.ietf.org/ht...tls-tls13-28#appendix-B.4

Daar ben ik het niet mee eens, ik vind het wel prettig dat we een paar opties hebben want ook met een klein aantal algoritmes zullen er foutjes gemaakt worden. Of, erger nog, iedere vorm van encryptie kan fundamentele fouten bevatten. We hebben geen manier om dat te voorkomen anders dan dat een hoop wetenschapper en hackers heel hard proberen om een fout te vinden. Dat ze nog niks gevonden hebt betekent niet dat er geen fouten zijn.
Daarom vind ik het noodzakelijk om wat extra's achter de hand te hebben voor het geval we plots zo'n algoritme moeten uitschakelen. Het zou niet de eerste keer zijn.

Wat dat betreft was het ook hoog tijd voor TLS 1.3. TLS 1.0 en 1.1 zijn eigenlijk al afgeschreven waarmee we momenteel eigenlijk alleen TLS1.2 hebben. Als daar een fout in gevonden zou worden dan was er eigenlijk geen alternatief meer. Nu hebben we in ieder geval TLS1.3.

De stable versies van OpenSSL hebben ook nog geen v1.3 aan boord, daarvoor moet je zelf builden vanaf een development source (correct me if I'm wrong), dus veel server software zal het nog niet ondersteunen zolang dit niet het geval is.

OpenSSL 1.1.1 (nu beta1) is gereserveerd voor TLS1.3 en had heeft net als veel andere pakketten al ondersteuning voor de drafts. Firefox, Chrome en NGINX hebben dat ook gedaan. LibreSSL loopt een beetje achter, maar omdat het een fork van OpenSSL is zal dat ook niet lang duren. De draft support gebruikte 0x07 als versie nummer ipv 0x0304 dus nummertje veranderen en OpenSSL is klaar ... dan duurt het natuurlijk nog een tijdje voordat de distributies zijn bijgewerkt.

Hoe weet je nou dat een password uilekt? (ben volkomen noob op dit gebied)

Het artikel is verwarrend, het gaan niet om wachtwoorden die uitlekken, maar de privesleutel van de server. Wanneer een server wordt voorzien van een certificaat, dan hoort er ook nog een privesleutel bij (twee bestanden in totaal). In sommige configuraties is het mogelijk dat door middel van alleen deze privesleutel het verkeer kan worden ontcijfert.

Het uitlekken van de privesleutel kan komen door onzorgvuldigheid (ik heb meegemaakt dat op een shared hosting server de privesleutel door elke gebruiker op de server te lezen was, maar het kan ook zijn dat een oude backup per ongeluk uitlekt) of software fouten (Heartbleed).

Dank voor de uitleg

Een wachtwoord zou op last van een rechter vrijgegeven kunnen worden.

Is perfect forward secrecy nu standaard? Want bij TLS 1.2 kon het ook al, alleen was het een hoop extra werk om in te stellen. Het artikel is hier niet zo duidelijk over.

Ja, TLS 1.3 ondersteunt alleen maar cipher suites met forward secrecy, RSA sleutels worden nu alleen maar gebruikt voor authenticatie en niet meer voor encryptie van een premaster secret (aan de hand daarvan kan een hele sessie worden decrypted).

Mozilla heeft een mooi tooltje gemaakt waarbij het updaten naar de laatste security settings van je webserver/reverse-proxy een koud kustje wordt: https://mozilla.github.io...tls/ssl-config-generator/

en een 0-RTT-modus ofwel zero round-trip time, waarbij de cliënt en server niet voor elk bericht opnieuw hoeven te verifiëren. Dit bespaart data ten koste van enkele beveiligingsfuncties.

Je voelt al op je klompen dat dit mis zal gaan.

Er is een erg leuke discussie hierover op HackerNews, want dat is inderdaad best wel een tricky situatie! Zie: https://news.ycombinator.com/item?id=16667036
Cloudflare heeft bijv een interessante beschrijving over hoe ze dit deel wat eigenlijk onveilig is toch implementeren op een manier dat de veiligheid het minst in het geding komt: "Specifically, only GET requests with no query parameters are answered over 0-RTT. " (https://blog.cloudflare.com/introducing-0-rtt/)