TLS

TLS består af en record-protokol, der deler applikationsdata op, beskytter hver record med en AEAD-algoritme og nonces baseret på sekvensnumre, og en række underprotokoller, der bæres i records: håndtrykket, alerts og, i ældre versioner, change cipher spec. Slægtslinjen går fra Netscapes SSL 2.0 (1995) og SSL 3.0 (1996) over TLS 1.0 (RFC 2246, 1999), 1.1 (RFC 4346, 2006) og 1.2 (RFC 5246, 2008) til TLS 1.3 (RFC 8446, 2018). RFC 8996 (2021) udfasede formelt TLS 1.0 og 1.1, og RFC 9325 giver de gældende anbefalinger til konfiguration. DTLS overfører samme design til UDP; DTLS 1.3 er RFC 9147.

I det fulde TLS 1.3-håndtryk (RFC 8446 §2) sender klienten en ClientHello med understøttede cipher suites, en key_share med én eller flere flygtige (EC)DHE-offentlige nøgler, supported_versions og SNI. Serveren svarer med en ServerHello med sin egen key share; herfra udleder begge sider håndtryksnøgler via en HKDF-baseret key schedule, og resten af serverens svar - EncryptedExtensions, Certificate, CertificateVerify (en signatur over hele udvekslingen) og Finished - er allerede krypteret. Klienten verificerer kæden og sender sin Finished, og applikationsdata kan sendes efter én rundtur. Genoptagelse med en pre-shared key kan tilføje 0-RTT early data, som ikke er beskyttet mod genafspilning og kun må bruges til idempotente forespørgsler.

TLS 1.3 fjernede en lang række gamle funktioner, som var roden til tidligere angreb: statisk RSA-nøgletransport (oracle-angreb i Bleichenbacher-stil, ROBOT), CBC-baserede algoritmer (BEAST, Lucky Thirteen, POODLE mod SSL 3.0), RC4, komprimering (CRIME), genforhandling samt eksport-svage og selvdefinerede Diffie-Hellman-grupper (FREAK, Logjam). Der er kun fem cipher suites tilbage, alle AEAD, og hvert fuldt håndtryk giver forward secrecy. En nedgraderingsmarkør i de sidste otte byte af ServerHello.random (§4.1.3) lader en TLS 1.3-klient opdage, hvis en angriber tvinger en ældre version igennem. Heartbleed (2014) var derimod en implementeringsfejl i OpenSSL, ikke en fejl i protokollen.

Serverautentifikation afhænger af validering af X.509-certifikatet: en kæde til et betroet rodcertifikat, et navn, der passer til en subjectAltName-post, gyldighedsdatoer og kontrol af tilbagekaldelse, som i praksis er svag - én af grundene til, at CA/Browser Forum forkorter certifikaternes levetid. Mutual TLS tilføjer et klientcertifikat og er almindeligt mellem tjenester. Åbne problemer er de metadata, TLS efterlader synlige (IP-adresser, størrelser og SNI, medmindre Encrypted Client Hello, RFC 9849, er indført), og kvanterisikoen, som imødegås med den hybride nøgleudveksling X25519MLKEM768, som de store browsere og CDN'er allerede forhandler. Sammenlignet med en VPN sikrer TLS én applikationsforbindelse fra ende til ende ved grænsen mellem transport- og applikationslaget, mens en VPN tunnelerer al IP-trafik mellem en enhed og en netværksgateway; mange "SSL VPN"-produkter er i virkeligheden TLS, der bærer tunnelerede IP-pakker.