Gå til indhold
atlas

HTTPS

Også kendt som: HTTP Secure, HTTP over TLS

Måden, browsere og websteder udveksler sider på, hvor TLS beskytter hver besked, så ingen undervejs kan læse eller ændre dem.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

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.

Forklaret enkelt

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.

I praksis

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.

Hvorfor det betyder noget

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.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Lav en liste over alle websites, subdomæner og web-API'er, organisationen driver, også testsites og gamle kampagnesider, og udpeg en ejer for hver.
  2. Skaf et certifikat til hvert navn fra en betroet certifikatudsteder, og automatisér udstedelse og fornyelse med ACME, fx via hostingudbyderen eller en klient som Certbot, så certifikater aldrig udløber uventet.
  3. Lever alle sider og API'er udelukkende over HTTPS, og omdiriger alle almindelige HTTP-forespørgsler på port 80 permanent til samme adresse på HTTPS.
  4. Send Strict-Transport-Security-headeren, start med en kort max-age, og hæv den til mindst et år med includeSubDomains, når alle subdomæner virker over HTTPS.
  5. Markér alle session- og login-cookies med Secure og HttpOnly, og ret mixed content ved at hente alle scripts, styles, billeder og formularmål over HTTPS.
  6. Sørg for, at trafikken også er krypteret bag CDN eller load balancer helt ind til applikationsserverne og ikke kun på den offentlige side.
  7. Scan jeres sites hver måned for udløbne certifikater, manglende HSTS, mixed content og HTTP-sider, og ret det, scanningen finder.
  8. Hold øje med Certificate Transparency-logs efter certifikater udstedt til jeres domæner, og undersøg dem, I ikke selv har bestilt.

Typiske faldgruber

  • At forny certifikater manuelt ud fra en kalenderpåmindelse, så et bliver glemt, og sitet viser en sikkerhedsadvarsel til alle besøgende.
  • At tilmelde HSTS preload med includeSubDomains, før det er tjekket, at alle subdomæner understøtter HTTPS, så brugerne bliver låst ude af dem, der ikke gør.
  • At tage hængelåsen som bevis på, at et site er redeligt, selv om phishingsites lige så let får gratis certifikater.

Gode vejledninger

Teknisk uddybning

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).

HTTPS 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.

Det 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.

I 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.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Kryptografisk nøgle
  2. →Kryptering
  3. →Hashing
  4. →Digital identitet
  5. →Netværk
  6. →IP-adresse
  7. →Protokol
  8. →Asymmetrisk kryptografi (public key)
  9. →Klient
  10. →Digital signatur
  11. →Pakke
  12. →Port
  13. →Digitalt certifikat
  14. →Server
  15. →TCP/IP
  16. →HTTP
  17. →TLS
  18. →HTTPS

Relationer

En slags
Protokol
Implementerer
Fortrolighed

Kilder og videre læsning

Standarder og officielle tekster

Lærebøger

  • Kurose & Ross, Computer Networking: A Top-Down Approach

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Nævnt i

Test dig selv

Indlæser…

Atlas er i beta.