{"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://atlas.maintz.dev/)"},"id":"cs/tls","url":{"en":"https://atlas.maintz.dev/en/terms/cs/tls/","da":"https://atlas.maintz.dev/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."},"howTo":{"steps":{"en":["List every service that speaks TLS - web servers, load balancers, mail servers, VPN gateways, databases, APIs and internal service-to-service links - with its owner, TLS library and certificate.","Set a TLS baseline in writing, for example TLS 1.3 preferred, TLS 1.2 only with ECDHE and AEAD cipher suites, and SSL 3.0, TLS 1.0 and TLS 1.1 switched off.","Apply the baseline on each server using a vetted configuration template, such as the Mozilla-derived Intermediate profile, instead of hand-picking cipher lists.","Use certificates with at least RSA 2048-bit or ECDSA P-256 keys, correct names in subjectAltName and a complete chain, and add CAA records in DNS that name the CAs allowed to issue for your domains.","Keep a certificate inventory with expiry dates, automate renewal, and alert well before any certificate expires.","Encrypt internal traffic too, and use mutual TLS where services must prove to each other who they are, with certificates from an internal CA.","Make sure client programs and scripts validate certificates, and remove any setting that turns validation off.","Test every public endpoint with a TLS scanner after each change and at least quarterly, keep the TLS libraries patched, and update the baseline when guidance changes, including the move to post-quantum key exchange."],"da":["Lav en liste over alle tjenester, der bruger TLS - webservere, load balancere, mailservere, VPN-gateways, databaser, API'er og interne forbindelser mellem tjenester - med ejer, TLS-bibliotek og certifikat.","Skriv en TLS-baseline ned, fx TLS 1.3 som foretrukket, TLS 1.2 kun med ECDHE og AEAD-ciphersuites, og SSL 3.0, TLS 1.0 og TLS 1.1 slået fra.","Anvend baselinen på hver server ud fra en gennemprøvet konfigurationsskabelon, fx den Mozilla-baserede Intermediate-profil, i stedet for at vælge ciphersuites i hånden.","Brug certifikater med mindst RSA 2048-bit- eller ECDSA P-256-nøgler, korrekte navne i subjectAltName og en komplet kæde, og tilføj CAA-records i DNS, der angiver, hvilke CA'er der må udstede til jeres domæner.","Hold en oversigt over certifikater med udløbsdatoer, automatisér fornyelsen, og alarmér i god tid, før et certifikat udløber.","Kryptér også intern trafik, og brug mutual TLS, hvor tjenester skal bevise over for hinanden, hvem de er, med certifikater fra en intern CA.","Sørg for, at klientprogrammer og scripts validerer certifikater, og fjern enhver indstilling, der slår valideringen fra.","Test alle offentlige endpoints med en TLS-scanner efter hver ændring og mindst hvert kvartal, hold TLS-bibliotekerne patchet, og opdatér baselinen, når vejledningen ændres, også ved overgangen til kvantesikker nøgleudveksling."]},"pitfalls":{"en":["Turning off certificate validation in code or scripts to get past an error, which silently removes all protection against a man in the middle.","Keeping TLS 1.0 or weak cipher suites switched on for one old client and forgetting them for years.","Forgetting certificates on internal systems and appliances, so they expire unnoticed and stop a critical service."],"da":["At slå certifikatvalidering fra i kode eller scripts for at komme forbi en fejl, hvilket i det stille fjerner al beskyttelse mod en man-in-the-middle.","At lade TLS 1.0 eller svage ciphersuites være slået til for én gammel klient og glemme dem i årevis.","At glemme certifikater på interne systemer og appliances, så de udløber ubemærket og stopper en kritisk tjeneste."]},"guides":[{"title":"NIST SP 800-52 Rev. 2 - Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations","url":"https://csrc.nist.gov/pubs/sp/800/52/r2/final","publisher":"NIST","tier":"standard"},{"title":"RFC 9325 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)","url":"https://www.rfc-editor.org/rfc/rfc9325","publisher":"IETF","tier":"standard"},{"title":"Transport Layer Security Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"},{"title":"Sikker brug af Transport Layer Security (TLS)","url":"https://samsik.dk/publikation/sikker-brug-af-transport-layer-security-tls/","publisher":"Styrelsen for Samfundssikkerhed","tier":"official-doc","lang":"da"}]},"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}