{"id":32,"date":"2026-06-10T12:33:23","date_gmt":"2026-06-10T12:33:23","guid":{"rendered":"https:\/\/shattered.io\/dk\/2026\/06\/10\/https-og-tls\/"},"modified":"2026-06-10T13:35:45","modified_gmt":"2026-06-10T13:35:45","slug":"https-og-tls","status":"publish","type":"post","link":"https:\/\/shattered.io\/dk\/security\/https-og-tls\/","title":{"rendered":"HTTPS og TLS: s\u00e5dan beskyttes din forbindelse"},"content":{"rendered":"<h2 id=\"hvad-https-og-tls-er\">Hvad HTTPS og TLS er<\/h2>\n<p>N\u00e5r du bes\u00f8ger en hjemmeside, sendes data frem og tilbage mellem din enhed og en server et sted p\u00e5 nettet. Undervejs passerer de mange mellemstationer: dit tr\u00e5dl\u00f8se netv\u00e6rk, din internetudbyder og en lang r\u00e6kke routere. Uden beskyttelse kan enhver, der har adgang til et af disse led, l\u00e6se med og i v\u00e6rste fald \u00e6ndre indholdet. HTTPS og TLS findes for at lukke den mulighed.<\/p>\n<p>HTTPS er den sikre udgave af den protokol, browsere bruger til at hente hjemmesider. Det ekstra S st\u00e5r for sikker, og sikkerheden kommer fra et lag kaldet TLS, Transport Layer Security. TLS er den teknik, der krypterer forbindelsen, s\u00e5 indholdet er ul\u00e6seligt for udenforst\u00e5ende, og som samtidig sikrer, at du faktisk taler med den rigtige server. N\u00e5r du ser h\u00e6ngel\u00e5sen i browserens adresselinje, betyder det, at siden blev hentet over en TLS-beskyttet forbindelse.<\/p>\n<h2 id=\"hvad-tls-faktisk-beskytter\">Hvad TLS faktisk beskytter<\/h2>\n<p>Det er nyttigt at v\u00e6re pr\u00e6cis om, hvad en TLS-forbindelse giver dig. Den leverer grundl\u00e6ggende tre ting p\u00e5 \u00e9n gang.<\/p>\n<p><strong>Fortrolighed<\/strong> betyder, at indholdet er krypteret. En person, der lytter med p\u00e5 netv\u00e6rket, ser kun en str\u00f8m af krypteret data, ikke de kodeord, beskeder eller kortnumre, du sender. Det er denne egenskab, der g\u00f8r det forsvarligt at logge ind via et offentligt tr\u00e5dl\u00f8st netv\u00e6rk p\u00e5 en caf\u00e9, s\u00e5 l\u00e6nge forbindelsen til selve tjenesten er krypteret.<\/p>\n<p><strong>Integritet<\/strong> betyder, at data ikke kan \u00e6ndres undervejs uden at det opdages. TLS forsyner det sendte med en form for kontrolv\u00e6rdi, s\u00e5 modtageren kan se, om noget er blevet pillet ved p\u00e5 vejen. En angriber kan derfor ikke uset inds\u00e6tte eller \u00e6ndre indhold i en krypteret forbindelse.<\/p>\n<p><strong>Autenticitet<\/strong> betyder, at du kan stole p\u00e5, hvem du taler med. TLS bruger certifikater til at bevise, at serveren faktisk er den, den udgiver sig for. Uden dette led ville kryptering alene ikke hj\u00e6lpe, for s\u00e5 kunne du have en perfekt krypteret samtale med den forkerte part.<\/p>\n<p>De tre egenskaber h\u00e6nger sammen. Kryptering uden autenticitet beskytter mod aflytning, men ikke mod at blive narret til at tale med en bedrager. Det er derfor, certifikater er en s\u00e5 central del af systemet.<\/p>\n<h2 id=\"saadan-etableres-en-sikker-forbindelse\">S\u00e5dan etableres en sikker forbindelse<\/h2>\n<p>N\u00e5r din browser \u00e5bner en HTTPS-forbindelse, foreg\u00e5r der f\u00f8rst et s\u00e5kaldt h\u00e5ndtryk, f\u00f8r noget egentligt indhold sendes. Uden at g\u00e5 i de matematiske detaljer kan forl\u00f8bet beskrives i nogle f\u00e5 trin.<\/p>\n<p>F\u00f8rst pr\u00e6senterer serveren sit certifikat, som indeholder dens offentlige n\u00f8gle og oplysninger om, hvem den er. Browseren kontrollerer, at certifikatet er gyldigt og udstedt til netop det dom\u00e6ne, du fors\u00f8ger at bes\u00f8ge. Dern\u00e6st bruger de to parter asymmetrisk kryptografi til i f\u00e6llesskab at blive enige om en hemmelig n\u00f8gle, som kun de to kender, uden at n\u00f8glen nogensinde sendes \u00e5bent over forbindelsen. Endelig skifter forbindelsen over til at bruge denne f\u00e6lles n\u00f8gle med hurtig symmetrisk kryptering til al videre kommunikation.<\/p>\n<p>Pointen i denne todeling er b\u00e5de sikkerhed og hastighed. Den indledende, langsommere asymmetriske del bruges kun til at etablere den f\u00e6lles hemmelighed. Resten af samtalen, som kan v\u00e6re stor, krypteres med en hurtigere metode. Resultatet er en forbindelse, der b\u00e5de er praktisk at bruge og sv\u00e6r at bryde.<\/p>\n<h2 id=\"certifikater-og-certifikatmyndigheder\">Certifikater og certifikatmyndigheder<\/h2>\n<p>Et certifikat er i bund og grund en elektronisk attest p\u00e5, at en bestemt offentlig n\u00f8gle h\u00f8rer til et bestemt dom\u00e6ne. Men en attest er kun v\u00e6rd at stole p\u00e5, hvis den er udstedt af en, du har tillid til. Her kommer certifikatmyndighederne ind.<\/p>\n<p>En certifikatmyndighed, ofte forkortet CA, er en organisation, hvis opgave er at verificere, at den, der beder om et certifikat til et dom\u00e6ne, faktisk kontrollerer det dom\u00e6ne. N\u00e5r myndigheden er overbevist, udsteder den et certifikat ved at skrive digitalt under p\u00e5 det. Din browser og dit styresystem leveres med en liste over betroede certifikatmyndigheder. N\u00e5r et certifikat er underskrevet af en af dem, accepterer browseren det uden videre.<\/p>\n<p>Selve underskriften bygger p\u00e5 digitale signaturer, og de hviler igen p\u00e5 hashfunktioner. N\u00e5r en certifikatmyndighed underskriver et certifikat, beregnes der et hash af certifikatets indhold, og det er dette hash, der signeres. Browseren kan derefter genberegne hashet og kontrollere underskriften. Det er en del af grunden til, at styrken af de underliggende hashfunktioner er s\u00e5 vigtig: en svag hashfunktion ville kunne udnyttes til at fremstille et falsk, men tilsyneladende gyldigt certifikat. Sammenh\u00e6ngen mellem certifikater, signaturer og hashing uddybes i afsnittet om <a href=\"https:\/\/shattered.io\/dk\/cryptography\/\">kryptografi<\/a>.<\/p>\n<p>Det var netop denne risiko, der gjorde svagheder i \u00e6ldre hashfunktioner til et reelt problem for certifikater. Da det blev praktisk muligt at fremstille kollisioner i en udbredt \u00e6ldre hashfunktion, kunne man i princippet konstruere to forskellige certifikater med samme hash, og dermed undergrave tilliden til underskriften. Det er en hoved\u00e5rsag til, at branchen er g\u00e5et over til st\u00e6rkere hashfunktioner i certifikater.<\/p>\n<h2 id=\"haengelaasen-og-dens-graenser\">H\u00e6ngel\u00e5sen og dens gr\u00e6nser<\/h2>\n<p>H\u00e6ngel\u00e5sen i adresselinjen er et nyttigt signal, men den fort\u00e6ller mindre, end mange tror. Den bekr\u00e6fter, at forbindelsen til siden er krypteret, og at sidens certifikat er gyldigt for det dom\u00e6ne, du ser i adresselinjen. Den siger derimod intet om, hvorvidt selve siden er \u00e6rlig.<\/p>\n<p>Dette er en vigtig nuance. En svindelside kan sagtens have et gyldigt certifikat og dermed en h\u00e6ngel\u00e5s, for det er i dag let og gratis for hvem som helst at f\u00e5 et certifikat til et dom\u00e6ne, de kontrollerer. H\u00e6ngel\u00e5sen garanterer alts\u00e5, at din forbindelse til siden er privat, men ikke at siden bag den er til at stole p\u00e5. En phishingside, der efterligner din bank, kan udm\u00e6rket vises med h\u00e6ngel\u00e5s. Derfor er det afg\u00f8rende at l\u00e6se selve dom\u00e6nenavnet i adresselinjen og ikke n\u00f8jes med at se, at l\u00e5sen er der. Mere om dette i artiklen om <a href=\"https:\/\/shattered.io\/dk\/security\/phishing\/\">phishing<\/a>.<\/p>\n<h2 id=\"hvor-tls-ikke-raekker\">Hvor TLS ikke r\u00e6kker<\/h2>\n<p>TLS l\u00f8ser et veldefineret problem: at beskytte data, mens de er undervejs mellem din enhed og serveren. Men der er meget, det ikke g\u00f8r, og det er v\u00e6rd at kende gr\u00e6nserne.<\/p>\n<p>TLS beskytter ikke data, n\u00e5r de ligger hos modtageren. N\u00e5r dine oplysninger er n\u00e5et frem til en tjeneste, afh\u00e6nger deres sk\u00e6bne af, hvordan tjenesten opbevarer dem. En krypteret forbindelse forhindrer ikke et senere <a href=\"https:\/\/shattered.io\/dk\/security\/datalaek\/\">datal\u00e6k<\/a> hos virksomheden. Beskyttelsen g\u00e6lder transporten, ikke opbevaringen.<\/p>\n<p>TLS beskytter heller ikke mod, at du selv frivilligt sender data til den forkerte. Bliver du narret til at indtaste dit kodeord p\u00e5 en falsk side, hj\u00e6lper kryptering ikke, for forbindelsen til svindleren kan v\u00e6re lige s\u00e5 sikker som til den \u00e6gte tjeneste. Her er det din vurdering af, hvem du taler med, der afg\u00f8r udfaldet, ikke krypteringen.<\/p>\n<p>Endelig beskytter TLS ikke en enhed, der allerede er kompromitteret. Er der skadelig software p\u00e5 din computer, kan den l\u00e6se dine data, f\u00f8r de overhovedet bliver krypteret. Sikkerheden i forbindelsen foruds\u00e6tter, at endepunkterne i sig selv er i orden.<\/p>\n<h2 id=\"det-vigtigste-at-huske\">Det vigtigste at huske<\/h2>\n<p>HTTPS og TLS sikrer, at det, du sender og modtager, forbliver privat og u\u00e6ndret undervejs, og at du faktisk er forbundet til det dom\u00e6ne, der st\u00e5r i adresselinjen. Det er et fundament for n\u00e6sten alt, hvad vi foretager os online, fra netbank til indk\u00f8b. Men beskyttelsen handler om transporten, ikke om afsenderens h\u00e6derlighed. H\u00e6ngel\u00e5sen betyder sikker forbindelse, ikke sikker hjemmeside. L\u00e6s altid dom\u00e6nenavnet, og husk, at krypteret ikke er det samme som trov\u00e6rdig.<\/p>\n<div class=\"shat-sources\">\n<h2 id=\"kilder\">Kilder<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8446\" rel=\"noopener\">RFC 8446: TLS 1.3<\/a><\/li>\n<li><a href=\"https:\/\/csrc.nist.gov\/pubs\/sp\/800\/52\/r2\/final\" rel=\"noopener\">NIST SP 800-52 Rev. 2: Guidelines for TLS<\/a><\/li>\n<\/ul>\n<\/div>\n<div class=\"shat-related\">\n<h2 id=\"relaterede-artikler\">Relaterede artikler<\/h2>\n<ul>\n<li><a href=\"https:\/\/shattered.io\/dk\/security\/datalaek\/\">Datal\u00e6k: s\u00e5dan opst\u00e5r de, og s\u00e5dan beskytter du dig<\/a><\/li>\n<li><a href=\"https:\/\/shattered.io\/dk\/security\/kodeordssikkerhed\/\">Kodeordssikkerhed: l\u00e6ngde, hashing, kodeordsmanagere og 2FA<\/a><\/li>\n<li><a href=\"https:\/\/shattered.io\/dk\/security\/\">Onlinesikkerhed: beskyt dine data, konti og forbindelser<\/a><\/li>\n<li><a href=\"https:\/\/shattered.io\/dk\/security\/phishing\/\">Phishing og social engineering: kend fors\u00f8get, og undg\u00e5 f\u00e6lden<\/a><\/li>\n<\/ul>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Hvad HTTPS og TLS er N\u00e5r du bes\u00f8ger en hjemmeside, sendes data frem og tilbage mellem din enhed og en server et sted p\u00e5 nettet. Undervejs passerer de mange mellemstationer:\u2026<\/p>\n","protected":false},"author":3,"featured_media":39,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-32","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/posts\/32","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/comments?post=32"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/posts\/32\/revisions"}],"predecessor-version":[{"id":47,"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/posts\/32\/revisions\/47"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/media\/39"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/media?parent=32"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/categories?post=32"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/dk\/wp-json\/wp\/v2\/tags?post=32"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}