Vad är krypteringsprotokoll och hur fungerar de?

Publicerad: maj 2021. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI-rådgivningsteam.

Kryptering omvandlar läsbar data till chiffertext, men kryptering ensamt talar inte om för två datorer hur de ska komma överens om en nyckel, verifiera varandras identitet eller strukturera de krypterade bytena på kabeln. Det är uppgiften för ett krypteringsprotokoll. Varje säker anslutning du förlitar dig på, en webbläsarsession, en VPN-tunnel, en SSH-inloggning, ett signerat e-postmeddelande, är byggt på ett namngivet protokoll som anger exakt hur kryptering används, inte bara vilken algoritm som gör beräkningarna. Att välja fel protokoll, eller en föråldrad version av rätt algoritm, är en av de vanligaste luckorna som våra krypteringsrådgivningsuppdrag hittar under arkitekturgranskningar.

Vad är skillnaden mellan ett krypteringsprotokoll och en krypteringsalgoritm?

En krypteringsalgoritm är en specifik matematisk procedur, såsom AES , RSA eller ECDSA, som omvandlar klartext till chiffertext, genererar en digital signatur eller producerar en hash. En algoritm har i sig ingen åsikt om hur två parter hittar varandra, kommer överens om vilken algoritm som ska användas, utbyter nycklar säkert eller upptäcker ett manipulerat meddelande.

Ett protokoll är den regelbok som lindar in en eller flera algoritmer i ett fungerande säkerhetssystem för ett specifikt ändamål. TLS 1.3, definierat i RFC 8446 , specificerar exakt vilka handskakningsmeddelanden en klient och server utväxlar, vilka krypteringssviter som är tillåtna, hur sessionsnyckeln härleds och hur anslutningen autentiseras med ett certifikat. Byt ut AES mot ChaCha20-Poly1305 i samma TLS 1.3-handskakning och protokollet har inte ändrats, bara algoritmen som protokollet förhandlade fram. Den skillnaden är viktig operativt: en protokollversion kan vara föråldrad även om varje algoritm inuti den fortfarande anses vara stark, eftersom själva förhandlingslogiken har en brist (detta är exakt vad som hände med SSLv3, diskuteras nedan).

Vid sidan av de flesta asymmetriska protokoll fungerar Public Key Infrastructure (PKI) . En PKI utfärdar de digitala certifikat som TLS, IPsec och S/MIME använder för att binda en offentlig nyckel till en identitet, så protokollets handskakning har något pålitligt att kontrollera mot en förtroendekedja tillbaka till en certifikatutfärdare . Utan det identitetslagret kan ett protokoll fortfarande kryptera en kanal, men det kan inte berätta vem som är i andra änden av den.

Vilka är de viktigaste krypteringsprotokollen och hur fungerar vart och ett?

TLS/SSL: Säkra klient-server-anslutningar

Transport Layer Security (TLS), efterföljaren till det äldre Secure Sockets Layer (SSL), är protokollet bakom hänglåsikonen och "https" i webbläsarens adressfält. TLS krypterar ingenting självt; det förhandlar om vilka algoritmer som ska göra det arbetet. En TLS-handskakning väljer protokollversionen, autentiserar servern (och eventuellt klienten) med ett X.509-certifikat, godkänner en chiffersvit och härleder en delad sessionsnyckel. TLS 1.3, standardiserad i RFC 8446 , minskade handskakningen till en tur och retur, tog bort stödet för statiskt RSA-nyckelutbyte och CBC-lägeschiffrar och begränsade förhandling till en kort lista över AEAD-chiffersviter. Se vår introduktion till chiffersviter för exakt vilka algoritmkombinationer TLS 1.2 och 1.3 tillåter och hur handskakningen förhandlar om dem.

IPsec: Kryptera nätverkstrafik och VPN-tunnlar

Internet Protocol Security (IPsec) säkrar trafik på nätverkslagret istället för applikationslagret, vilket gör det protokollagnostiskt: allt som körs på IP skyddas utan att applikationen behöver veta att kryptering sker. IPsec har två centrala delprotokoll, AH (Authentication Header) för integritet och ESP (Encapsulating Security Payload) för konfidentialitet plus integritet, och två lägen: transportläge, som endast krypterar paketets nyttolast, och tunnelläge, som krypterar hela originalpaketet inklusive dess header. Tunnelläge är vad de flesta VPN-tjänster för plats-till-plats och fjärråtkomst använder. Innan någon av dessa krypteringar kan ske behöver båda slutpunkterna en delad nyckel, vilket är där protokollet Internet Key Exchange (IKE) kommer in i bilden. IKEv2, definierat i RFC 7296 , förhandlar och uppdaterar dessa nycklar och är den nuvarande standarden; dess föregångare IKEv1 avskaffades formellt av RFC 9395 år 2023 och bör tas bort från alla konfigurationer som fortfarande kör det.

SSH: Säkra fjärradministration

Secure Shell (SSH) skyddar interaktiva fjärrinloggningar, filöverföringar och portvidarebefordran. Dess arkitektur, som beskrivs i RFC 4251 , är uppdelad i tre lager, vart och ett med sin egen RFC: transportlagret ( RFC 4253 ) förhandlar algoritmerna och etablerar en krypterad, integritetskontrollerad kanal med hjälp av ett Diffie-Hellman-nyckelutbyte; användarautentiseringslagret ( RFC 4252 ) verifierar klientens identitet, vanligtvis med en offentlig nyckel snarare än ett lösenord; och anslutningslagret ( RFC 4254 ) multiplexerar den krypterade transporten till flera logiska kanaler för skal, filöverföringar och vidarebefordrade portar. Eftersom SSH-åtkomst vanligtvis autentiseras med långlivade nyckelpar snarare än certifikat som löper ut, är en ohanterad SSH-nyckelfastighet ett vanligt granskningsresultat; detta är just vad SSH-nyckellivscykelverktyg är byggda för att åtgärda.

PGP och S/MIME: Kryptera och signera e-post

OpenPGP och S/MIME krypterar och signerar e-post digitalt, men de bygger förtroende på olika sätt. OpenPGP, som för närvarande specificeras i RFC 9580 (vilket föråldrar den äldre RFC 4880), förlitar sig på ett decentraliserat förtroendenät där användare signerar varandras nycklar direkt. S/MIME, som specificeras i RFC 8551 , förlitar sig istället på X.509-certifikat utfärdade av en CA, vilket gör det till en mer naturlig lösning för organisationer som redan kör en PKI för andra ändamål. Båda protokollen ger konfidentialitet och oavvislighet för en meddelandetext; inget av dem skyddar e-postrubriker, routingmetadata eller meddelanden när de har dekrypterats och finns i en inkorg.

WireGuard: Ett lätt och modernt VPN-protokoll

WireGuard är ett nyare VPN-protokoll byggt kring en fast, minimal kryptografisk svit (Curve25519 för nyckelutbyte, ChaCha20-Poly1305 för kryptering, BLAKE2s för hashing) istället för IPsecs förhandlingsbara chifferlista. Den bygger sin handskakning på Noise Protocol Framework , och dess fullständiga design är dokumenterad i dess egen tekniska whitepaper snarare än en IETF RFC. Eftersom den inte förhandlar om algoritmer finns det ingen äldre chiffer-fallback för att felkonfigurera, vilket är en stor del av anledningen till att WireGuard-konfigurationer tenderar att vara mindre och enklare att granska än en motsvarande IPsec-installation. Avvägningen är mindre flexibilitet: om en komponent i WireGuards fasta svit någonsin bryts, behöver protokollet en ny version snarare än en konfigurationsändring.

Kerberos: Nätverksautentisering

Kerberos är ett ärendebaserat autentiseringsprotokoll, mest känt som ryggraden i Windows Active Directory-inloggningar. Ett centralt Key Distribution Center autentiserar en användare en gång och utfärdar ett tidsbegränsat ärende, som användaren sedan presenterar för enskilda tjänster istället för att autentisera om till var och en. Kerberos är byggt för betrodda interna nätverk och Active Directory; det är inte en ersättning för TLS, IPsec eller SSH på trafik som korsar ett opålitligt nätverk.

Vilket krypteringsprotokoll ska du använda för varje användningsfall?

Rätt protokoll följer direkt av vad du skyddar och vilka slutpunkterna är, inte av vilken som är "starkast" i abstrakt mening.

Användningsfall	Protokoll	Nuvarande rekommenderad version	Status
Webb- och API-trafik (klient-server)	TLS / SSL	TLS 1.3 (RFC 8446); TLS 1.2 acceptabelt minimum	TLS 1.0/1.1 och SSLv3 är föråldrade
Plats-till-plats-VPN, tunnlar på nätverksnivå	IPsec	IKEv2 (RFC 7296)	IKEv1 föråldrad (RFC 9395)
Interaktiv fjärradministrering, filöverföring	SSH	SSH-2 (RFC 4251-4254)	SSH-1 föråldrad, använd inte
E-postkonfidentialitet, organisationshanterad PKI	S / MIME	S/MIME 4.0 (RFC 8551)	Aktuella
E-postkonfidentialitet, decentraliserat förtroende	OpenPGP	RFC 9580	Nuvarande; RFC 4880 föråldrad
Lätt VPN för fjärråtkomst/plats	WireGuard	Åtgärdade krypteringspaket enligt WireGuard-vitboken	Aktuella
Intern AD-autentisering	Kerberos	Kerberos 5 (RFC 4120)	Gäller endast för betrodda interna nätverk

Några praktiska regler följer av den här tabellen. Offentliga webb- och API-slutpunkter bör avsluta TLS 1.3 där klientstödet tillåter, och inte falla tillbaka lägre än TLS 1.2. Plats-till-plats-anslutningar mellan datacenter eller moln-VPC:er passar vanligtvis bättre för IPsec/IKEv2, eftersom det fungerar under applikationslagret och integreras med befintlig router- och brandväggsinfrastruktur. Enskilda användare som ansluter till interna resurser från ohanterade nätverk betjänas ofta bättre av WireGuard eller en IPsec-klient, inte rå SSH-tunnling, som är avsedd för administrativ åtkomst snarare än allmänt nätverk. Valet mellan S/MIME och OpenPGP för e-post beror vanligtvis på om organisationen redan använder en PKI: om den gör det återanvänder S/MIME den investeringen; om publiken är extern och decentraliserad kan OpenPGP:s Web of Trust vara den mer praktiska lösningen.

Hotmodell och föråldrade protokoll att undvika

Varje protokoll ovan förutsätter en aktiv nätverksmotståndare som kan läsa, modifiera, injicera och spela upp paket, inte bara en passiv avlyssnare. Det antagandet är anledningen till att versionsförhandling i sig är en säkerhetskritisk del av dessa protokoll: en angripare som kan tvinga fram en nedgradering till en svagare version kan ofta omintetgöra kryptering utan att förstöra någon algoritm alls. Flera protokollversioner har formellt föråldrats av just denna anledning och bör inaktiveras överallt där de fortfarande är konfigurerade:

• SSLv3 blev avskriven av RFC 7568 efter att POODLE padding-oracle-attacken visade att den på ett tillförlitligt sätt kunde nedgraderas till och brytas.
• TLS 1.0 och TLS 1.1 blev avskrivna av RFC 8996 år 2021, på grund av beroende av svaga MD5/SHA-1-konstruktioner och svagheter i CBC-läge utan någon fungerande säker konfiguration.
• IKEv1 blev avskriven av RFC 9395 år 2023 tillsammans med en uppsättning föråldrade IPsec-algoritmer.
• SSH-protokoll version 1 har kända kryptografiska svagheter och har ersatts av SSH-2 i nästan två decennier; vilken server som helst som fortfarande erbjuder det är ett kritiskt fynd i varje bedömning.

NIST:s riktlinjer för federala TLS-distributioner, SP 800-52 Revision 2 , kräver TLS 1.2 som golv och riktar myndigheter mot TLS 1.3, vilket återspeglar samma logik: en protokollversion förblir acceptabel endast så länge ingen praktisk nedgradering eller kryptografisk attack mot den existerar.

Så härdar du din krypteringsprotokollkonfiguration

1. Inventera alla protokoll och versioner som används. Skanna externa och interna slutpunkter efter de TLS-versioner, IKE-versioner och SSH-versioner som de för närvarande accepterar, inte bara den version du avser att köra.
2. Inaktivera föråldrade versioner på konfigurationsnivå. Ta bort SSLv3, TLS 1.0/1.1, IKEv1 och SSH-1 från server- och lastbalanseringskonfigurationer; förlita dig inte på att klienter helt enkelt "inte väljer" ett svagt alternativ under förhandlingar.
3. Ange en lägsta accepterade version, inte bara en föredragen. Konfigurera TLS 1.2 som våning med TLS 1.3 som prioritet och bekräfta att servern faktiskt avvisar tidigare handskakningar snarare än att bara lista dem som lågprioriterade.
4. Begränsa förhandling av krypteringssviter till AEAD-sviter. Ta bort CBC-läge och RC4-sviter från alla TLS 1.2-konfigurationer som fortfarande måste stödja det; se guide till chiffersviter för en scenariobaserad lista med rekommenderade alternativ.
5. Verifiera certifikat och nyckelhygien för varje protokoll. Bekräfta att TLS- och S/MIME-certifikat är kedjade till en betrodd rot och att de inte snart har löpt ut, och att SSH-auktoriserade nyckelfiler inte innehåller överblivna eller ohanterade nycklar.
6. Testa igen efter varje byte. Skanna samma slutpunkter igen för att bekräfta att den föråldrade versionen faktiskt är borta från serverns förhandlade handskakning, inte bara från en konfigurationsfil som aldrig laddades om.

Avvägningar mellan prestanda och interoperabilitet

Protokollval handlar sällan bara om säkerhetsmarginal; det har också en verklig driftskostnad. TLS 1.3:s handskakning med en enda tur och retur minskar anslutningslatensen jämfört med TLS 1.2, vilket är viktigt vid miljontals dagliga anslutningar, men äldre klienter, vissa äldre lastbalanserare och vissa mellanboxar för djup paketinspektion stöder fortfarande bara TLS 1.2, vilket tvingar många publika tjänster att hålla en TLS 1.2-reservväg tillgänglig. IPsecs förhandlingsbara chifferlista ger bred interoperabilitet mellan leverantörers hårdvara, på bekostnad av en större attackyta från äldre algoritmalternativ som aktivt måste beskäras. WireGuards fasta chiffersvit tar bort den förhandlingskostnaden och håller paketkostnaden låg, vilket är anledningen till att den presterar bra på mobila och begränsade nätverk, men den kan inte falla tillbaka till äldre algoritmer om en klient inte kan stödja den nuvarande sviten, och den saknar det leverantörs- och apparatekosystem som IPsec har byggt upp under två decennier. SSH:s multiplexering per kanal är effektiv för interaktiva sessioner men är inte utformad för bulkkryptering av nätverkslagret, vilket är anledningen till att den inte bör användas som en generell VPN-ersättning även om ett "fattigmans-VPN" över SSH-tunnling är tekniskt möjligt.

Nyckelhanteringsberoenden för varje protokoll

Inget protokoll på den här listan är säkert utan ett fungerande nyckelhanteringsprogram bakom sig, och vart och ett är beroende av en annan typ av nyckelinfrastruktur:

• TLS / SSL är beroende av en PKI som utfärdar, förnyar och återkallar X.509-certifikat innan de löper ut eller komprometteras, fungerar vårt CertSecure-hanterare plattformen automatiserar över stora certifikattillgångar.
• IPsec beror på fördelade nycklar eller certifikatbaserad autentisering för sin IKE-fas, och på periodisk omnyckling för att begränsa mängden trafik som skyddas av en enskild nyckel.
• SSH är beroende av att hantera potentiellt tusentals långlivade, icke-utgångna nyckelpar över servrar och tjänstkonton, en tillgång som växer ohanterad mycket lättare än certifikatbaserad åtkomst.
• PGP beror på att enskilda användare korrekt hanterar sina egna privata nycklar och ett nätverk av förtroende utan central återkallningsbehörighet.
• S / MIME är beroende av samma PKI- och CA-infrastruktur som TLS, utökad till enskilda postlådor.
• WireGuard beror på att distribuera och rotera Curve25519-nyckelpar per peer, vanligtvis utanför en centraliserad PKI.

I praktiken är det sällan protokollet som får ett krypteringsprogram att misslyckas; det är nyckelhanteringslagret under det. En organisation kan köra TLS 1.3 överallt och fortfarande vara exponerad om certifikatförnyelsen sker manuellt och något går ut obemärkt, eller om SSH-nycklar från en anställd som slutade för två år sedan fortfarande är auktoriserade på produktionsservrar.

Implementeringsexempel

En offentlig e-handelssajt avslutar TLS 1.3 vid sin lastbalanserare, med stöd av certifikat som utfärdas och förnyas automatiskt via en hanterad PKI, där TLS 1.2 endast är tillgängligt för den lilla andelen äldre klienter som inte kan förhandla om 1.3. Två datacenter som är anslutna via en permanent länk kör IPsec i tunnelläge med IKEv2, så varje paket mellan dem krypteras på nätverkslagret oavsett vilken applikation som genererade det. Ett plattformsteam ger ingenjörer SSH-åtkomst till produktionsvärdar via en bastionvärd som utfärdar kortlivade certifikat istället för statiska nycklar, vilket åtgärdar det vanligaste fallet med SSH-nyckelspridning. Ett juridiskt team krypterar och signerar klientkorrespondens med S/MIME-certifikat som utfärdats från företagets egen PKI, så att mottagare kan verifiera avsändaren utan att byta nycklar manuellt. En distansarbetsstyrka ansluter till företagets nätverk via WireGuard snarare än en tyngre IPsec-klient och byter konfigurerbar chifferflexibilitet mot en mindre, snabbare och lättare att granska anslutning.

Begränsningar

Inget krypteringsprotokoll skyddar data när de väl dekrypteras vid en slutpunkt; TLS skyddar data under överföring, inte klartexten som finns i serverminnet eller en applikationslogg efteråt. Protokollstyrkan är också relativ till konfigurationen: TLS 1.3 som är dåligt felkonfigurerad (till exempel med en svag eller ogiltig certifikatkedja) erbjuder mindre verkligt skydd än en korrekt konfigurerad TLS 1.2-distribution. Inget av dessa protokoll åtgärdar nyckelkompromettering i efterhand, om en privat nyckel blir stulen, är varje session som autentiserats retroaktivt misstänkt tills nyckeln återkallas och ersätts. Slutligen är protokollstöd inte universellt: äldre hårdvara, vissa IoT-enheter och vissa reglerade miljöer kanske inte kan gå över till den aktuella rekommenderade versionen omedelbart, vilket gör en dokumenterad kompenserande kontroll- och migreringsplan nödvändig snarare än valfri.

Vad skulle krypteringskonsulter rekommendera?

De flesta organisationer vi arbetar med har inte så mycket ett protokollproblem som ett problem med synlighet och livscykel: TLS 1.3 är rätt val nästan överallt, men certifikaten bakom det förfaller obemärkt, SSH-nycklar ackumuleras utan ägare och IPsec-konfigurationer glider från sin ursprungliga härdningsbaslinje över tid. Vårt krypteringsrådgivningsteam börjar varje protokollgranskning med en identifieringsövergång över din miljö och mappar sedan resultaten till en åtgärdsplan snarare än en generisk checklista för bästa praxis. För certifikatinnehav bakom TLS och S/MIME automatiserar CertSecure Manager utfärdande, förnyelse och återkallelse så att utgångna certifikat slutar vara en manuell spårningsövning. För själva PKI:n kan vårt PKI-tjänsteteam designa eller återuppbygga CA-hierarkin och CP/CPS-dokumentationen som varje certifikatbaserat protokoll på den här sidan är beroende av. Om din organisation fortfarande använder SSLv3, TLS 1.0/1.1 eller IKEv1 någonstans i produktion är det inte ett framtida projekt, det är ett aktuellt, utnyttjande gap som är värt att täcka detta kvartal.

Slutsats

Krypteringsprotokoll är regelböckerna som förvandlar krypteringsalgoritmer till fungerande säkerhetssystem: TLS/SSL för klient-server-webbtrafik, IPsec för tunnlar på nätverkslagret, SSH för fjärradministration, PGP och S/MIME för e-post och WireGuard för lätta moderna VPN-tjänster. Rätt val beror på användningsfallet, inte på vilket protokoll som låter starkast, och vart och ett av dem är beroende av ett nyckelhanterings- eller PKI-lager för att faktiskt leverera sitt säkerhetslöfte. Håll föråldrade versioner, SSLv3, TLS 1.0/1.1 och IKEv1, ur produktion, ange en dokumenterad lägsta accepterade version för varje protokoll du kör och behandla certifikat- och nyckellivscykelhantering som en del av protokollet, inte en eftertanke.

FAQ

Är TLS samma sak som SSL?
Nej. SSL var TLS föregångare och alla versioner av SSL, inklusive SSLv3, är nu föråldrade (RFC 7568). ”SSL” används fortfarande informellt i betydelsen ”TLS” i marknadsföring och dokumentation, men ingen nuvarande implementering bör faktiskt köra SSL-protokollet.

Borde jag inaktivera TLS 1.2 nu när TLS 1.3 finns?
Inte nödvändigtvis. TLS 1.2, korrekt konfigurerad med AEAD-krypteringssviter, är fortfarande ett accepterat minimum enligt NIST SP 800-52 Rev. 2. Inaktivera TLS 1.0/1.1 och SSLv3, men håll TLS 1.2 tillgängligt som reserv tills du har bekräftat att alla klienter du måste stödja kan förhandla om TLS 1.3.

Är WireGuard tillräckligt säkert för att ersätta IPsec?
För många användningsområden för fjärråtkomst och plats-till-plats-användning, ja. WireGuards fasta, moderna chiffersvit och lilla kodbas gör det enklare att granska än en fullständig IPsec-stack. Avvägningen är att IPsec har bredare leverantörs- och apparatstöd och konfigurerbar chifferflexibilitet som vissa reglerade eller äldre miljöer fortfarande kräver.

Varför behöver SSH tre separata RFC:er istället för en?
SSH:s transport-, autentiserings- och anslutningsfunktioner är avsiktligt lagerlagda så att var och en kan utvecklas oberoende av varandra. RFC 4253 (transport), RFC 4252 (autentisering) och RFC 4254 (anslutning) ligger alla ovanpå basarkitekturen i RFC 4251, vilket låter autentiseringsmetoder ändras utan att den krypterade transporten underliggande ändras.

Är det viktigare att välja det "säkraste" protokollet än att hantera nyckelringar?
Nej. Enligt våra bedömningar orsakar felaktig protokollkonfiguration och ohanterade nycklar eller certifikat betydligt mer exponering i verkligheten än valet av algoritm i ett modernt protokoll. En korrekt hanterad TLS 1.2-distribution är säkrare i praktiken än en TLS 1.3-distribution med utgångna certifikat eller svag nyckellagring.

Referensprojekt

• IETF, RFC 8446: Transport Layer Security (TLS)-protokollet version 1.3
• IETF, RFC 8996: Avveckling av TLS 1.0 och TLS 1.1
• IETF, RFC 7568: Avveckling av Secure Sockets Layer version 3.0
• IETF, RFC 7296: Internet Key Exchange Protocol version 2 (IKEv2)
• IETF, RFC 9395: Utfasning av protokollet Internet Key Exchange version 1 (IKEv1) och föråldrade algoritmer
• IETF, RFC 4251: Protokollarkitekturen för Secure Shell (SSH)
• IETF, RFC 4253: Secure Shell (SSH) transportlagerprotokoll
• IETF, RFC 9580: OpenPGP
• IETF, RFC 8551: Meddelandespecifikation för S/MIME version 4.0
• NIST, SP 800-52 Revision 2: Riktlinjer för TLS-implementeringar
• trådskydd, WireGuard: Nästa generations kärnnätverkstunnel