{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/tls","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/tls/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/tls/"},"term":{"en":"TLS","da":"TLS"},"aka":{"en":["Transport Layer Security"],"da":["Transport Layer Security"]},"domain":["cs"],"cluster":"networking","layer":"network","status":"current","era":1999,"summary":{"en":"The protocol that wraps data sent over TCP/IP in an encrypted channel after checking the other side's certificate.","da":"Protokollen, der lægger en krypteret kanal om data sendt over TCP/IP, efter at modpartens certifikat er kontrolleret."},"body":{"formal":{"en":"A protocol running on top of TCP/IP that first checks the other side's identity through its digital certificate, agrees on shared secret keys, and then uses encryption to keep data private and unaltered in transit. It replaced the older SSL; version 1.3 is current.","da":"En protokol oven på TCP/IP, der først kontrollerer modpartens identitet via dens digitale certifikat, aftaler fælles hemmelige nøgler og derefter bruger kryptering til at holde data hemmelige og sikre, at de ikke ændres undervejs. Den afløste den ældre SSL; version 1.3 er den gældende."},"plain":{"en":"Like sending your letters in a locked, sealed case, after first checking the person receiving it is really who they claim to be.","da":"Som at sende dine breve i en låst, forseglet kuffert efter først at have tjekket, at modtageren virkelig er den, de udgiver sig for."},"inPractice":{"en":"A municipality's IT operations manager is warned that the TLS certificate on the citizen self-service site expires in ten days; she renews it, since otherwise citizens' browsers would show a security warning and many would give up.","da":"En kommunes IT-driftsansvarlige får besked om, at TLS-certifikatet på borgernes selvbetjeningsside udløber om ti dage; hun fornyer det, for ellers ville borgernes browsere vise en sikkerhedsadvarsel, og mange ville give op."},"whyItMatters":{"en":"Without it, anyone on the same wifi or along the route could read or change passwords and personal data as they pass.","da":"Uden den kunne alle på det samme wifi eller langs ruten læse eller ændre adgangskoder og persondata, mens de passerer."}},"deepDive":{"en":"TLS consists of a record protocol, which fragments application data, protects each record with an AEAD cipher and sequence-number-based nonces, and several sub-protocols carried in records: the handshake, alerts and, in older versions, change cipher spec. The lineage runs from Netscape's SSL 2.0 (1995) and SSL 3.0 (1996) through TLS 1.0 (RFC 2246, 1999), 1.1 (RFC 4346, 2006) and 1.2 (RFC 5246, 2008) to TLS 1.3 (RFC 8446, 2018). RFC 8996 (2021) formally deprecated TLS 1.0 and 1.1, and RFC 9325 gives current configuration recommendations. DTLS adapts the same design to UDP; DTLS 1.3 is RFC 9147.\n\nIn the TLS 1.3 full handshake (RFC 8446 §2) the client sends a ClientHello with supported cipher suites, a key_share containing one or more ephemeral (EC)DHE public keys, supported_versions and SNI. The server replies with a ServerHello carrying its own key share; from that point both sides derive handshake keys via an HKDF-based key schedule, and the rest of the server's flight - EncryptedExtensions, Certificate, CertificateVerify (a signature over the transcript) and Finished - is already encrypted. The client verifies the chain, sends its Finished message, and application data flows after one round trip. Resumption with a pre-shared key can add 0-RTT early data, which is not protected against replay and must only be used for idempotent requests.\n\nTLS 1.3 removed a long list of legacy features that had been the root of earlier attacks: static RSA key transport (Bleichenbacher-style oracles, ROBOT), CBC-mode ciphers (BEAST, Lucky Thirteen, POODLE against SSL 3.0), RC4, compression (CRIME), renegotiation and export-grade and custom Diffie-Hellman groups (FREAK, Logjam). Only five cipher suites remain, all AEAD, and every full handshake has forward secrecy. A downgrade sentinel in the last eight bytes of ServerHello.random (§4.1.3) lets a TLS 1.3 client detect an attacker forcing an older version. Heartbleed (2014), by contrast, was an OpenSSL implementation bug, not a protocol flaw.\n\nServer authentication depends on X.509 certificate validation: a chain to a trusted root, a name matching a subjectAltName entry, validity dates, and revocation checking, which in practice is weak, one reason the CA/Browser Forum is shortening certificate lifetimes. Mutual TLS adds a client certificate and is common between services. Open problems include the metadata TLS leaves visible (IP addresses, sizes, and SNI unless Encrypted Client Hello, RFC 9849, is deployed) and quantum risk, addressed by the hybrid X25519MLKEM768 key exchange that major browsers and CDNs already negotiate. Compared with a VPN, TLS secures one application connection end to end at the transport/application boundary, while a VPN tunnels all IP traffic between a device and a network gateway; many \"SSL VPN\" products are in fact TLS carrying tunnelled IP packets.","da":"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.\n\nI 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.\n\nTLS 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.\n\nServerautentifikation 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."},"edges":[{"type":"requires","to":"cs/tcp-ip","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/encryption","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/digital-certificate","confidence":"high","strength":"normal"},{"type":"kind-of","to":"cs/protocol","confidence":"high","strength":"normal"},{"type":"implements","to":"security/confidentiality","confidence":"high","strength":"normal"},{"type":"implements","to":"security/integrity","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"cs/vpn","why":{"en":"TLS protects one program's connection to one service; a VPN wraps all of a device's traffic in a single protected tunnel.","da":"TLS beskytter ét programs forbindelse til én tjeneste; en VPN pakker al en enheds trafik ind i én beskyttet tunnel."},"confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/session-hijacking","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/man-in-the-middle","why":{"en":"Encryption plus a checked certificate means an attacker on the path can neither read nor quietly change the traffic.","da":"Kryptering og et kontrolleret certifikat betyder, at en angriber på vejen hverken kan læse eller i det stille ændre trafikken."},"confidence":"high","strength":"primary"}],"depth":4,"sources":[{"title":"Kurose & Ross, Computer Networking: A Top-Down Approach","tier":"textbook"},{"title":"RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3","tier":"standard"},{"title":"RFC 9849 - TLS Encrypted Client Hello","url":"https://www.rfc-editor.org/rfc/rfc9849","tier":"standard","publisher":"IETF"}],"draft":true}