NCSC raadt bedrijven in nieuwe richtlijn aan over te stappen naar tls 1.3

Het Nationaal Cyber Security Centrum waarschuwt bedrijven over te schakelen naar tls 1.3. De instantie roept op hun leveranciers daarom te vragen. Tls 1.2 krijgt voortaan het veiligheidsniveau Voldoende.

Het NCSC heeft een update gepubliceerd voor de richtlijn voor het gebruik van Transport Layer Security, het protocol om verbindingen van bijvoorbeeld het web of e-mail te versleutelen. Versie 1.3 van tls is volgens de organisatie het veiligst en zou daarom door alle bedrijven gebruikt moeten worden voor interne systemen. Bedrijven die nieuwe software inkopen of een bestaand systeem vervangen kunnen dan naar de NCSC-richtlijnen verwijzen.

De reden van het nieuwe advies is dat het NCSC tls 1.2 heeft afgeschaald van veiligheidsniveau Goed naar Voldoende. "Het NCSC beschouwt tls 1.2 daarmee nog steeds als veilig, maar minder toekomstvaste optie dan tls 1.3", schrijft de instantie. Tls 1.3 is volgens het NCSC 'goed beschikbaar in recente versies van softwarebibliotheken', en bedrijven zouden met de ondersteuning beter voorbereid zijn op een'toekomstvaste configuratie'.

In tls 1.3 zitten enkele voordelen ten opzichte van tls 1.2. De nieuwe versie zou bijvoorbeeld minder kwetsbare configuratieopties bevatten, waardoor tls 1.3 makkelijker kan worden geconfigureerd op een veilige manier.

Reacties (35)

[Balance]

Hoewel TLS 1.2 nog een bredere ondersteuning heeft (98.24% van de gebruikers volgens Can I Use), ondersteunen alle grote browsers nu ook TLS 1.3 (Can I Use).

Enkel TLS 1.2

• Internet Explorer 11
• Opera Mini
• UC Browser for Android

TLS 1.2 en 1.3 (onder andere)

• Chrome 70+
• Firefox 63+
• Edge 79+
• Safari 12.1+ (op macOS 10.14 Mojave+)
• Safari op iOS 12.2+
• Opera 57+

Daarmee zijn 90.98% van de wereldwijde gebruikers van TLS 1.3 ondersteuning voorzien. In Westerse landen ligt dit vermoedelijk nog een stuk hoger.

[The Zep Man]

Daarmee zijn 90.98% van de wereldwijde gebruikers van TLS 1.3 ondersteuning voorzien.

TLS wordt voor meer gebruikt dan enkel voor browsers.

Zo wordt voor Android TLS 1.3 pas sinds Android 10 ondersteund, wat nu door maar ~43% van de Android markt gebruikt wordt.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:05]

[TheVivaldi]

Mooi lijstje! Alleen is het wel een beetje onduidelijk, want er staat "Opera Mini not supported", maar dat gaat over de oeroude Opera Mini voor o.a. op Java gebaseerde mobiletjes, terwijl Opera Mini voor Android wel degelijk tls 1.3 ondersteunt.

[bjv]

De browser is slechts 1 kant van het verhaal. Aan de andere kant van het lijntje heb je een server, en ook die moet TLS1.3 ondersteunen. Red Hat Enterprise Linux 7 bijvoorbeeld ondersteunt geen TLS1.3.
Nu weet ik dat RHEL7 niet de laatste versie is, maar hij is pas over 3.5 jaar EOL en nog volop in gebruik.

[Mellow Jack]

Ook daar zijn oplossingen voor

Het user device perspectief (bijv android ondersteuning) is relevant maar naar mijn mening behoeft een server gewoon een WAF (web application firewall). Dan hoeft het intern niet perse 1.3 te draaien

[Keypunchie]

Bij heel veel toepassingen en sectoren moet het interne verkeer ook versleuteld worden. En dat moet dan ook aan de standaarden voldoen.

Financiële data bijvoorbeeld, maar ook persoonsgegevens in het algemeen, geloof ik, mogen niet zomaar on- of slecht versleuteld over een intern netwerk worden geschoven.

Ondersteuning van TLS 1.3 is maar 1 deel van de puzzel. Het *uitschakelen* van verouderde standaarden is soms ook nog best lastig.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 08:05]

[Mellow Jack]

1.2 is nog voldoende dus dat is een beetje een non argument. Is precies wat ik zeg, buiten 1.3 en binnen iets minder maar toch voldoende. 1.2 is daar een optie en niet zo overdreven door gewoon niets te doen

[Donderr]

Bij Can I Use kun je de dekking in plaats van wereldwijd ook voor een land of regio inzien (via settings rechtsboven). Nederland zit dan voor TLS 1.3 op 92,81%. Bijna 2% hoger dan wereldwijd.

[mrcreatech]

Dat is allemaal leuk en aardig, maar er zijn nog ontzettend veel legacy devices die nooit een upgrade hebben gehad. Bijvoorbeeld televisies, die soms zelfs alleen TLS1.1 ondersteunen. Dus je als je daar apps op hebt draaien, kan je niet anders dan ook nog TLS1.1 en 1.2 aan te blijven bieden.

[CAPSLOCK2000]

Dat is allemaal leuk en aardig, maar er zijn nog ontzettend veel legacy devices die nooit een upgrade hebben gehad. Bijvoorbeeld televisies, die soms zelfs alleen TLS1.1 ondersteunen. Dus je als je daar apps op hebt draaien, kan je niet anders dan ook nog TLS1.1 en 1.2 aan te blijven bieden.

Nee hoor, je hebt ook de optie om je oude apparaat niet meer te gebruiken of een nieuw te kopen. Kwestie van prioriteiten. Ik snap dat dit een dure grap kan zijn maar dan let je deze keer hopelijk wel op dat je iets koopt dat kan worden onderhouden. Anders hebben we over drie jaar weer dit probleem.
Het is echt geen verassing dat software af en toe moet worden gemoderniseerd. Wie daar geen rekening mee houdt doet z'n werk niet goed. 20 jaar geleden was dat nog een vergeefbare fout, tegenwoordig niet meer.

En ja, dat is makkelijk praten, maar uiteindelijk is het wel de realiteit. Zolang we ons slap blijven opstellen tegen slechte software verandert er nooit iets. Gelukkig ligt er al een wetsvoorstel om dit verplicht te maken (https://www.rijksoverheid...cht-om-updates-te-leveren) zodat je niet met de leverancier in discussie hoeft over je recht op updates (in mijn ogen is dit grotendeels overbodig omdat we al recht op garantie hebben, maar daar is niet iedereen het over eens).
Snel doorvoeren dus.

[mrcreatech]

Ik snap zeker dat dit de realiteit is. Wat ik probeer te zeggen is dat zo'n advies er leuk is, maar dat je er nooit aan zult kunnen voldoen zolang er apparaten zijn die niet geupdate worden. In de televisiewereld kunnen we 5 jaar teruggaan en dan zijn er televisies die geen TLS1.3 ondersteunen, dat waarschijnlijk ook nooit gaan doen. De keuze om TLS1.3 dan niet de gaan forceren is dan snel gemaakt, als je weet dat gebruikers eens in de ~10 jaar of zelfs meer van televisie veranderen (waarbij de oude dan zelfs vaak naar de kinderkamer gaat). Om nog maar te spreken over de ecologische gevolgen als we inderdaad direct oude apparaten niet meer zouden gebruiken. Het beste is dan simpelweg dat er wetten moeten komen om verplichtingen te stellen over updates als deze.

[Ge Someone]

Ik had het wel verwacht, de "smart" functionaliteit van mijn TV nam na een paar jaar snel af (steeds minder apps werkten). De genade klap is (denk ik) geweest toen SHA256 niet ondersteund werd en destijds wel verplicht.
Ik heb de Internet kabel er inmiddels uit getrokken en gebruikt HDMI om toch zaken van Internet of de NAS te kunnen afspelen (via een ander device).

[Pikkemans]

Ik vind dan ook dat het aan een server beheerder is om te kijken naar het TLS gebruik voordat je een grote wijziging maakt mbt TLS versies die ondersteund worden. Je wilt toch van te voren weten wat de impact is van een wijziging op je webserver/loadbalancer.

[CAPSLOCK2000]

Ik vind dan ook dat het aan een server beheerder is om te kijken naar het TLS gebruik voordat je een grote wijziging maakt mbt TLS versies die ondersteund worden. Je wilt toch van te voren weten wat de impact is van een wijziging op je webserver/loadbalancer.

Natuurlijk moet je daar naar kijken, maar je moet ook kijken naar de gevolgen als je niet veranderd en dat wordt vaak vergeten. Iedereen heeft wel ergens een legacy device of gebruiker. Af en toe zal je die het slechte nieuws moeten brengen dat er moet worden geupgradet.
Het grootste risico van niet upgraden is natuurlijk dat je gehacked wordt, maar er zijn ook andere risico's die minder zichtbaar zijn.

Een punt dat veel mensen niet weten is dat Google de veiligheid van je website meetelt in de ranglijst. Als er twee identieke sites zijn die alleen verschillen in het gebruik van goede encryptie versus geen goede encryptie dan komt de site met goede encryptie hoger in de lijst te staan.

Een ander probleem dat vaak over het hoofd gezien wordt is dat stilstand zorgt voor opstapelend werk doordat je door de tijd heen steeds meer kunstgrepen moet uitvoeren om de oude situatie in stand te houden. Als er dan een keer gemoderniseerd wordt moet je heel veel in één keer veranderen en dat maakt verandering moeilijk.

Nog een voordeel van vroeg upgraden is dat als er problemen zijn met het nieuwe systeem je daar beter mee om kan gaan. Als de meeste van je gebruikers toch nog het oude protocol gebruiken dan zijn de gevolgen niet zo groot als er iets mis is met het nieuw protocol. Daarnaast heb je dan nog een fallback mogelijkheid en kun je bij proboemen terugvallen op het oude protocol. Als je tot het laatste moment wacht dan kun je niet meer terug als upgrade niet goed gaat.

Wat ook een rol speelt is dat kennis vaak maar een korte tijd actueel is. Op het moment dat "iedereen" met een upgrade bezig is dan is het makkelijk om kennis, informatie en hulp te krijgen. Als je te lang wacht dan is dat soort kennis weer weggezakt.

Nou ja, de kern van de zaak is dat we te vaak alleen maar naar de kosten en nadelen van een upgrade kijken, zeker als er geen handige nieuwe features zijn die iedereen wil. De kosten van niet upgraden kunnen ook heel fors zijn.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 08:05]

[Pikkemans]

Leuk feitje. De grootste cloud provider (AWS) ondersteund nog geen TLS 1.3 op zijn Application Loadbalancers.

[Noxious]

Microsoft IIS (webserver) ook nog niet. Het is pas sinds kort beschikbaar in test builds van Windows en het is maar de vraag of er nog support gaat komen in .NET Framework (tot nu toe enkel gelezen over .NET 5.0+).

[thof]

.NET Framework 4.7 ondersteund wel TLS 1.3. .NET Framework gebruikt de hoogst beschikbare versie van het TLS volgens het OS. Voor Windows wordt ondersteund TLS 1.3 sinds mei update van afgelopen jaar. Nog wel experimental, zie laatste link hier onder.

"Starting with .NET Framework 4.7, the default configuration is to use the OS TLS version."

Microsoft TLS 1.3 Support Reference:
https://devblogs.microsof...ls-1-3-support-reference/

Verzoek aan Microsoft om in Azure TLS 1.3 te ondersteunen voor web-apps:
https://feedback.azure.co...this-should-be-implemente

Windows support TLS 1.3:
nieuws: Microsoft schakelt tls 1.3 in bij testversie Windows 10

[Reactie gewijzigd door thof op 23 juli 2024 08:05]

[Noxious]

Ah dat is goed om te weten; maar dus nog niet bruikbaar op Server 2016/2019?

[VHware]

Correct. Alleen de rolling releases zegmaar (Windows Server, build 1903 en later), maar niet de officiële long-term support versie (Server 2016/2019)

[uiltje]

Ze hebben ook nog maar redelijk pas geleden GCM mode toegevoegd aan de .NET API, en dan nog redelijk summier. Microsoft loopt ook niet echt voorop met betrekking tot cryptografische algoritmen en protocollen, en dat is nog zacht uitgedrukt. Het sterke vermoeden is dat ze GCM ook maar hebben toegevoegd omdat ze TLS 1.3 wilden ondersteunen. We zullen het maar helemaal niet over de documentatie van de API hebben want die is bij tijd en wijlen ronduit beroerd.

AES-GCM wordt vaak gebruikt om de berichten in TLS te versleutelen, voor de mensen die dat nog niet wisten. Er is ook een stream cipher die gebruikt kan worden, maar die heeft geen hardware ondersteuning (AES-NI zijn specifieke processor instructies om AES snel & veilig uit te voeren).

[VHware]

Beter gezegd, algemeen Windows Server (2016, 2019) ondersteund het nog niet. Daar leunt o.a. IIS en vele andere applicaties op: de OS implementatie.

[swing7wing]

Ondersteund Azure dit wel?

[Amiga3000]

Nee nog niet

https://feedback.azure.co...this-should-be-implemente

[thof]

Ligt aan de dienst die je gebruikt, maar de meesten nog niet.

[MoonWatcher]

En in hun CDN. ( CloudFront )

Ik ben bang dat de server wereld hier nog niet helemaal klaar voor is. Maar een oproep om wakker te worden lijkt en de voordelen van TLSv1.3 te omarmen lijkt mij zeker een stap in de goede richting.

[Reactie gewijzigd door MoonWatcher op 23 juli 2024 08:05]

[Pikkemans]

Zoals hierboven aangegeven is CloudFlare een ander bedrijf.

AWS heeft CloudFront (CDN) en die ondersteund dan wel weer TLS 1.3.

Bron

[MoonWatcher]

Bedankt voor de toevoeging.

Blijkbaar staat het standaard aan bij CloudFront ongeacht wat je aan protocollen hebt ingesteld in je CDN profiel zelf in AWS. En daar zie je alleen TLS 1.1 en TLS 1.2 als opties. Bijzonder dat ze voor deze constructie hebben gekozen. Enigsinds afwijkend van hoe ze dit in het verleden deden. Overigens vind ik het persoonlijk wel prettig dat het al aan staat.

[Verwijderd]

Ik denk dat je de profielen verkeerd begrijpt. Het protocol dat in de naam staat, is het "minimum" dat ze ondersteunen.

De SSLv3 security policy ondersteunt SSlv3 en alles daarboven (dus ook tls 1.3).

Het staat allemaal vrij duidelijk omschreven in de docs: https://docs.aws.amazon.c...er-protocols-ciphers.html

[Snake]

CloudFlare is een ander bedrijf.
Bedoel je CloudFront?

[MoonWatcher]

Ja, Excuus, Inmiddels aangepast. Ik bedoelde inderdaad CloudFront.
Tot voorkort was TLS 1.3 ook nog experimenteel bij CloudFlare.
CloudFlare is inderdaad wel een stuk sneller met de ondersteuning van nieuwe functionaliteiten en daar is het al wel mogelijk om gebruik te maken van TLS 1.3 zoals je zelf ook al aangaf.

[Reactie gewijzigd door MoonWatcher op 23 juli 2024 08:05]

[ppl]

Amazon CloudFront now supports TLSv1.3 for improved performance and security. Amazon CloudFront is a global content delivery network (CDN) that enables you to securely distribute content to viewers with low latency and high availability. Amazon CloudFront supports HTTPS using Transport Layer Security (TLS) to encrypt and secure communication between your viewer clients and CloudFront. TLSv1.3 is the latest version of TLS.

Bronnen:
* https://aws.amazon.com/ab...oudfront-tlsv1-3-support/
* https://docs.aws.amazon.c...er-protocols-ciphers.html

Voor de Application Load Balancers (en ook de andere load balancer opties van AWS) is er ook documentatie waarin een overzicht staat wat er aan TLS versies wordt ondersteund (zie Security Policies): https://docs.aws.amazon.c...tml#describe-ssl-policies

Ze ondersteunen dus nog niet overal TLSv1.3. Daarom is het ook van belang dat je de documentatie induikt om dat na te gaan. Afgezien daarvan hebben TLSv1.2 en 1.3 ook overeenkomsten. Als je de juiste algoritmes gebruikt met 1.2 dan zit je vrij dicht tegen 1.3 aan. Bovendien is security veel meer dan alleen maar de nieuwste TLS versie gebruiken. Je hoeft dus echt niet in de stress te schieten en boe te gaan roepen omdat iets TLSv1.2 gebruikt ipv 1.3. Eigenlijk is het advies van het NCSC een schot voor open doel: de nieuwere versie van TLS is veiliger dan zijn voorganger dus is het aan te raden om de nieuwste te gebruiken (het is alleen een gedachte die niet altijd op gaat).

[Reactie gewijzigd door ppl op 23 juli 2024 08:05]

[kodak]

Zolang het voor klanten van aws nog te accepteren is lijkt dat dus geen probleem. Maar dan is het nu wel tijd om aan aws (of andere dienstverleners) aan te geven dat dit moet gaan veranderen.

[digi-savvy]

Als je server het ondersteunt direct implementeren, het is back-ward compatibel met TLS v1.2 dus als een client niet verder komt dan TLS v1.2 is het nog steeds werkbaar en inmiddels zijn volgens mij de meeste clients wel over naar TLS v1.2 aangezien TLS v1.0 en v1.1 al twee jaar deprecated zijn!

@TijsZonderH misschien wel handig de backward compatibility op te nemen in het artikel

[edit] : opmerking aan Tijs

[Reactie gewijzigd door digi-savvy op 23 juli 2024 08:05]

[v42.net]

Helaas niet 100% back-ward compatible: het gebruik van client certificates werkt nu heel anders. Nu zullen de meeste Tweakers dat niet gebruiken, maar ik heb mijn neus al hard gestoten

Tot en met TLS v1.2 kan je in Apache met ".htaccess" in een directory het gebruik van een client certificate afdwingen, terwijl de rest van de website geen client certificates vereist. Met TLS v1.3 is dat niet meer mogelijk en moet je dus twee aparte websites inrichten: één met, en één zonder de eis voor het gebruik van een client certificate.

Alles verbouwen kost wat meer tijd, dus voorlopig heb ik TLS v1.3 uitgeschakeld. Hoe de definitieve oplossing er uit gaat zien weet ik nog niet. Misschien een mooi moment om naar NGINX om te schakelen ... heeft iemand al een manier gevonden om meer uren in een dag te krijgen?

[digi-savvy]

die was ik nog niet tegengekomen, goed dat je het zegt!

nee, ik krijg ook niet meer dan 25 uur in een dag