Defaults.Exposed › Fikser › Moderne kryptering (TLS-versjon og chiffersuiter)

Slik fikser du Moderne kryptering (TLS-versjon og chiffersuiter)

TLS er låsen som krypterer dataene som flyter mellom besøkende og nettstedet ditt. To ting gjør den låsen troverdig: å bruke en moderne versjon av TLS (ikke de gamle, ødelagte), og å bruke sterke chiffersuiter (den faktiske krypteringsoppskriften). Denne siden dekker begge — pluss noen relaterte innstillinger som ikke påvirker karakteren din, men som er verdt å vite om.

Bunnlinjen for virksomheten din: Hvis siden kjører på utdatert kryptering eller svake chiffersuiter, kan de private detaljene kundene skriver inn — pålogginger, kortnumre, kontaktinformasjon — avlyttes og leses stille på delte nettverk, og du kan feile sikkerhetssjekker som banker, betalingsleverandører og større klienter nå krever før de vil gjøre forretninger med deg.

Hva dette kan koste deg

• En kunde betaler eller logger inn over hotell- eller kafé-WiFi, en utdatert tilkobling eller svak chiffersuite lar en fremmed på det nettverket lese kortdetaljer og passord, og svindelen — og den sinte telefonsamtalen — spores rett tilbake til siden din.
• Du søker om å ta kortbetalinger (eller betalingsleverandøren re-reviderer deg) og avvises fordi utdatert TLS eller en forbudt chiffersuite bryter betalingssikkerhetsreglene — nettbutikken din er frosset til det er fikset.
• Et større selskaps IT-team kjører en rutinesikkerhetsskanning før de signerer, ser at siden fortsatt tillater ødelagt kryptering, og flagger deg som en risiko — kontrakten staller over et problem som koster ingenting å fikse.
• En databeskyttelsesklage eller brudd lander på skrivebordet ditt og det første spørsmålet tilsynsmyndigheter stiller er om du beskyttet kundedata 'hensiktsmessig' — å kjøre kryptering som har vært offentlig kjent som ødelagt i årevis er et veldig vanskelig svar å gi.
• Siden viser en hengelås, så alle antar at den er fullt trygg, og dette gapet går uoppdaget i årevis — til en enkelt avlyttet pålogging eller kortnummer blir en hendelse langt dyrere enn den gratis fiksen ville ha vært.

Hvorfor det er viktig. Kryptering som er trygg er usynlig; kryptering som er utdatert eller svak er et ansvar som sitter stille til dagen det koster deg en kunde, en kontrakt, eller en samsvarsgodkjenning. TLS-versjonen og chiffersuitesjekken er de to delene som faktisk beveger karakteren din, og begge er typisk en enkelt gratis innstilling — det er ingen fordel ved å la de gamle, ødelagte alternativene stå på.

I enkle ord

Når noen besøker nettstedet ditt, krypteres alt de skriver — pålogginger, kortnumre, navn, telefonnumre, meldinger — underveis slik at fremmede ikke kan lese det. Teknologien som gjør krypteringen kalles TLS (du kan også høre det kalt SSL, det eldre navnet). For at krypteringen faktisk skal være trygg, må to ting være riktige:

1. TLS-versjonen — hvilken generasjon av teknologien du bruker. De tidlige versjonene (TLS 1.0 og 1.1) har vært offentlig ødelagt i årevis; de trygge er TLS 1.2 og TLS 1.3.
2. Chiffersuite — den spesifikke oppskriften TLS bruker til å gjøre krypteringen. Noen chiffersuiter (som RC4, DES og 3DES) er blitt knekket og er nå forbudt; moderne chiffersuiter er fortsatt sterke.

Denne siden dekker begge, fordi en side kan gjøre den ene riktig og den andre feil. Du kan ha en moderne lås med en gammel, knekbar oppskrift fortsatt slått på — eller en sterk oppskrift beskyttet av en utdatert lås. Begge gap er en åpen dør. Begge lukkes vanligvis av den samme enkle gratis endringen i server- eller webhotellinnstillingene dine.

Hva dette kan koste deg

• En kunde blir ranet på offentlig WiFi. Noen logger inn på kontoen sin eller betaler fra et hotell, kafé eller flyplass. Fordi siden fortsatt tillater en gammel TLS-versjon eller en svak chiffersuite, tvinger en fremmed på det nettverket tilkoblingen ned til det knekbare alternativet og leser passord og kortnummer i sanntid. Svindelen lander på kunden, men skylden — og supportsamtalen — lander på deg.
• Kortbetalingene dine slås av. Betalingssikkerhetsregler (PCI DSS) krever TLS 1.2 som minimum og forbyr eksplisitt svake chiffersuiter som RC4. Når prosessoren re-reviderer deg, eller når du søker om å ta kort, feiler en utdatert konfigurasjon sjekken og kassen din er frosset til det er fikset — på nøyaktig feil tidspunkt for kontantstrøm.
• En avtale staller i en sikkerhetsgjennomgang. Før en større klient signerer, kjører IT-teamet en rutineskanning. Den flagger umiddelbart at siden din fortsatt godtar ødelagt kryptering — den typen funn som ser uaktsom ut og får en kjøper til å lure på hva annet som er løst. Kontrakten sitter i limbo over et problem som koster ingenting å fikse.
• En tilsynsmyndighet stiller det vanskelige spørsmålet. Etter enhver klage eller brudd er det første en databeskyttelsesmyndighet vil vite om du beskyttet persondata «hensiktsmessig.» Å kjøre kryptering som har vært kjent-ødelagt offentlig i årevis er veldig vanskelig å forsvare, og «vi visste ikke at den gamle versjonen fortsatt var på» er ikke et komfortabelt svar.
• Det gjemmer seg bak hengelåsen i årevis. Fordi siden fortsatt viser en normal hengelås, merker ingen gapet — til en enkelt avlyttet pålogging eller kortnummer blir en offentlig hendelse langt dyrere enn den fem-minutters fiksen ville ha vært.

Hva det faktisk er

TLS-versjonen

En side støtter ikke bare én versjon av TLS — den kan tilby flere på én gang og la hver besøkerens nettleser velge. En moderne besøkende vil bruke den nyeste tilgjengelige versjonen og se en normal hengelås. Faren er at de gamle, ødelagte versjonene kan sitte der ved siden av de gode som en åpen bakdør: en angriper kan tvinge en besøkerens tilkobling til å «nedgradere» til TLS 1.0 eller 1.1 og deretter utnytte de kjente svakhetene i disse versjonene (BEAST og POODLE-angrepene er de berømte eksemplene) for å dekryptere trafikken.

Så sjekken vår kobler til siden din og tester hver versjon individuelt — TLS 1.0, 1.1, 1.2 og 1.3 — for å se hvilke din server fortsatt godtar. Her er hva «bra» ser ut som og hvordan det scores:

• TLS 1.3 (med eller uten 1.2), og ingen eldre: det beste resultatet — en moderne, ren konfigurasjon. Full score.
• Bare TLS 1.2, ingen 1.3: trygt og bestås, men du lar den nyeste, raskeste versjonen ligge ubenyttet. Nesten full score; å aktivere 1.3 er verdt å gjøre.
• TLS 1.0 eller 1.1 akseptert fortsatt: automatisk feil, scoret null og flagget kritisk — det spiller ingen rolle at 1.2/1.3 også fungerer, fordi de ødelagte versjonene er den åpne døren. Dette er det du må fikse.

Chiffersuite

Når en versjon er valgt, velger TLS en chiffersuite — den faktiske algoritmen som krypterer dataene. De fleste moderne chiffersuiter er sterke. En håndfull er ødelagte og må aldri brukes: RC4 (krypteringen er forutinntatt og lekker klartekst), DES (nøkkelen er så kort at den kan brute-forces), 3DES (sårbar for «Sweet32»-angrepet), pluss NULL (ingen kryptering overhodet), EXPORT-klasse chiffersuiter (bevisst svekket — FREAK og Logjam-angrepene), og anonyme chiffersuiter (ingen identitetssjekk, så en etterligner kan sitte i midten).

Chifferencontrolle vår gjør to ting. Først ser den på chiffersuite serveren faktisk forhandlet frem med oss. Deretter — og dette er den viktige delen — prøver den aktivt å håndhilse ved å bruke flere kjente-ødelagte chiffersuiter (RC4, 3DES, EXPORT, NULL og anonyme varianter). En server kan velge en sterk chiffersuite når den snakker med en moderne klient, og likevel godta en svak hvis en angriper insisterer — og det er en reell nedgraderingsrisiko. Hvis serveren godtar noen forbudte chiffersuiter, flagger sjekken det; å godta en kritisk (som RC4 eller NULL) er en feil.

De tre informative tilleggene

Tre relaterte elementer rapporteres, men påvirker ikke karakteren din — de flagges som informative fordi de ikke kan verifiseres pålitelig utenfra, og på alle moderne servere eller CDN-er er de allerede håndtert riktig:

• TLS-komprimering (CRIME-angrepet): en gammel funksjon som, hvis den ble stående på, kunne la en angriper lokke frem øktcookies. Den har vært deaktivert som standard i alle moderne nettservere i over et tiår.
• OCSP-stapling: en ytelses- og personvernfunksjon der serveren forhåndshenter bevis på at sertifikatet ikke er tilbakekalt. CDN-er som Cloudflare gjør dette automatisk.
• Sikker renegotiering: en fiks for en gammel feil (CVE-2009-3555) som lot angripere injisere data i en økt. TLS 1.3 fjernet renegotiering fullstendig, så det er ikke et problem der, og moderne TLS 1.2-servere implementerer fiksen som standard.

Slik fikser du det (gratis, ~30 minutter)

Send dette til IT-personen din — fiksen er gratis. Denne seksjonen er for den som administrerer domenet, nettstedet eller webhotellet ditt. Fiksen er en konfigurasjonsendring, ikke et kjøp. Den eneste moderne konfigurasjonen nedenfor fikser både versjon- og chiffersuite-funnene på én gang.

Den enkleste pålitelige tilnærmingen er å generere en kjent-god konfigurasjon i stedet for å skrive den for hånd: lim inn servertypen din i Mozillas SSL-konfigurasjonsbygger på https://ssl-config.mozilla.org/ og velg «Intermediate»-profilen (bred kompatibilitet) eller «Modern» (kun TLS 1.3). Den gir ut de riktige ssl_protocols- og ssl_ciphers-linjene for deg.

Per plattform:

1. Cloudflare eller et administrert vertsskap — vanligvis ett eller to klikk. I Cloudflare: SSL/TLS → Kantesertifikater → Minimum TLS-versjon → TLS 1.2, og chiffersuitene der administreres for deg (plattformen vil ikke tilby forbudte chiffersuiter). De fleste administrerte verter og nettstedsbyggere (Squarespace, Wix, Shopify, moderne WordPress-verter) håndhever allerede TLS 1.2+ med sterke chiffersuiter — bare bekreft at det ikke er noe «legacy TLS» eller «gammel nettleserkompatibilitet»-alternativ fortsatt slått på.
2. Nginx. Sett moderne-bare versjoner og en eksplisitt sterk chiffersuiteliste, og last inn på nytt:

   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. Deaktiver de gamle versjonene og fest en sterk chiffersuiteliste, og start deretter på nytt:

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

4. Windows / IIS. Bruk det gratis IIS Crypto-verktøyet (eller tilsvarende registerinnstillinger) for å deaktivere TLS 1.0 og 1.1, deaktivere RC4/DES/3DES/NULL/EXPORT-chiffersuiter, og la TLS 1.2 og 1.3 med sterke chiffersuiter være aktivert. Verktøyets «Best Practices»-mal gjør alt dette i ett klikk.
5. De informative tilleggene (valgfritt, gratis). For en ren opprydding: på Nginx legg til ssl_stapling on; ssl_stapling_verify on; (med en resolver-linje) for OCSP-stapling; på Apache, SSLUseStapling On. TLS-komprimering og sikker renegotiering er allerede trygge som standard på moderne servere — ingen handling nødvendig. På Cloudflare håndteres alle tre automatisk.
6. Verifiser, og sjekk deretter her på nytt. Bekreft at bare de trygge versjonene og chiffersuiter gjenstår — for eksempel med nmap --script ssl-enum-ciphers -p 443 dittdomene.com — og kjør deretter denne sjekken på nytt. Aktiver der mulig TLS 1.3 ved siden av 1.2: det er både raskere og sikrere.

Vanlige feil

• «Vi har en hengelås, så vi er fine.» Hengelåsen beviser bare at en sikker tilkobling eksisterer. Den sier ingenting om en gammel versjon eller en forbudt chiffersuite fortsatt godtas i bakgrunnen — det er nøyaktig gapet disse sjekken finner.
• Fikse versjonen, men ikke chiffersuiten (eller omvendt). Deaktivering av TLS 1.0/1.1 fjerner ikke automatisk RC4 eller 3DES, og festing av sterke chiffersuiter deaktiverer ikke automatisk gamle versjoner. Sett begge — den genererte konfigurasjonen ovenfor gjør det.
• La «legacy» eller «gammel nettleserkompatibilitet»-brytere stå på. Mange verter og CDN-er har et alternativ som stille re-aktiverer de ødelagte versjonene eller svake chiffersuiter «for kompatibilitet.» Det hjelper nesten aldri en ekte besøkende og forårsaker direkte dette funnet.
• Glemme å faktisk laste inn/starte serveren på nytt. Konfigurasjonsendringer trer ikke i kraft før nettserveren lastes inn på nytt — en overraskende vanlig årsak til at en «fikset» side fortsatt feiler re-sjekken.
• Konfigurere én server, men ikke alle. Hvis du kjører en lastbalanserer, flere nettservere eller separate underdomener (butikk, blogg, app), trenger hvert TLS-endepunkt den samme konfigurasjonen — det svakeste er det en angriper retter seg mot.

Hva du bør huske

TLS versjon og chiffersuite er de to delene av krypteringen din som faktisk beveger karakteren din, og begge handler om å slå av alternativer som har vært ødelagt offentlig i årevis. Fiksen er gratis, den er vanligvis én moderne konfigurasjonslinje per server, og for en normal besøkende endrer den ingenting unntatt at tilkoblingen genuint er trygg. De relaterte elementene — komprimering, OCSP-stapling, sikker renegotiering — er verdt å vite om, men vil ikke påvirke scoren din, og på ethvert moderne oppsett er de allerede håndtert for deg.

FAQ