Defaults.Exposed › Rettelser › Moderne kryptering (TLS-version og ciphers)

Sådan retter du Moderne kryptering (TLS-version og ciphers)

TLS er låsen der krypterer data der flyder mellem dine besøgende og din hjemmeside. To ting gør den lås pålidelig: at bruge en moderne version af TLS (ikke de gamle, defekte), og at bruge stærke ciphers (den faktiske krypteringsopskrift). Denne side dækker begge — plus et par relaterede indstillinger der ikke påvirker din karakter, men er værd at kende.

Det korte svar for din virksomhed: Kører din side på forældet kryptering eller svage ciphers, kan de private oplysninger dine kunder taster — logins, kortnumre, kontaktinfo — stille opsnappees og læses på delte netværk, og du kan fejle de sikkerhedstjek som banker, betalingsbehandlere og større klienter nu kræver inden de vil gøre forretning med dig.

Hvad dette kan koste dig

• En kunde betaler eller logger ind over hotel- eller café-Wi-Fi; en forældet forbindelse eller svag cipher lader en fremmed på det netværk læse deres kort og adgangskode, og svindlen — og det vrede opkald — sporer direkte til din side.
• Du ansøger om at tage kortbetalinger (eller din betalingsudbyder re-auditerer dig) og afvises, fordi forældet TLS eller en forbudt cipher bryder betalingssikkerhedsreglerne — din online checkout er frosset, til det er fikset.
• En større klients IT-team kører en rutinesikkerhedsscanning inden underskrift, ser at din side stadig tillader defekt kryptering, og markerer dig som en risiko — kontrakten staller over et problem der koster ingenting at fikse.
• Et databeskyttelsesklag eller brud lander på dit bord, og det første spørgsmål regulatorer stiller, er om du beskyttede kundedata 'passende' — at kører kryptering der har været offentligt-known-broken i årevis, er et meget svært svar at give.
• Din side viser en lås, så alle antager, at den er fuldt sikker, og dette hul går ubemærket hen i årevis — til ét opsnappet login eller kortnummer giver en hændelse langt dyrere end den gratis rettelse ville have været.

Hvorfor det betyder noget. Kryptering der er sikker er usynlig; kryptering der er forældet eller svag, er en forpligtelse der sidder stille, til den koster dig en kunde, en kontrakt eller en compliancegodkendelse. TLS-version og cipher-tjek er de to dele der faktisk bevæger din karakter, og begge er typisk en enkelt gratis indstilling — der er ingen fordel ved at lade de gamle, defekte muligheder forblive slået til.

På klart dansk

Når nogen besøger din hjemmeside, er alt de taster — logins, kortnumre, navne, telefonnumre, beskeder — krypteret undervejs, så fremmede ikke kan læse det. Den teknologi der gør krypteringen, hedder TLS (du hører den måske også kaldet SSL, dens ældre navn). For at den kryptering faktisk er sikker, skal to ting være rigtige:

1. TLS-versionen — hvilken generation af teknologien du bruger. De tidlige versioner (TLS 1.0 og 1.1) har været offentligt defekte i årevis; de sikre er TLS 1.2 og TLS 1.3.
2. Cipheren — den specifikke opskrift TLS bruger til at gøre krypteringen. Nogle ciphers (som RC4, DES og 3DES) er knækket og nu forbudte; moderne ciphers er stadig stærke.

Denne side dækker begge, fordi en side kan få en ret og den anden forkert. Du kan have en moderne lås med en gammel, crackbar opskrift stadig slået til — eller en stærk opskrift beskyttet af en forældet lås. Begge huller er en åben bagdør. Begge lukkes som regel af den samme enkelt gratis ændring til din server eller hosting-indstillinger.

Hvad dette kan koste dig

• En kunde røves på offentligt Wi-Fi. Nogen logger ind eller betaler fra et hotel, café eller lufthavn. Fordi din side stadig tillader en gammel TLS-version eller en svag cipher, tvinger en fremmed på det netværk forbindelsen ned til den defekte mulighed og læser adgangskode og kortnummer i realtid. Svindlen lander på kunden, men skylden — og supportopkaldet — lander på dig.
• Dine kortbetalinger slås fra. Betalingssikkerhedsregler (PCI DSS) kræver TLS 1.2 som minimum og forbyder eksplicit svage ciphers som RC4. Genauditerer din behandler dig, eller ansøger du om at tage kort, fejler en forældet konfiguration tjekket og din checkout er frosset.
• En aftale staller i en sikkerhedsgennemgang. Inden en større klient underskriver, kører deres IT-team en rutinescan. Den markerer øjeblikkeligt, at din side stadig accepterer defekt kryptering — den slags fund der ser sjusket ud og får en køber til at undre sig over, hvad andet der er løst. Kontrakten sidder i vakuum over et problem der koster ingenting at fikse.
• En regulator stiller det akavet spørgsmål. Efter ethvert klag eller brud vil det første en databeskyttelsesmyndighed vide, er om du beskyttede persondata “passende.” At køre kryptering der har været known-broken offentligt i årevis, er meget svært at forsvare.
• Det gemmer sig bag låsen i årevis. Fordi din side stadig viser en normal lås, bemærker ingen hullet — til et enkelt opsnappet login eller kortnummer bliver en offentlig hændelse.

Hvad det faktisk er

TLS-versionen

En side understøtter ikke blot én version af TLS — den kan tilbyde flere på én gang og lade enhver besøgendes browser vælge. En moderne besøgende vil bruge den nyeste version og se en normal lås. Faren er, at de gamle, defekte versioner kan sidde der ved siden af de gode som en åben bagdør: en angriber kan tvinge en besøgendes forbindelse til at “nedgradere” til TLS 1.0 eller 1.1 og derefter udnytte de kendte svagheder i disse versioner (BEAST- og POODLE-angrebene er de berømte eksempler) til at dekryptere trafikken.

Vores tjek forbinder til din side og tester hver version individuelt — TLS 1.0, 1.1, 1.2 og 1.3 — for at se hvilke din server stadig accepterer:

• TLS 1.3 (med eller uden 1.2), og ingen legacy: det bedste resultat. Fulde point.
• Kun TLS 1.2, ingen 1.3: sikker og består, men du efterlader den nyeste, hurtigste version. De fleste point; at aktivere 1.3 er værd at gøre.
• TLS 1.0 eller 1.1 stadig accepteret: et automatisk fejl, scored nul og flagget kritisk — det spiller ingen rolle at 1.2/1.3 også virker, fordi de defekte versioner er den åbne bagdør. Det er det, du skal fikse.

Cipheren

Når en version er valgt, vælger TLS en cipher — den faktiske algoritme der krypterer dataene. De fleste moderne ciphers er stærke. En håndfuld er defekte og må aldrig bruges: RC4 (dets kryptering er biased og lækker klarteksten), DES (dets nøgle er så kort, den kan brute-forces), 3DES (sårbar over for “Sweet32”-angrebet), plus NULL (ingen kryptering overhovedet), EXPORT-grade ciphers (bevidst svækkede) og anonyme ciphers (ingen identitetstjek).

Vores cipher-tjek gør to ting. Først kigger det på den cipher din server faktisk forhandlede med os. Derefter — og dette er den vigtige del — prøver det aktivt at handshake ved hjælp af adskillige known-broken ciphers (RC4, 3DES, EXPORT, NULL og anonyme varianter). En server kan vælge en stærk cipher, når den taler med en moderne klient, men stadig acceptere en svag en, hvis en angriber insisterer — og det er en reel nedgraderingsrisiko.

De tre informative extras

Tre relaterede elementer rapporteres men påvirker ikke din karakter — de flages som informative, fordi de ikke kan verificeres pålideligt udefra, og på enhver moderne server eller CDN er de allerede håndteret korrekt:

• TLS-komprimering (CRIME-angrebet): en gammel funktion der, hvis den var slået til, kunne lade en angriber sondere session-cookies. Den er deaktiveret som standard i enhver moderne webserver i over et årti.
• OCSP-stapling: en performance- og privatlivsrettighed, hvor din server pre-henter bevis for, at dens certifikat ikke er tilbagekaldt.
• Sikker genforhandling: en rettelse for en gammel fejl (CVE-2009-3555). TLS 1.3 fjernede genforhandling fuldstændigt.

Vi viser disse, så din IT-person har det fulde billede, men for langt de fleste ejere er der intet at gøre.

Sådan fikser du det (gratis, ~30 minutter)

Overrækk dette til din IT-person — fikset er gratis. Den enkle pålidelige tilgang er at generere en known-good-konfiguration snarere end at håndskrive en: indsæt din servertype i Mozillas SSL Configuration Generator på https://ssl-config.mozilla.org/ og vælg “Intermediate”-profilen.

Efter platform:

1. Cloudflare eller managed host — som regel ét eller to klik. I Cloudflare: SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2.
2. Nginx. Sæt moderne-only versioner og en eksplicit stærk cipher-liste, genindlæs derefter:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

3. Apache. Deaktivér de gamle versioner og pin en stærk cipher-liste, genstart derefter:

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...
   SSLHonorCipherOrder on
   

4. Windows / IIS. Brug det gratis IIS Crypto-værktøj til at deaktivere TLS 1.0 og 1.1, deaktivere RC4/DES/3DES/NULL/EXPORT ciphers. Værktøjets “Best Practices”-skabelon gør alt dette med ét klik.
5. Verificér, tjek derefter her igen. Bekræft kun de sikre versioner og ciphers forbliver.

Almindelige fejl

• “Vi har en lås, så vi er fine.” Låsen beviser kun, at en sikker forbindelse eksisterer. Den siger intet om, hvorvidt en gammel version eller en forbudt cipher stadig accepteres i baggrunden.
• At fikse versionen men ikke ciphers (eller omvendt). Deaktivering af TLS 1.0/1.1 fjerner ikke automatisk RC4 eller 3DES. Sæt begge.
• At efterlade “legacy” eller “gammelt-browser-kompatibilitet”-toggles slået til. Mange hosts og CDN’er har en mulighed, der stille re-aktiverer de defekte versioner eller svage ciphers “for kompatibilitet.”
• At glemme at genindlæse/genstarte serveren. Konfigurationsændringer træder ikke i kraft, før webserveren genindlæses.
• At konfigurere én server men ikke alle. Hvis du kører en loadbalancer, flere webservere eller separate subdomæner, har hvert TLS-endpoint brug for den samme konfiguration.

FAQ