Wat zijn encryptieprotocollen en hoe werken ze?

Gepubliceerd: mei 2021. Bijgewerkt: augustus 2026. Beoordeeld door het PKI-adviessteam van Encryption Consulting.

Versleuteling zet leesbare gegevens om in versleutelde tekst, maar versleuteling alleen vertelt twee computers niet hoe ze een sleutel moeten afspreken, elkaars identiteit moeten verifiëren of de versleutelde bytes op de lijn moeten structureren. Dat is de taak van een versleutelingsprotocol. Elke beveiligde verbinding waarop u vertrouwt – een browsersessie, een VPN-tunnel, een SSH-login, een ondertekende e-mail – is gebouwd op een specifiek protocol dat precies aangeeft hoe versleuteling wordt gebruikt, niet alleen welk algoritme de berekeningen uitvoert. Het kiezen van het verkeerde protocol, of een verouderde versie van het juiste, is een van de meest voorkomende tekortkomingen die we tijdens architectuurbeoordelingen aantreffen bij onze adviesdiensten op het gebied van versleuteling .

Wat is het verschil tussen een encryptieprotocol en een encryptiealgoritme?

Een encryptiealgoritme is een specifieke wiskundige procedure, zoals AES , RSA of ECDSA, die platte tekst omzet in versleutelde tekst, een digitale handtekening genereert of een hash produceert. Een algoritme op zich heeft geen mening over hoe twee partijen elkaar vinden, overeenkomen welk algoritme te gebruiken, sleutels veilig uitwisselen of een gemanipuleerd bericht detecteren.

Een protocol is het reglement dat een of meer algoritmen samenvoegt tot een werkend beveiligingssysteem voor een specifiek doel. TLS 1.3, gedefinieerd in RFC 8446 , specificeert de exacte handshake-berichten die een client en server uitwisselen, welke cipher suites zijn toegestaan, hoe de sessiesleutel wordt afgeleid en hoe de verbinding wordt geverifieerd met een certificaat. Vervang AES door ChaCha20-Poly1305 binnen diezelfde TLS 1.3-handshake en het protocol is niet veranderd, alleen het algoritme dat het protocol onderhandelt. Dat onderscheid is operationeel belangrijk: een protocolversie kan verouderd raken, zelfs als elk algoritme erin nog steeds als sterk wordt beschouwd, omdat de onderhandelingslogica zelf een fout bevat (dit is precies wat er met SSLv3 is gebeurd, zoals hieronder wordt besproken).

De meeste asymmetrische protocollen werken samen met een Public Key Infrastructure (PKI) . Een PKI geeft de digitale certificaten uit die TLS, IPsec en S/MIME gebruiken om een ​​publieke sleutel aan een identiteit te koppelen. Zo heeft de handshake van het protocol iets betrouwbaars om te controleren aan de hand van een vertrouwensketen die teruggaat naar een certificeringsinstantie . Zonder die identiteitslaag kan een protocol nog steeds een kanaal versleutelen, maar het kan niet vaststellen wie zich aan de andere kant bevindt.

Wat zijn de belangrijkste encryptieprotocollen en hoe werkt elk protocol?

TLS/SSL: Beveiliging van client-serververbindingen

Transport Layer Security (TLS), de opvolger van het oudere Secure Sockets Layer (SSL), is het protocol achter het hangslotpictogram en "https" in de adresbalk van uw browser. TLS versleutelt zelf niets; het onderhandelt over welke algoritmen dat werk zullen doen. Een TLS-handshake selecteert de protocolversie, authenticeert de server (en optioneel de client) met behulp van een X.509-certificaat, komt een cipher suite overeen en leidt een gedeelde sessiesleutel af. TLS 1.3, gestandaardiseerd in RFC 8446 , verkortte de handshake tot één roundtrip, verwijderde de ondersteuning voor statische RSA-sleuteluitwisseling en CBC-modus ciphers, en beperkt de onderhandeling tot een korte lijst van AEAD-cipher suites. Zie onze inleiding tot cipher suites voor een exacte beschrijving van welke algoritmecombinaties TLS 1.2 en 1.3 toestaan ​​en hoe de handshake hierover onderhandelt.

IPsec: Versleuteling van netwerkverkeer en VPN-tunnels

Internet Protocol Security (IPsec) beveiligt verkeer op de netwerklaag in plaats van de applicatielaag, waardoor het protocolonafhankelijk is: alles wat via IP wordt verzonden, wordt beschermd zonder dat de applicatie hoeft te weten dat er versleuteling plaatsvindt. IPsec heeft twee kernsubprotocollen: AH (Authentication Header) voor integriteit en ESP (Encapsulating Security Payload) voor vertrouwelijkheid en integriteit. Er zijn twee modi: transportmodus, die alleen de payload van het pakket versleutelt, en tunnelmodus, die het volledige originele pakket inclusief de header versleutelt. De tunnelmodus wordt door de meeste site-to-site VPN's en VPN's voor toegang op afstand gebruikt. Voordat deze versleuteling kan plaatsvinden, hebben beide eindpunten een gedeelde sleutel nodig. Hier komt het Internet Key Exchange (IKE)-protocol in beeld. IKEv2, gedefinieerd in RFC 7296 , onderhandelt over en vernieuwt deze sleutels en is de huidige standaard; de voorganger IKEv1 werd formeel afgekeurd door RFC 9395 in 2023 en moet worden uitgefaseerd in configuraties die deze nog steeds gebruiken.

SSH: Beveiliging van beheer op afstand

Secure Shell (SSH) beschermt interactieve externe aanmeldingen, bestandsoverdrachten en poortdoorsturing. De architectuur, beschreven in RFC 4251 , is verdeeld in drie lagen, elk met een eigen RFC: de transportlaag ( RFC 4253 ) onderhandelt over de algoritmen en brengt een versleuteld, op integriteit gecontroleerd kanaal tot stand met behulp van een Diffie-Hellman-sleuteluitwisseling; de gebruikersauthenticatielaag ( RFC 4252 ) verifieert de identiteit van de client, doorgaans met een publieke sleutel in plaats van een wachtwoord; en de verbindingslaag ( RFC 4254 ) multiplexeert het versleutelde transport naar meerdere logische kanalen voor shells, bestandsoverdrachten en doorgestuurde poorten. Omdat SSH-toegang meestal wordt geauthenticeerd met lang geldige sleutelparen in plaats van verlopende certificaten, is een onbeheerd SSH-sleutelbestand een veelvoorkomende bevinding bij audits; dit is precies wat tools voor het beheer van de levenscyclus van SSH-sleutels moeten oplossen.

PGP en S/MIME: E-mail versleutelen en ondertekenen

OpenPGP en S/MIME versleutelen en ondertekenen beide e-mails digitaal, maar ze bouwen op verschillende manieren vertrouwen op. OpenPGP, momenteel gespecificeerd in RFC 9580 (die de oudere RFC 4880 vervangt), is gebaseerd op een gedecentraliseerd vertrouwensnetwerk waarin gebruikers elkaars sleutels rechtstreeks ondertekenen. S/MIME, gespecificeerd in RFC 8551 , vertrouwt daarentegen op X.509-certificaten die zijn uitgegeven door een certificeringsinstantie (CA), waardoor het een meer voor de hand liggende keuze is voor organisaties die al een PKI (Public Key Infrastructure) gebruiken voor andere doeleinden. Beide protocollen bieden vertrouwelijkheid en niet-afwijzing voor de inhoud van een bericht; geen van beide beschermt e-mailheaders, routeringsmetadata of berichten nadat ze zijn gedecodeerd en zich in een inbox bevinden.

WireGuard: een lichtgewicht, modern VPN-protocol

WireGuard is een nieuwer VPN-protocol dat is gebouwd rond een vaste, minimale cryptografische suite (Curve25519 voor sleuteluitwisseling, ChaCha20-Poly1305 voor encryptie, BLAKE2s voor hashing) in plaats van de onderhandelbare cipherlijst van IPsec. De handshake is gebaseerd op het Noise Protocol Framework en het volledige ontwerp is gedocumenteerd in een eigen technische whitepaper in plaats van een IETF RFC. Omdat er geen algoritmen worden onderhandeld, is er geen terugval naar oudere ciphers bij een verkeerde configuratie. Dit is een belangrijke reden waarom WireGuard-configuraties doorgaans kleiner en gemakkelijker te controleren zijn dan een vergelijkbare IPsec-configuratie. Het nadeel is minder flexibiliteit: als een onderdeel van de vaste suite van WireGuard ooit defect raakt, is een nieuwe versie van het protocol nodig in plaats van een configuratiewijziging.

Kerberos: Netwerkverificatie

Kerberos is een ticketgebaseerd authenticatieprotocol, vooral bekend als de basis van Windows Active Directory-aanmeldingen. Een centraal Key Distribution Center authenticeert een gebruiker eenmalig en geeft een ticket met een beperkte geldigheidsduur uit. De gebruiker presenteert dit ticket vervolgens aan de afzonderlijke services in plaats van zich bij elke service opnieuw te moeten authenticeren. Kerberos is ontworpen voor vertrouwde interne netwerken en Active Directory; het is geen vervanging voor TLS, IPsec of SSH voor verkeer dat een onbetrouwbaar netwerk doorkruist.

Welk encryptieprotocol moet u voor elk gebruiksscenario gebruiken?

Het juiste protocol vloeit rechtstreeks voort uit wat u wilt beschermen en wie de eindpunten zijn, en niet uit welk protocol in abstracte zin "het sterkst" is.

Use Case	Protocol	Huidige aanbevolen versie	Status
Web- en API-verkeer (client-server)	TLS / SSL	TLS 1.3 (RFC 8446); TLS 1.2 is een acceptabel minimum.	TLS 1.0/1.1 en SSLv3 zijn verouderd.
Site-to-site VPN, netwerklaagtunnels	IPsec	IKEv2 (RFC 7296)	IKEv1 is verouderd (RFC 9395)
Interactief beheer op afstand, bestandsoverdracht	SSH	SSH-2 (RFC 4251-4254)	SSH-1 is verouderd, gebruik het niet meer.
Vertrouwelijkheid van e-mail, door de organisatie beheerde PKI	S / MIME	S/MIME 4.0 (RFC 8551)	Actueel
Vertrouwelijkheid van e-mail, gedecentraliseerd vertrouwen	OpenPGP	RFC 9580	Huidig; RFC 4880 verouderd
Lichtgewicht VPN voor toegang op afstand/locatie	WireGuard	Vaste cipher suite volgens WireGuard whitepaper	Actueel
Interne AD-authenticatie	Kerberos	Kerberos 5 (RFC 4120)	Momenteel alleen geldig voor vertrouwde interne netwerken.

Uit deze tabel volgen enkele praktische regels. Openbare web- en API-eindpunten moeten TLS 1.3 gebruiken waar clientondersteuning dit toelaat, en terugvallen op een versie die niet lager is dan TLS 1.2. Site-to-site-verbindingen tussen datacenters of cloud-VPC's zijn doorgaans beter geschikt voor IPsec/IKEv2, omdat dit onder de applicatielaag werkt en integreert met bestaande router- en firewallinfrastructuur. Individuele gebruikers die vanuit onbeheerde netwerken verbinding maken met interne resources, zijn vaak beter af met WireGuard of een IPsec-client dan met pure SSH-tunneling, wat bedoeld is voor administratieve toegang in plaats van algemene netwerkdoeleinden. De keuze tussen S/MIME en OpenPGP voor e-mail hangt meestal af van de vraag of de organisatie al een PKI beheert: als dat het geval is, hergebruikt S/MIME die investering; als het publiek extern en gedecentraliseerd is, kan het web van vertrouwen van OpenPGP een meer praktische oplossing zijn.

Dreigingsmodel en verouderde protocollen die u moet vermijden

Elk van de bovenstaande protocollen gaat ervan uit dat er een actieve netwerkaanvaller is die pakketten kan lezen, wijzigen, injecteren en opnieuw afspelen, en niet slechts een passieve afluisteraar. Die aanname is de reden waarom versieonderhandeling zelf een beveiligingskritisch onderdeel van deze protocollen is: een aanvaller die een downgrade naar een zwakkere versie kan afdwingen, kan vaak de encryptie omzeilen zonder ook maar één algoritme te kraken. Verschillende protocolversies zijn om precies deze reden formeel afgekeurd en zouden overal waar ze nog geconfigureerd zijn, moeten worden uitgeschakeld.

• SSLv3 werd afgekeurd door RFC 7568 nadat de POODLE padding-oracle-aanval aantoonde dat het betrouwbaar kon worden gedowngrade en onbruikbaar gemaakt.
• TLS 1.0 en TLS 1.1 werden afgekeurd door RFC 8996 In 2021, vanwege de afhankelijkheid van zwakke MD5/SHA-1-constructies en de zwakheden van de CBC-modus, zonder een bruikbare veilige configuratie.
• IKEv1 werd afgekeurd door RFC 9395 in 2023, samen met een reeks verouderde IPsec-algoritmen.
• SSH-protocol versie 1 Het heeft bekende cryptografische zwakheden en is al bijna twintig jaar vervangen door SSH-2; elke server die het nog steeds aanbiedt, is een cruciale bevinding bij elke beoordeling.

De NIST-richtlijn voor federale TLS-implementaties, SP 800-52 Revisie 2 , vereist TLS 1.2 als minimum en stuurt overheidsinstanties richting TLS 1.3, wat dezelfde logica weerspiegelt: een protocolversie blijft alleen acceptabel zolang er geen praktische downgrade of cryptografische aanval op bestaat.

Hoe u uw configuratie van het encryptieprotocol kunt beveiligen

1. Inventariseer alle protocollen en versies die in gebruik zijn. Controleer zowel externe als interne eindpunten op de TLS-, IKE- en SSH-versies die ze momenteel accepteren, en niet alleen op de versie die u wilt gaan gebruiken.
2. Schakel verouderde versies uit op configuratieniveau. Verwijder SSLv3, TLS 1.0/1.1, IKEv1 en SSH-1 uit de server- en loadbalancerconfiguraties; ga er niet vanuit dat clients tijdens de onderhandeling simpelweg geen zwakke optie kiezen.
3. Stel een minimaal acceptabele versie in, niet alleen een voorkeursversie. Configureer TLS 1.2 als de ondergrens met TLS 1.3 als voorkeursstandaard en controleer of de server eerdere handshakes daadwerkelijk afwijst in plaats van ze alleen als lage prioriteit te vermelden.
4. Beperk de onderhandeling over de cijferreeks tot AEAD-reeksen. Verwijder de CBC-modus en RC4-suites uit elke TLS 1.2-configuratie die deze nog moet ondersteunen; zie de handleiding voor cijfersuites voor een op scenario's gebaseerde aanbevelingslijst.
5. Controleer het certificaat en de belangrijkste hygiënemaatregelen voor elk protocol. Controleer of de certificaatketen van TLS en S/MIME verwijst naar een vertrouwde root en niet bijna verloopt, en of de geautoriseerde SSH-sleutelbestanden geen onbeheerde of achtergebleven sleutels bevatten.
6. Test na elke wijziging opnieuw. Scan dezelfde eindpunten opnieuw om te bevestigen dat de verouderde versie daadwerkelijk is verdwenen uit de onderhandelde handshake van de server, en niet alleen is verwijderd uit een configuratiebestand dat nooit opnieuw is geladen.

Afweging tussen prestaties en interoperabiliteit

De protocolkeuze draait zelden alleen om de veiligheidsmarge; er zijn ook reële operationele kosten aan verbonden. De single-round-trip handshake van TLS 1.3 verlaagt de verbindingslatentie ten opzichte van TLS 1.2, wat van belang is bij miljoenen dagelijkse verbindingen. Oudere clients, sommige verouderde loadbalancers en bepaalde middleboxes met deep-packet inspection ondersteunen echter nog steeds alleen TLS 1.2, waardoor veel publiek toegankelijke services een TLS 1.2 fallback-pad beschikbaar moeten houden. De onderhandelbare cipherlijst van IPsec zorgt voor brede interoperabiliteit tussen hardware van verschillende leveranciers, ten koste van een groter aanvalsoppervlak door verouderde algoritmeopties die actief moeten worden verwijderd. De vaste cipher suite van WireGuard elimineert die onderhandelingsoverhead en houdt de pakketoverhead laag, waardoor het goed presteert op mobiele en beperkte netwerken. WireGuard kan echter niet terugvallen op oudere algoritmen als een client de huidige suite niet ondersteunt, en mist het ecosysteem van leveranciers en apparaten dat IPsec in de afgelopen twee decennia heeft opgebouwd. De per-kanaalmultiplexing van SSH is efficiënt voor interactieve sessies, maar is niet ontworpen voor grootschalige netwerkversleuteling. Daarom moet het niet worden gebruikt als algemene vervanging voor een VPN, ook al is een 'goedkope VPN' via SSH-tunneling technisch mogelijk.

Belangrijkste beheersafhankelijkheden van elk protocol

Geen enkel protocol op deze lijst is veilig zonder een werkend sleutelbeheerprogramma, en elk protocol is afhankelijk van een ander soort sleutelinfrastructuur:

• TLS / SSL is afhankelijk van een PKI die X.509-certificaten uitgeeft, vernieuwt en intrekt voordat ze verlopen of gecompromitteerd raken, en werkt samen met ons CertSecure Manager Het platform automatiseert processen voor grote certificaatportefeuilles.
• IPsec Het is afhankelijk van vooraf gedeelde sleutels of certificaatgebaseerde authenticatie voor de IKE-fase, en van periodieke sleutelvernieuwing om de hoeveelheid verkeer die door één enkele sleutel wordt beschermd te beperken.
• SSH Dit is afhankelijk van het beheren van mogelijk duizenden langlopende, niet-verlopende sleutelparen verspreid over servers en serviceaccounts, een systeem dat onbeheerd veel gemakkelijker groeit dan toegang op basis van certificaten.
• PGP Het is afhankelijk van het correct beheren van de eigen privésleutels door individuele gebruikers en van een vertrouwensnetwerk zonder centrale instantie die sleutels kan intrekken.
• S / MIME is afhankelijk van dezelfde PKI- en CA-infrastructuur als TLS, uitgebreid naar individuele mailboxen.
• WireGuard Dit is afhankelijk van het distribueren en roteren van Curve25519-sleutelparen per peer, doorgaans buiten een gecentraliseerde PKI.

In de praktijk ligt het probleem bij het protocol zelf zelden; het zit hem eerder in de sleutelbeheerlaag eronder. Een organisatie kan overal TLS 1.3 gebruiken en toch kwetsbaar blijven als certificaten handmatig worden vernieuwd en er ongemerkt iets verloopt, of als SSH-sleutels van een medewerker die twee jaar geleden is vertrokken nog steeds geautoriseerd zijn op productieservers.

Implementatievoorbeelden

Een openbare e-commercewebsite beëindigt TLS 1.3 bij de load balancer, ondersteund door certificaten die automatisch worden uitgegeven en vernieuwd via een beheerde PKI. TLS 1.2 blijft alleen beschikbaar voor het kleine deel van de oudere clients die geen TLS 1.3 kunnen onderhandelen. Twee datacenters, verbonden door een permanente link, gebruiken IPsec in tunnelmodus met IKEv2, waardoor elk pakket tussen hen op netwerkniveau wordt versleuteld, ongeacht welke applicatie het heeft gegenereerd. Een platformteam geeft engineers SSH-toegang tot productiehosts via een bastionhost die kortstondige certificaten uitgeeft in plaats van statische sleutels, waarmee het meest voorkomende probleem van SSH-sleutelwildgroei wordt opgelost. Een juridisch team versleutelt en ondertekent correspondentie met cliënten met S/MIME-certificaten die zijn uitgegeven door de eigen PKI van het bedrijf, zodat ontvangers de afzender kunnen verifiëren zonder handmatig sleutels uit te wisselen. Medewerkers die op afstand werken, maken verbinding met het bedrijfsnetwerk via WireGuard in plaats van een zwaardere IPsec-client, waarbij ze de configureerbare versleutelingsflexibiliteit inruilen voor een kleinere, snellere en gemakkelijker te controleren verbinding.

Beperkingen

Geen enkel encryptieprotocol beschermt gegevens zodra deze aan het eindpunt zijn gedecodeerd; TLS beschermt gegevens tijdens de overdracht, niet de onversleutelde tekst die zich in het servergeheugen of een applicatielogboek bevindt. De sterkte van een protocol is ook afhankelijk van de configuratie: een slecht geconfigureerde TLS 1.3 (bijvoorbeeld met een zwakke of ongeldige certificaatketen) biedt minder echte bescherming dan een correct geconfigureerde TLS 1.2-implementatie. Geen van deze protocollen pakt het probleem van een gecompromitteerde sleutel achteraf aan; als een privésleutel wordt gestolen, is elke sessie die ermee is geauthenticeerd achteraf verdacht totdat die sleutel is ingetrokken en vervangen. Ten slotte is protocolondersteuning niet universeel: oudere hardware, sommige IoT-apparaten en bepaalde gereguleerde omgevingen kunnen mogelijk niet direct overstappen op de huidige aanbevolen versie, waardoor een gedocumenteerd plan voor compenserende maatregelen en migratie noodzakelijk is in plaats van optioneel.

Wat zou Encryption Consulting aanbevelen?

De meeste organisaties waarmee we samenwerken, hebben niet zozeer een protocolprobleem, maar eerder een probleem met zichtbaarheid en de levenscyclus van certificaten: TLS 1.3 is vrijwel overal de juiste keuze, maar de bijbehorende certificaten verlopen ongemerkt, SSH-sleutels hopen zich op zonder eigenaar en IPsec-configuraties wijken in de loop der tijd af van hun oorspronkelijke beveiligingsniveau. Ons team van Encryption Advisory begint elke protocolbeoordeling met een grondige analyse van uw omgeving en vertaalt de bevindingen vervolgens naar een herstelplan in plaats van een algemene checklist met best practices. Voor de certificaten die ten grondslag liggen aan TLS en S/MIME automatiseert CertSecure Manager de uitgifte, verlenging en intrekking, waardoor verlopende certificaten geen handmatige taak meer zijn. Voor de PKI zelf kan ons PKI Services- team de CA-hiërarchie en de CP/CPS-documentatie ontwerpen of herbouwen waarop elk certificaatgebaseerd protocol op deze pagina is gebaseerd. Als uw organisatie nog steeds SSLv3, TLS 1.0/1.1 of IKEv1 gebruikt in productie, is dat geen project voor de toekomst, maar een actuele, kwetsbare lacune die we dit kwartaal moeten dichten.

Conclusie

Versleutelingsprotocollen zijn de regels die versleutelingsalgoritmen omzetten in werkende beveiligingssystemen: TLS/SSL voor webverkeer tussen client en server, IPsec voor netwerktunnels, SSH voor beheer op afstand, PGP en S/MIME voor e-mail en WireGuard voor lichte, moderne VPN's. De juiste keuze hangt af van de toepassing, niet van welk protocol het sterkst klinkt, en elk protocol is afhankelijk van een sleutelbeheer- of PKI-laag om de beveiligingsbelofte daadwerkelijk waar te maken. Houd verouderde versies, zoals SSLv3, TLS 1.0/1.1 en IKEv1, buiten productieomgevingen, stel een gedocumenteerde minimale geaccepteerde versie in voor elk protocol dat u gebruikt en beschouw certificaat- en sleutellevenscyclusbeheer als onderdeel van het protocol, niet als een bijzaak.

FAQ

Is TLS hetzelfde als SSL?
Nee. SSL was de voorganger van TLS en elke versie van SSL, inclusief SSLv3, is nu verouderd (RFC 7568). "SSL" wordt in marketing en documentatie nog steeds informeel gebruikt als synoniem voor "TLS", maar geen enkele huidige implementatie zou daadwerkelijk het SSL-protocol moeten gebruiken.

Moet ik TLS 1.2 uitschakelen nu TLS 1.3 bestaat?
Niet per se. TLS 1.2, correct geconfigureerd met AEAD-coderingssuites, is nog steeds een geaccepteerd minimum volgens NIST SP 800-52 Rev. 2. Schakel TLS 1.0/1.1 en SSLv3 uit, maar houd TLS 1.2 beschikbaar als terugvaloptie totdat u hebt bevestigd dat elke client die u moet ondersteunen TLS 1.3 kan onderhandelen.

Is WireGuard veilig genoeg om IPsec te vervangen?
Voor veel toepassingen met toegang op afstand en site-to-site-verbindingen is het antwoord ja. De vaste, moderne cipher suite en de kleine codebase van WireGuard maken het eenvoudiger te controleren dan een volledige IPsec-stack. Het nadeel is dat IPsec bredere ondersteuning van leveranciers en apparaten biedt, evenals configureerbare cipher flexibiliteit, wat in sommige gereguleerde of verouderde omgevingen nog steeds vereist is.

Waarom heeft SSH drie aparte RFC's nodig in plaats van één?
De transport-, authenticatie- en verbindingsfuncties van SSH zijn bewust gelaagd, zodat ze elk onafhankelijk van elkaar kunnen evolueren. RFC 4253 (transport), RFC 4252 (authenticatie) en RFC 4254 (verbinding) zijn allemaal gebaseerd op de basisarchitectuur in RFC 4251, waardoor authenticatiemethoden kunnen veranderen zonder het onderliggende versleutelde transport aan te tasten.

Is de keuze voor het 'meest veilige' protocol belangrijker dan sleutelbeheer?
Nee. Uit onze beoordelingen blijkt dat verkeerde protocolconfiguratie en onbeheerde sleutels of certificaten in de praktijk veel meer risico's met zich meebrengen dan de keuze van het algoritme binnen een modern protocol. Een correct beheerde TLS 1.2-implementatie is in de praktijk veiliger dan een TLS 1.3-implementatie met verlopen certificaten of zwakke sleutelopslag.

Referenties

• IETF, RFC 8446: Het Transport Layer Security (TLS) protocol versie 1.3
• IETF, RFC 8996: TLS 1.0 en TLS 1.1 worden afgekeurd.
• IETF, RFC 7568: Secure Sockets Layer versie 3.0 wordt afgekeurd.
• IETF, RFC 7296: Internet Key Exchange Protocol Versie 2 (IKEv2)
• IETF, RFC 9395: Uitfasering van het Internet Key Exchange Version 1 (IKEv1)-protocol en verouderde algoritmen
• IETF, RFC 4251: De architectuur van het Secure Shell (SSH) protocol
• IETF, RFC 4253: Het Secure Shell (SSH) Transport Layer Protocol
• IETF, RFC 9580: OpenPGP
• IETF, RFC 8551: S/MIME Versie 4.0 Berichtspecificatie
• NIST-onderzoek SP 800-52 Revisie 2: Richtlijnen voor TLS-implementaties
• draadwacht, WireGuard: De volgende generatie kernelnetwerktunnel