TLS 1.2 en TLS 1.3 begrijpen

TLS (Transport Layer Security) is het cryptografische protocol dat gegevens versleutelt en authenticeert die tussen clients en servers over een netwerk worden verzonden. Het beschermt persoonlijke informatie, financiële transacties, API-verkeer en zakelijke communicatie tegen afluisteren, manipulatie en identiteitsfraude. TLS 1.3 is de momenteel aanbevolen versie. Het reduceert het aantal handshake-rondes van 2 naar 1, vereist forward secrecy via ECDHE voor alle verbindingen, verwijdert alle zwakke cipher suites uit het verleden en versleutelt een groter deel van de handshake dan TLS 1.2. De aanbevolen actie: schakel TLS 1.3 onmiddellijk in op alle servers, schakel TLS 1.0 en 1.1 uit, beperk TLS 1.2 tot alleen ECDHE-AEAD cipher suites gedurende de overgangsperiode en houd beide versies parallel totdat analyse van bestaande clients bevestigt dat TLS 1.2 kan worden uitgefaseerd.

Kort antwoord: TLS 1.2 versus TLS 1.3 – Welke te gebruiken en waarom?

TLS 1.3 is de juiste keuze voor alle nieuwe implementaties. Het is sneller (1-RTT handshake versus 2-RTT), veiliger (verplichte forward secrecy, versleutelde handshake, verwijdering van alle verouderde algoritmen) en eenvoudiger (5 cipher suites in plaats van honderden). TLS 1.2 blijft alleen nodig voor achterwaartse compatibiliteit met clients en systemen die TLS 1.3 nog niet ondersteunen. NIST schrijft voor dat alle TLS-servers van de Amerikaanse federale overheid zowel TLS 1.2 (met FIPS-compatibele cipher suites) als TLS 1.3 moeten ondersteunen, conform NIST SP 800-52 Revisie 2 , waarbij TLS 1.3 verplicht is vanaf 1 januari 2024. TLS 1.0 en TLS 1.1 mogen niet worden gebruikt; ze bevatten bekende kwetsbaarheden die kunnen worden misbruikt en hebben momenteel geen legitiem gebruik.

Wat is TLS?

Transport Layer Security (TLS) is een cryptografisch protocol dat in 1999 door de IETF is gestandaardiseerd. TLS bouwt voort op SSL (Secure Sockets Layer) door de kwetsbaarheden ervan aan te pakken en de beveiliging te verbeteren met behulp van sterkere encryptiealgoritmen, verbeterde certificaatvalidatie en bescherming tegen aanvallen die in SSL-versies aanwezig waren. Oudere TLS-versies (1.0 en 1.1) hadden beveiligingslekken waardoor aanvallers gevoelige gegevens konden stelen. TLS beschermt gegevens door middel van drie mechanismen die samenwerken:

• authenticatie: Tijdens de handshake presenteert de server een TLS-certificaat dat is uitgegeven door een vertrouwde certificeringsinstantie (CA). De client verifieert dit certificaat om te bevestigen dat hij communiceert met de legitieme server en niet met een neppe server.
• encryptie: Nadat de handshake een gedeelde sessiesleutel heeft vastgesteld, worden alle verzonden gegevens versleuteld met een symmetrische encryptie (AES-GCM of ChaCha20-Poly1305 in TLS 1.3), waardoor afluisteraars de inhoud niet kunnen lezen.
• Integrity: AEAD-coderingssuites bevatten authenticatietags die elke wijziging van versleutelde gegevens detecteren, waardoor een aanvaller de gegevens tijdens de overdracht niet ongemerkt kan wijzigen.

TLS 1.2 en zijn handshake

TLS 1.2, geïntroduceerd in augustus 2008 (IETF RFC 5246), pakte de beperkingen van TLS 1.0 en 1.1 aan door middel van sterkere encryptiealgoritmen, verbeterde certificaatvalidatie en ondersteuning voor AEAD-coderingssuites. De handshake vereist twee round trips (2-RTT):

• De client verstuurt een ClientHello met ondersteunde TLS-versies, cipher suites, een willekeurige client-ID en een optionele sessie-ID.
• De server reageert met een ServerHello waarin de TLS-versie en cipher suite, zijn eigen willekeurige getal en zijn ondertekende certificaat met publieke sleutel worden geselecteerd. Als wederzijdse authenticatie vereist is, vraagt ​​de server om een ​​clientcertificaat.
• De client valideert het certificaat van de server aan de hand van vertrouwde certificeringsinstanties (CA's). Bij wederzijdse TLS (mTLS) valideert de server ook het certificaat van de client.
• Cryptografie met openbare sleutel Beveiligt de sleuteluitwisseling: de client stuurt een pre-master secret, versleuteld met de publieke sleutel van de server. Alleen de server kan deze ontsleutelen met zijn privésleutel, die veilig wordt bewaard in een HSM of sleutelkluis. Beide partijen leiden sessiesleutels af uit het pre-mastergeheim en hun willekeurige waarden.
• Client en server wisselen ChangeCipherSpec- en Finished-berichten uit om te bevestigen dat ze klaar zijn voor symmetrische encryptie. Alle verdere communicatie maakt gebruik van de afgeleide sessiesleutels.

Belangrijkste kenmerken van TLS 1.2

• Verbeterde hashing: De MD5+SHA-1-combinatie die in eerdere versies werd gebruikt, is vervangen door configureerbare hash-algoritmen, waaronder SHA-256 en SHA-384.
• Ondersteuning voor AES-coderingssuites: geïntroduceerd AES cipher suites met 128-bits en 256-bits sleutels, die een aanzienlijk sterkere symmetrische encryptie bieden dan de DES-gebaseerde suites die ze hebben vervangen.
• Ondersteuning voor geauthenticeerde versleuteling (AEAD): Uitgebreide ondersteuning voor AEAD-modi, waaronder AES-GCM en AES-CCM, die zowel vertrouwelijkheid als integriteitsverificatie in één bewerking bieden.
• Onderhandelbare hash- en handtekeningalgoritmen: Zowel de client als de server kunnen tijdens de handshake hun ondersteunde hash- en handtekeningalgoritmen specificeren, waardoor de sterkste, door beide partijen ondersteunde combinatie kan worden geselecteerd en een soepele overstap van zwakke algoritmen zoals SHA-1 mogelijk wordt.

TLS 1.3 en zijn handshake

TLS 1.3, gepubliceerd in augustus 2018 (RFC 8446), vertegenwoordigt een aanzienlijke herziening van het protocol. Het geeft prioriteit aan beveiliging door kwetsbare, verouderde opties te verwijderen in plaats van er extra beveiligingsmaatregelen aan toe te voegen. De TLS 1.3-handshake wordt in één round trip (1-RTT) voltooid:

• De client verstuurt een ClientHello met daarin de ondersteunde TLS-versie, cipher suites, client random en key shares voor de voorkeurs-ECDHE-groepen. Als clientauthenticatie is ingeschakeld, voegt de client ook certificaatinformatie toe.
• De server selecteert de cipher suite en de ECDHE-groep, genereert het master secret op basis van de willekeurige getallen die worden gegenereerd door ClientHello en de server, gecombineerd met de geselecteerde sleutelshares, en verzendt een ServerHello met de geselecteerde parameters plus een ServerFinished-bericht. Het certificaat van de server en alle daaropvolgende handshake-berichten worden versleuteld.
• De client verifieert het certificaat van de server, genereert hetzelfde hoofdgeheim met behulp van zijn eigen sleutelbestand en het antwoord van de server, stuurt een ClientFinished-bericht en beide partijen beginnen met de versleutelde uitwisseling van applicatiegegevens. De volledige handshake is in één keer voltooid.

Belangrijkste kenmerken van TLS 1.3

• Verplichte forward secrety: TLS 1.3 vereist ECDHE voor alle sleuteluitwisselingen, waardoor forward secrecy verplicht is voor elke verbinding. Zelfs als de permanente TLS-privésleutel van een server later wordt gecompromitteerd, kunnen eerdere sessies niet worden gedecodeerd omdat de tijdelijke sessiesleutels verloren zijn gegaan.
• Alleen AEAD-coderingssuites toegestaan: TLS 1.3 staat slechts vijf cipher suites toe, allemaal AEAD: AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20-Poly1305-SHA256, AES-128-CCM-SHA256 en AES-128-CCM-8-SHA256. Alle suites bieden geauthenticeerde encryptie die manipulatie detecteert.
• Versleutelde handdruk: TLS 1.3 versleutelt meer van de handshake dan TLS 1.2, waaronder het servercertificaat. Passieve waarnemers kunnen niet zien welk certificaat een server presenteert.
• 0-RTT hervatting: Clients die opnieuw verbinding maken met een server waarmee ze eerder al verbinding hebben gemaakt, kunnen applicatiegegevens met het eerste bericht verzenden (0-RTT), waardoor de latentie voor terugkerende verbindingen wordt verminderd. Let op: 0-RTT-gegevens zijn kwetsbaar voor replay-aanvallen en mogen niet worden gebruikt voor niet-idempotente bewerkingen (verzoeken die de status wijzigen, zoals financiële transacties).
• Algoritme verwijderen: TLS 1.3 verwijdert RC4, DES, 3DES, MD5, SHA-1, RSA-sleuteluitwisseling, statische DH, CBC-coderingssuites en TLS-compressie — stuk voor stuk aanvalsvectoren in TLS 1.2-implementaties.

Vergelijking: TLS 1.2 versus TLS 1.3

Kenmerk	TLS 1.2	TLS 1.3	Impact
Handshake-rondreizen	2-RTT	1-RTT (0-RTT voor hervatting van de sessie)	TLS 1.3 zorgt voor een snellere verbindingsopbouw; 0-RTT brengt een risico op replay-aanvallen met zich mee.
Toegestane cijferreeksen	Honderden, waaronder zwakke kandidaten (RC4, DES, CBC)	Slechts vijf AEAD-suites	TLS 1.2 vereist zorgvuldige configuratie om zwakke suites te vermijden; TLS 1.3 is van nature veilig.
Sleuteluitwisseling	RSA, DHE, ECDHE (allemaal ondersteund)	alleen ECDHE	TLS 1.3 biedt forward secrecy voor elke verbinding; TLS 1.2 RSA-sleuteluitwisseling biedt geen forward secrecy.
Voorwaartse geheimhouding	Optioneel (afhankelijk van de cipher suite)	Verplicht	TLS 1.3 beschermt eerdere sessies, zelfs als de langetermijnsleutel is gecompromitteerd.
Handshake-versleuteling	Certificaat in platte tekst weergegeven tijdens handshake	Certificaat versleuteld tijdens de handshake	TLS 1.3 verbergt de serveridentiteit voor passieve waarnemers.
Algoritme verwijdering	Ondersteunt RC4, MD5, SHA-1, 3DES (moet expliciet worden uitgeschakeld).	Deze algoritmes zijn volledig verwijderd	TLS 1.3 elimineert complete aanvalscategorieën (POODLE, BEAST, CRIME) door de kwetsbare primitieven te verwijderen.
Hervatting van de sessie	Sessie-ID's en sessietickets	PSK met 0-RTT-optie	TLS 1.3-sessietickets bieden forward secrecy; TLS 1.2-sessietickets mogelijk niet.
Certificaatvalidatie	Enkele details over de handdruk onthuld	Volledige handshake versleuteld na ServerHello	TLS 1.3 biedt een verbetering van de privacy voor de inhoud van certificaten.
Prestaties	Langzamer (2-RTT handdruk)	Sneller (1-RTT; 0-RTT voor hervatting)	TLS 1.3 verlaagt de latentie, met name voor netwerken met hoge latentie en mobiele clients.
NIST-mandaat	Vereist; alleen FIPS-compatibele cipher suites	Vereist vanaf 1 januari 2024 (NIST SP 800-52 Rev. 2)	Beide zijn vereist voor federale systemen; TLS 1.3 is de huidige standaard.

Cipher suite selectie voor TLS 1.2

TLS 1.3 heeft een vaste lijst van vijf AEAD-coderingssuites; er is niets te kiezen. TLS 1.2 ondersteunt een veel breder scala, inclusief onveilige opties die expliciet moeten worden uitgeschakeld. Aanbevolen TLS 1.2-coderingssuites volgens NIST SP 800-52 Rev. 2 (in volgorde van voorkeur):

• TLS_ECDHE_ECDSA_MET_AES_256_GCM_SHA384 (beste: ECDHE forward secrecy, ECDSA cert, AES-256-GCM AEAD)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ECDHE forward secrecy, RSA cert, AES-256-GCM AEAD)
• TLS_ECDHE_ECDSA_MET_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_MET_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_MET_CHACHA20_POLY1305_SHA256

Schakel in TLS 1.2 expliciet alle suites uit die RC4-, DES-, 3DES-, NULL-encryptie, EXPORT-, MD5- of anonieme (anon) sleuteluitwisseling bevatten. Schakel alle RSA-sleuteluitwisselingssuites (TLS_RSA_*) uit: deze bieden geen forward secrecy. Vermijd waar mogelijk CBC-suites vanwege de gevoeligheid voor padding oracle-aanvallen (POODLE, BEAST).

Kwetsbaarheden: TLS 1.2 en TLS 1.3

TLS 1.2 is het doelwit geweest van verschillende spraakmakende aanvallen, waarbij de meeste misbruik maakten van de ondersteuning voor verouderde algoritmen:

• BEEST (2011): De voorspelbaarheid van CBC IV werd in TLS 1.0 benut; dit werd gedeeltelijk verholpen in TLS 1.2 door middel van de AES-GCM- en AEAD-coderingssuites.
• POEDEL (2014): Er werd misbruik gemaakt van een SSL 3.0 padding-orakel via protocol-downgrade-aanvallen; dit is verholpen door SSL 3.0 en TLS 1.0/1.1 uit te schakelen.
• Heartbleed (2014): OpenSSL-geheugenlek; dit zit niet in de TLS-specificatie zelf, maar trof wel TLS 1.2-implementaties.
• Wasbeer aanval (2020): Een op timing gebaseerde side-channel-aanval op DHE-sleuteluitwisseling; het gebruik van ECDHE in TLS 1.3 elimineert statische DH volledig.
• MISDRIJF en INBREUK: maakte gebruik van TLS-compressie om geheimen te achterhalen; TLS 1.3 verwijdert compressie volledig.

TLS 1.3 elimineert de meeste van deze aanvalsoppervlakken door de kwetsbare primitieven (CBC-modi, DH, compressie, RSA-sleuteluitwisseling) te verwijderen in plaats van ze te omzeilen met patches. TLS 1.3 is echter niet immuun voor implementatiekwetsbaarheden: verkeerde configuraties zoals voorspelbare nonces in AES-GCM, onjuiste 0-RTT-replaybeveiliging en zwakke sleutelgeneratie kunnen nog steeds kwetsbaarheden creëren. De NIST CVE-database heeft implementatiefouten in TLS 1.3 in specifieke producten gedocumenteerd. Regelmatig patchen, beveiligingsaudits en controle van de TLS-configuratie blijven essentieel, zelfs met TLS 1.3.

Implementatievoorbeeld: Migratie van Enterprise TLS

Een financiële dienstverlener met 200 publiekelijk toegankelijke diensten voert een gestructureerde TLS-migratie uit:

1. Audit en inventarisatie: Een scan van de TLS-configuratie op alle 200 eindpunten identificeert het volgende: 12 services die nog steeds TLS 1.0 of 1.1 gebruiken; 85 services die TLS 1.2 gebruiken met RSA-sleuteluitwisselingscodering (zonder forward secrecy); 40 services die zwakke CBC-coderingscodering gebruiken; 63 services die al TLS 1.2 gebruiken met ECDHE-AEAD-codering. TLS-certificaten: 140 RSA-2048, 60 ECDSA P-256.
2. TLS 1.0/1.1 direct uitschakelen: De 12 services die TLS 1.0/1.1 gebruiken, worden binnen 30 dagen bijgewerkt om deze versies uit te schakelen, aangezien dit het grootste risico in de omgeving vormt.
3. TLS 1.3 inschakelen op alle servers: TLS 1.3 is naast TLS 1.2 ingeschakeld op alle servers. Moderne browsers en API-clients beginnen direct met het gebruik van TLS 1.3; oudere clients blijven TLS 1.2 gebruiken.
4. Beveiliging van de TLS 1.2 cipher suite: Alle RSA-sleuteluitwisseling en CBC-coderingssuites zijn uitgeschakeld in TLS 1.2-configuraties. Alleen de ECDHE-AEAD-suites blijven ingeschakeld, waardoor forward secrecy voor TLS 1.2-verbindingen tijdens de overgangsperiode wordt gewaarborgd.
5. Certificaatmigratie: RSA-2048-certificaten worden bij certificaatvernieuwing gemigreerd naar ECDSA P-256, met behulp van CertSecure Manager Om de verlenging te automatiseren en de voorraad bij te houden. ECDSA P-256 reduceert de omvang van de TLS-handshake en het volume aan certificaatgegevens.
6. TLS 1.2 pensioenplanning: Uit analyse van de toegangslogboeken blijkt dat het gebruik van TLS 1.2 maand na maand afneemt naarmate clients updates uitvoeren. Er is een plan opgesteld om TLS 1.2 uit te schakelen zodra het gebruik onder de 1% van de verbindingen zakt, naar verwachting binnen 12 maanden.

Sleutelbeheerafhankelijkheden voor TLS

• TLS-privésleutelbeveiliging: De privésleutel van de TLS-server is het meest gevoelige onderdeel van een TLS-implementatie. Compromittering van deze sleutel maakt het mogelijk om eerdere sessies te decoderen zonder forward secrecy (TLS 1.2 RSA-sleuteluitwisseling) en maakt serverimitatie mogelijk. Bewaar TLS-privésleutels waar mogelijk in FIPS 140-2 Level 2 of hogere HSM's of hardwarematige sleutelopslag. Zie HSM als een service.
• Automatisering van de certificaatlevenscyclus: TLS-certificaten zijn machine-identiteiten met een vervaldatum. Handmatig certificaatbeheer op grote schaal is niet haalbaar: het CA/Browser Forum heeft bepaald dat de geldigheidsduur van certificaten tegen 2029 moet worden teruggebracht tot 47 dagen. CertSecure Manager Automatiseert de detectie, verlenging en handhaving van beleid voor alle TLS-certificaten in de inventaris.
• Certificaatalgoritmevaluta: Volgens NIST IR 8547 worden RSA-2048-certificaten na 2030 uitgefaseerd. Organisaties dienen voor alle nieuwe implementaties ECDSA P-256-certificaten uit te geven en bij verlenging over te stappen op RSA-certificaten.

Migratie-uitdagingen

• Incompatibiliteit met oudere systemen: Oudere systemen, embedded devices en bepaalde middleware voor bedrijven ondersteunen mogelijk geen TLS 1.3. Deze vereisen updates of vervanging, wat kostbaar kan zijn voor sectoren met een omvangrijke, verouderde infrastructuur.
• Verwijdering van RSA-sleuteluitwisseling: Het feit dat TLS 1.3 de RSA-sleuteluitwisseling heeft afgeschaft, zorgt ervoor dat systemen die ervan afhankelijk zijn, niet meer werken. Netwerkinspectieapparaten die TLS-inspectie uitvoeren door verbindingen te onderscheppen en opnieuw te ondertekenen, moeten mogelijk opnieuw geconfigureerd worden om te werken met de tijdelijke sleuteluitwisseling van TLS 1.3.
• Handshake-wijzigingen die applicatie-updates vereisen: De gewijzigde handshake- en sessiehervattingsmechanismen van TLS 1.3 vereisen aanpassingen aan de applicatielogica in systemen met complexe authenticatie- of verbindingsstromen.
• Het vinden van een evenwicht tussen achterwaartse compatibiliteit en de overgang: Het is noodzakelijk, maar tijdelijk, om TLS 1.2 naast TLS 1.3 te blijven gebruiken tijdens de migratieperiode. TLS 1.2 met ECDHE-AEAD-suites biedt een acceptabele beveiliging tijdens de overgang; gewone TLS 1.2 met RSA-sleuteluitwisseling is dat niet en moet worden uitgeschakeld, zelfs als TLS 1.2 blijft bestaan.

Hoe encryptieconsultancy kan helpen

Bij Encryption Consulting helpen we organisaties bij het aanpakken van TLS-migratie-uitdagingen met maatwerkoplossingen die zijn afgestemd op hun specifieke infrastructuur. Onze diensten omvatten TLS-configuratiebeoordeling en -audit (het identificeren van zwakke cipher suites, verouderde protocolversies en certificaathiaten in uw omgeving), migratieplanning en -implementatie (een gestructureerde aanpak voor het inschakelen van TLS 1.3 en het uitfaseren van zwakkere configuraties met minimale serviceonderbrekingen) en certificaatlevenscyclusbeheer via CertSecure Manager (het automatiseren van de ontdekking, verlenging en beleidshandhaving voor TLS-certificaten, inclusief de aanstaande vereiste van een certificaatlevensduur van 47 dagen). Onze PKI-diensten omvatten ook de infrastructuur van de certificeringsinstantie die TLS-certificaten uitgeeft, zodat de vertrouwensketen correct is ontworpen en beheerd.

Conclusie

TLS is het fundamentele protocol voor het beveiligen van gegevens die via internet worden verzonden. TLS 1.3 is de huidige standaard: sneller dan TLS 1.2, met verplichte forward secrecy, een versleutelde handshake en zonder de ballast van verouderde algoritmen. Organisaties moeten TLS 1.3 onmiddellijk op alle servers inschakelen, TLS 1.0 en 1.1 zonder vertraging uitschakelen, TLS 1.2 alleen tijdens de overgangsperiode beveiligen voor ECDHE-AEAD-suites en plannen maken voor de uitfasering van TLS 1.2 zodra een analyse van verouderde clients bevestigt dat het niet langer nodig is.

De certificaatdimensie van TLS-beheer wordt steeds complexer: de certificaten hebben vanaf 2029 een levensduur van 47 dagen, waardoor geautomatiseerd lifecyclemanagement in plaats van handmatige controle noodzakelijk is. Ook de algoritmedimensie verandert: RSA-2048-certificaten worden naar verwachting na 2030 uitgefaseerd, waardoor ECDSA P-256 nu de juiste keuze is voor alle nieuwe TLS-certificaten. Zie voor meer informatie onze handleidingen over ECC- en SSL/TLS-certificaten.

Veelgestelde Vragen / FAQ

Wat is TLS en wat beschermt het?

TLS is een cryptografisch protocol dat vertrouwelijkheid, integriteit en authenticatie biedt voor netwerkgegevens. Het beschermt gegevens tegen afluisteren (versleuteling), manipulatie (integriteit via AEAD) en identiteitsvervalsing (servercertificaatverificatie via CA). Het wordt gebruikt in HTTPS, SMTP, IMAP, API-verkeer, databaseverbindingen en VPN-protocollen.

Wat is het verschil tussen TLS 1.2 en TLS 1.3?

TLS 1.3 is sneller (1-RTT versus 2-RTT), vereist forward secrecy via ECDHE, staat slechts 5 AEAD-coderingssuites toe (versus honderden in TLS 1.2, inclusief zwakke suites), versleutelt een groter deel van de handshake en verwijdert alle verouderde algoritmen (RC4, 3DES, RSA-sleuteluitwisseling, CBC, compressie) die aanvalsvectoren waren in TLS 1.2.

Welke cipher suites moeten worden gebruikt met TLS 1.2?

NIST SP 800-52 Rev. 2 beveelt ECDHE-AEAD-suites aan: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 en TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 hebben de voorkeur. Schakel waar mogelijk alle RSA-sleuteluitwisselingssuites (zonder forward secrecy), alle RC4/DES/3DES-suites, MD5/SHA-1-suites en CBC-suites uit.

Wat is forward secrecy en waarom vereist TLS 1.3 het?

Forward secrecy betekent dat het compromitteren van de langetermijn-TLS-privésleutel het niet mogelijk maakt om eerdere sessies te decoderen, omdat de sessiesleutels tijdelijk waren. TLS 1.3 schrijft dit voor via ECDHE voor alle verbindingen. Zonder forward secrecy (TLS 1.2 RSA-sleuteluitwisseling) kan een aanvaller die het huidige verkeer vastlegt, dit achteraf decoderen als hij later de privésleutel bemachtigt.

Hoe moeten organisaties migreren van TLS 1.2 naar TLS 1.3?

Schakel TLS 1.3 in op alle servers naast TLS 1.2 (niet in plaats daarvan). Schakel TLS 1.0 en 1.1 onmiddellijk uit. Beperk het gebruik van TLS 1.2 tot alleen ECDHE-AEAD-suites. Monitor de distributie van het TLS-protocol in de toegangslogboeken. Plan de uitfasering van TLS 1.2 zodra uit de monitoring blijkt dat het gebruik door actieve clients minimaal is.

Welke aanvallen treffen TLS 1.2 en zijn deze verholpen in TLS 1.3?

BEAST-, POODLE- en soortgelijke aanvallen maakten misbruik van de ondersteuning van CBC-coderingssuites en zwakke algoritmen in TLS 1.2. TLS 1.3 verwijdert CBC-coderingssuites volledig, waardoor deze aanvalsklassen worden geëlimineerd. Raccoon richtte zich op DHE; TLS 1.3 gebruikt alleen ECDHE. CRIME maakte misbruik van compressie; TLS 1.3 verwijdert compressie. TLS 1.3 is niet immuun voor implementatiefouten, maar elimineert de kwetsbare primitieven die de meeste bekende aanvallen op protocolniveau mogelijk maakten.