{"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/https","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/https/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/https/"},"term":{"en":"HTTPS","da":"HTTPS"},"aka":{"en":["HTTP Secure","HTTP over TLS"],"da":["HTTP Secure","HTTP over TLS"]},"domain":["cs"],"cluster":"networking","layer":"network","status":"current","era":1994,"summary":{"en":"The way web browsers and websites exchange pages with TLS protecting every message, so no one on the way can read or change them.","da":"Måden, browsere og websteder udveksler sider på, hvor TLS beskytter hver besked, så ingen undervejs kan læse eller ændre dem."},"body":{"formal":{"en":"The web's request-and-answer protocol between a client and a server, carried inside a TLS connection, usually on port 443, so the pages, forms and cookies sent are encrypted and checked for changes.","da":"Webbens protokol for forespørgsel og svar mellem en klient og en server, båret inde i en TLS-forbindelse, typisk på port 443, så sider, formularer og cookies krypteres og tjekkes for ændringer."},"plain":{"en":"Like ordering from a shop by sealed, tamper-proof envelope instead of shouting your order and card number across the street.","da":"Som at bestille fra en butik i en forseglet konvolut, der ikke kan pilles ved, i stedet for at råbe sin bestilling og sit kortnummer over gaden."},"inPractice":{"en":"When a customer pays at a small Danish web shop whose address starts with https://, the card number travels encrypted from the browser to the shop's payment page, and anyone on the café wifi sees only scrambled data.","da":"Når en kunde betaler i en lille dansk webshop, hvis adresse starter med https://, rejser kortnummeret krypteret fra browseren til butikkens betalingsside, og andre på caféens wifi ser kun uforståelige data."},"whyItMatters":{"en":"Plain, unprotected web traffic can be read and changed by anyone along the route, so HTTPS is now the expected minimum for any website handling logins or personal data.","da":"Almindelig, ubeskyttet webtrafik kan læses og ændres af alle langs ruten, så HTTPS er i dag det forventede minimum for ethvert websted med login eller persondata."}},"deepDive":{"en":"HTTPS began with Netscape's SSL in the mid-1990s and was first written up as RFC 2818, HTTP Over TLS (2000); its rules now live in RFC 9110, which defines the https URI scheme and how the client must check the server's identity against the certificate. A typical HTTP/1.1 or HTTP/2 exchange is: resolve the name, open TCP to port 443, run a TLS handshake in which the ClientHello carries the hostname in the Server Name Indication extension (RFC 6066) and the protocol choice in ALPN (RFC 7301, for example h2 or http/1.1), validate the certificate chain and the subjectAltName, and only then send the HTTP request inside TLS records. HTTP/3 (RFC 9114) runs over QUIC on UDP 443, where TLS 1.3 is integrated into the transport handshake (RFC 9001); clients discover it through the Alt-Svc header or the HTTPS DNS record (RFC 9460).\n\nHTTPS encrypts the method, path, query string, headers, cookies and body, but not everything. The IP addresses, ports, timing and approximate sizes of messages stay visible, the DNS lookup leaks the name unless encrypted DNS is used, and the SNI field has traditionally been sent in clear text; Encrypted Client Hello, standardised as RFC 9849 in 2026, closes that gap where both browser and server support it. A valid certificate proves control of the domain, not honesty: phishing sites routinely obtain free domain-validated certificates through ACME (RFC 8555). Certificate Transparency logs let domain owners spot certificates issued for their names without their knowledge.\n\nThe weakest point is the transition from HTTP. If a user types a bare domain name, the first request may go out over plain HTTP, and an on-path attacker can keep the victim on HTTP while talking HTTPS to the real site (SSL stripping, demonstrated by Moxie Marlinspike in 2009). HTTP Strict Transport Security (RFC 6797) tells the browser to use only HTTPS for the domain for max-age seconds, optionally including subdomains, and the browser preload list removes even the first insecure request. Session cookies also need the Secure attribute, or they can leak over an HTTP request to the same host. Browsers block most mixed content and label HTTP pages \"Not secure\"; Chrome replaced the padlock with a neutral icon in 2023 precisely because users read it as a sign that a site is trustworthy.\n\nIn real deployments HTTPS often ends before the application does. CDNs and load balancers terminate TLS, and the hop to the origin server is only protected if it is re-encrypted; corporate TLS-inspection proxies deliberately break end-to-end encryption by installing their own root CA on managed devices. Operational checks therefore cover the whole chain: HTTP-to-HTTPS redirects and HSTS, disabled legacy protocol versions, certificate inventory and automated renewal (public certificate lifetimes are being cut in steps, to 200 days from March 2026), and encryption between internal tiers.","da":"HTTPS begyndte med Netscapes SSL i midten af 1990'erne og blev første gang beskrevet i RFC 2818, HTTP Over TLS (2000); reglerne findes nu i RFC 9110, som definerer URI-skemaet https, og hvordan klienten skal kontrollere serverens identitet mod certifikatet. En typisk udveksling med HTTP/1.1 eller HTTP/2 foregår sådan: Navnet slås op, der åbnes en TCP-forbindelse til port 443, og der køres et TLS-håndtryk, hvor ClientHello bærer værtsnavnet i udvidelsen Server Name Indication (RFC 6066) og protokolvalget i ALPN (RFC 7301, fx h2 eller http/1.1); certifikatkæden og subjectAltName valideres, og først derefter sendes HTTP-forespørgslen inde i TLS-records. HTTP/3 (RFC 9114) kører over QUIC på UDP 443, hvor TLS 1.3 er bygget ind i transportlagets håndtryk (RFC 9001); klienter opdager det via Alt-Svc-headeren eller DNS-posttypen HTTPS (RFC 9460).\n\nHTTPS krypterer metode, sti, forespørgselsstreng, headere, cookies og indhold, men ikke alt. IP-adresser, porte, timing og beskedernes omtrentlige størrelse er stadig synlige, DNS-opslaget afslører navnet, medmindre der bruges krypteret DNS, og SNI-feltet er traditionelt sendt i klartekst; Encrypted Client Hello, standardiseret som RFC 9849 i 2026, lukker det hul, hvor både browser og server understøtter det. Et gyldigt certifikat beviser kontrol over domænet, ikke hæderlighed: Phishing-sider får rutinemæssigt gratis domænevaliderede certifikater via ACME (RFC 8555). Certificate Transparency-logs gør det muligt for domæneejere at opdage certifikater, der er udstedt til deres navne uden deres vidende.\n\nDet svageste punkt er overgangen fra HTTP. Skriver brugeren blot domænenavnet, kan den første forespørgsel gå ud over almindelig HTTP, og en angriber på vejen kan holde offeret på HTTP, mens angriberen selv taler HTTPS med det rigtige websted (SSL stripping, demonstreret af Moxie Marlinspike i 2009). HTTP Strict Transport Security (RFC 6797) fortæller browseren, at domænet kun må tilgås over HTTPS i max-age sekunder, eventuelt inklusive subdomæner, og browsernes preload-liste fjerner selv den første usikre forespørgsel. Sessionscookies skal også have Secure-attributten, ellers kan de lække via en HTTP-forespørgsel til samme vært. Browsere blokerer det meste blandede indhold og mærker HTTP-sider \"Ikke sikker\"; Chrome udskiftede hængelåsen med et neutralt ikon i 2023, netop fordi brugerne læste den som et tegn på, at et websted er troværdigt.\n\nI virkelige installationer slutter HTTPS ofte, før applikationen gør. CDN'er og load balancere afslutter TLS, og strækningen til den bagvedliggende server er kun beskyttet, hvis den krypteres igen; virksomheders TLS-inspektionsproxyer bryder bevidst end-to-end-krypteringen ved at installere deres eget rodcertifikat på administrerede enheder. Driftstjek dækker derfor hele kæden: omdirigering fra HTTP til HTTPS og HSTS, deaktivering af gamle protokolversioner, certifikatoversigt og automatisk fornyelse (levetiden for offentlige certifikater skæres ned i trin, til 200 dage fra marts 2026) samt kryptering mellem de interne lag."},"edges":[{"type":"requires","to":"cs/tls","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/client","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/server","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/http","confidence":"high","strength":"normal"},{"type":"kind-of","to":"cs/protocol","confidence":"high","strength":"normal"},{"type":"implements","to":"security/confidentiality","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/session-hijacking","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/man-in-the-middle","why":{"en":"Web traffic locked with TLS and a checked certificate cannot be read or altered by someone sitting on the path.","da":"Webtrafik, der er beskyttet med TLS og et kontrolleret certifikat, kan ikke læses eller ændres af en, der sidder på vejen."},"confidence":"high","strength":"normal"}],"depth":5,"sources":[{"title":"RFC 9110 - HTTP Semantics","tier":"standard"},{"title":"Kurose & Ross, Computer Networking: A Top-Down Approach","tier":"textbook"},{"title":"RFC 9849 - TLS Encrypted Client Hello","url":"https://www.rfc-editor.org/rfc/rfc9849","tier":"standard","publisher":"IETF"}],"draft":true}