Defaults.Exposed › Åtgärder › Modern kryptering (TLS-version och chiffrar)

Hur du fixar Modern kryptering (TLS-version och chiffrar)

TLS är låset som krypterar data som flödar mellan dina besökare och din webbplats. Två saker gör det låset pålitligt: att använda en modern version av TLS (inte de gamla, trasiga), och att använda starka chiffrar (det faktiska krypteringsreceptet). Den här sidan täcker båda — plus några relaterade inställningar som inte påverkar ditt betyg men är värda att känna till.

Slutsats för ditt företag: Om din webbplats kör på föråldrad kryptering eller svaga chiffrar kan privata uppgifter som dina kunder skriver in — inloggningar, kortnummer, kontaktinfo — tyst avlyssnas och läsas på delade nätverk, och du kan misslyckas med de säkerhetskontroller som banker, betalningsföretag och större kunder nu kräver innan de gör affärer med dig.

Vad detta kan kosta dig

En kund betalar eller loggar in på hotell- eller café-Wi-Fi, en föråldrad anslutning eller svagt chiffra låter en person på det nätverket läsa deras kort- och lösenordsuppgifter, och bedrägeriet — och det ilskna telefonsamtalet — spåras tillbaka till din webbplats.
Du söker om att ta kortbetalningar (eller din betalningsleverantör reviderar dig) och avvisas för att föråldrad TLS eller ett förbjudet chiffra bryter betalningssäkerhetsreglerna — din onlinekassa är fryst tills det åtgärdas.
En större kunds IT-team kör en rutinmässig säkerhetsskanning innan de skriver på, ser att din webbplats fortfarande tillåter trasig kryptering och flaggar dig som en risk — kontraktet stannar för ett problem som kostar ingenting att åtgärda.
Ett dataskyddsklagomål eller intrång hamnar på ditt bord och den första frågan tillsynsmyndigheter ställer är om du skyddade kunddata 'på lämpligt sätt' — att köra kryptering som har varit offentligt känd-trasig i år är ett väldigt svårt svar att ge.
Din webbplats visar ett hänglås, så alla antar att det är helt säkert, och det här gapet förblir oupptäckt i år — tills en avlyssnad inloggning eller ett kortnummer förvandlas till en incident som är mycket dyrare än den gratis åtgärden hade varit.

Varför det spelar roll. Kryptering som är säker är osynlig; kryptering som är föråldrad eller svag är ett ansvar som sitter stilla tills den dag den kostar dig en kund, ett kontrakt eller ett efterlevnadsgodkännande. TLS-versionen och chiffer-kontrollerna är de två delarna som faktiskt rör ditt betyg, och båda är typiskt en enda gratis inställning — det finns ingen fördel med att lämna de gamla, trasiga alternativen påslagna.

I klartext

När någon besöker din webbplats krypteras allt de skriver — inloggningar, kortnummer, namn, telefonnummer, meddelanden — under transporten så att obehöriga inte kan läsa det. Tekniken som gör krypteringen kallas TLS (du kan också höra det kallas SSL, dess äldre namn). För att krypteringen faktiskt ska vara säker måste två saker vara rätt:

TLS-versionen — vilken generation av tekniken du använder. De tidiga versionerna (TLS 1.0 och 1.1) har offentligt brutits i år; de säkra är TLS 1.2 och TLS 1.3.
Chiffrat — det specifika recept TLS använder för att göra krypteringen. Vissa chiffrar (som RC4, DES och 3DES) har knäckts och är nu förbjudna; moderna chiffrar är fortfarande starka.

Den här sidan täcker båda, för en webbplats kan få en rätt och den andra fel. Du kan ha ett modernt lås med ett gammalt, knäckbart recept fortfarande påslaget — eller ett starkt recept skyddat av ett föråldrat lås. Antingen gap är en öppen dörr. Båda stängs vanligtvis av samma enkla gratis ändring av din server eller hostinginställningar.

Vad det här kan kosta dig

En kund rånas på offentligt Wi-Fi. Någon loggar in på sitt konto eller betalar från ett hotell, café eller flygplats. Eftersom din webbplats fortfarande tillåter en gammal TLS-version eller ett svagt chiffra tvingar en person på samma nätverk anslutningen ned till det trasiga alternativet och läser deras lösenord och kortnummer i realtid. Bedrägeriet landar på kunden, men skulden — och supportsamtalet — landar på dig.
Dina kortbetalningar stängs av. Betalningssäkerhetsregler (PCI DSS) kräver TLS 1.2 som minimum och förbjuder uttryckligen svaga chiffrar som RC4. När din behandlare reviderar dig, eller när du söker om att ta kort, underkänner en föråldrad konfiguration kontrollen och din kassa fryses tills det är åtgärdat — exakt fel tidpunkt för kassaflödet.
En affär stannar i en säkerhetsgranskning. Innan en större kund skriver på kör deras IT-team en rutinmässig skanning. Den flaggar omedelbart att din webbplats fortfarande accepterar trasig kryptering — den typen av fynd som ser slarvig ut och får en köpare att undra vad annat som är löst. Kontraktet sitter i limbo för ett problem som kostar ingenting att åtgärda.
En tillsynsmyndighet ställer den besvärliga frågan. Efter ett klagomål eller intrång är det första en dataskyddsmyndighet vill veta om du skyddade persondata “på lämpligt sätt.” Att köra kryptering som har varit känt trasig offentligt i år är väldigt svårt att försvara, och “vi visste inte att den gamla versionen fortfarande var på” är inte ett bekvämt svar.
Det gömmer sig bakom hänglåset i år. Eftersom din webbplats fortfarande visar ett normalt hänglås märker ingen gapet — tills en enda avlyssnad inloggning eller ett kortnummer blir en offentlig incident mycket dyrare än den fem-minuters åtgärd hade varit.

Vad det faktiskt är

TLS-versionen

En webbplats stöder inte bara en version av TLS — den kan erbjuda flera på en gång och låta varje besökares webbläsare välja. En modern besökare kommer att använda den senaste tillgängliga versionen och se ett normalt hänglås. Faran är att de gamla, trasiga versionerna kan sitta där tillsammans med de bra som en öppen bakdörr: en angripare kan tvinga en besökares anslutning att “nedgradera” till TLS 1.0 eller 1.1 och sedan exploatera de kända svagheterna i de versionerna (BEAST- och POODLE-attackerna är de kända exemplen) för att dekryptera trafiken.

Så vår kontroll ansluter till din webbplats och testar varje version individuellt — TLS 1.0, 1.1, 1.2 och 1.3 — för att se vilka din server fortfarande accepterar. Så här ser “bra” ut och hur det betygsätts:

TLS 1.3 (med eller utan 1.2), och inga legacy: bästa resultatet — en modern, ren konfiguration. Fullt betyg.
Bara TLS 1.2, inget 1.3: säkert och godkänt, men du lämnar den senaste, snabbaste versionen på bordet.
TLS 1.0 eller 1.1 fortfarande accepterat: ett automatiskt underkänt, betygsatt noll och flaggat kritiskt — det spelar ingen roll att 1.2/1.3 också fungerar, för de trasiga versionerna är den öppna dörren. Det här är vad du måste åtgärda.

Chiffrat

När en version är vald väljer TLS ett chiffra — den faktiska algoritmen som krypterar datan. De flesta moderna chiffrar är starka. En handfull är trasiga och får aldrig användas: RC4 (dess kryptering är förskjuten och läcker klartexten), DES (dess nyckel är så kort att den kan brute-forceras), 3DES (sårbar för “Sweet32”-attacken), plus NULL (ingen kryptering alls), EXPORT-grade chiffrar (avsiktligt försvagade — FREAK- och Logjam-attackerna), och anonyma chiffrar (ingen identitetskontroll, så en bedragare kan sitta i mitten).

Vår chiffer-kontroll gör två saker. Först tittar den på chiffrat din server faktiskt förhandlade med oss. Sedan — och det här är den viktiga delen — försöker den aktivt skaka hand med hjälp av flera kända-trasiga chiffrar (RC4, 3DES, EXPORT, NULL och anonyma varianter). En server kan välja ett starkt chiffra när man pratar med en modern klient men ändå acceptera ett svagt om en angripare insisterar — och det är en verklig nedgraderingsrisk. Om din server accepterar ett förbjudet chiffra flaggar kontrollen det.

De tre informativa extrafunktionerna

Tre relaterade objekt rapporteras men påverkar inte ditt betyg — de flaggas som informativa för att de inte kan verifieras pålitligt utifrån, och på alla moderna servrar eller CDN hanteras de redan korrekt:

TLS-komprimering (CRIME-attacken): en gammal funktion som, om den lämnas på, kan låta en angripare locka fram sessionskakor. Den är inaktiverad som standard i alla moderna webbservrar i över ett decennium.
OCSP-fästning: en prestanda- och integritetsförbättring där din server pre-hämtar bevis på att dess certifikat inte har återkallats. CDN som Cloudflare gör det här automatiskt.
Säker omförhandling: en fix för en gammal brist (CVE-2009-3555). TLS 1.3 tog bort omförhandling helt, så det är inget problem där, och moderna TLS 1.2-servrar implementerar fixet som standard.

Vi presenterar dessa så att din IT-person har hela bilden, men för de allra flesta ägare finns det ingenting att göra.

Så här åtgärdar du det (gratis, ~30 minuter)

Skicka det här till din IT-person — åtgärden är gratis. Det här avsnittet är för den som hanterar din domän, webbplats eller hosting. Åtgärden är en konfigurationsändring, inte ett köp; vi tar bara betalt för att övervaka att din kryptering förblir korrekt konfigurerad över tid.

Det enklaste pålitliga tillvägagångssättet är att generera en känd-god konfiguration snarare än att skriva en för hand: klistra in din servertyp i Mozillas SSL Configuration Generator på https://ssl-config.mozilla.org/ och välj profilen “Intermediate” (bred kompatibilitet) eller “Modern” (bara TLS 1.3, om du inte behöver stöda något gammalt). Den matar ut de korrekta ssl_protocols- och ssl_ciphers-raderna åt dig.

Per plattform:

Cloudflare eller en hanterad värd — vanligtvis en eller två klick. I Cloudflare: SSL/TLS → Kantcertifikat → Minimum TLS-version → TLS 1.2, och chiffersviterna hanteras åt dig (plattformen erbjuder inte förbjudna chiffrar). De flesta hanterade värdar och webbplatsbyggare (Squarespace, Wix, Shopify, moderna WordPress-värdar) verkställer redan TLS 1.2+ med starka chiffrar — bekräfta bara att det inte finns något “legacy TLS”- eller “gammal webbläsarkompatibilitet”-alternativ fortfarande påslaget.

Nginx. Sätt moderna versioner och en explicit stark chifferlista, ladda sedan om:

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;

Apache. Inaktivera de gamla versionerna och pin en stark chifferlista, starta sedan om:

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

Windows / IIS. Använd det gratis IIS Crypto-verktyget för att inaktivera TLS 1.0 och 1.1, inaktivera RC4/DES/3DES/NULL/EXPORT-chiffrar och lämna TLS 1.2 och 1.3 med starka chiffrar aktiverade. Verktygets “Best Practices”-mall gör allt detta med ett klick.
De informativa extrafunktionerna (valfritt, gratis). Om du vill ha den rena soningen: på Nginx lägg till ssl_stapling on; ssl_stapling_verify on; (med en resolver-rad) för OCSP-fästning; på Apache, SSLUseStapling On. TLS-komprimering och säker omförhandling är redan säkra som standard på moderna servrar — ingen åtgärd krävs. På Cloudflare hanteras alla tre automatiskt.
Verifiera, kontrollera sedan här igen. Bekräfta att bara de säkra versionerna och chiffrarna kvarstår — till exempel med nmap --script ssl-enum-ciphers -p 443 dindomän.com, eller testa på https://ssl-config.mozilla.org/s länkade verktyg — kör sedan om den här kontrollen. Aktivera TLS 1.3 vid sidan av 1.2 där möjligt: det är både snabbare och säkrare.

Vanliga misstag

“Vi har ett hänglås, så vi är bra.” Hänglåset bevisar bara att en säker anslutning finns. Det säger ingenting om huruvida en gammal version eller ett förbjudet chiffra fortfarande accepteras i bakgrunden — vilket är exakt det gap de här kontrollerna hittar.
Åtgärda versionen men inte chiffrarna (eller vice versa). Att inaktivera TLS 1.0/1.1 tar inte automatiskt bort RC4 eller 3DES, och att pin-ta starka chiffrar inaktiverar inte automatiskt gamla versioner. Sätt båda — den genererade konfigurationen ovan gör det.
Lämna “legacy”- eller “gammal webbläsarkompatibilitet”-alternativ på. Många värdar och CDN har ett alternativ som tyst återaktiverar de trasiga versionerna eller svaga chiffrarna “för kompatibilitet.” Det hjälper nästan aldrig en riktig besökare och orsakar direkt den här flaggan.
Glömma att faktiskt ladda om/starta om servern. Konfigurationsändringar träder inte i kraft förrän webbservern laddas om — en förvånansvärt vanlig orsak till att en “åtgärdad” webbplats fortfarande underkänns vid omkontroll.
Konfigurera en server men inte alla. Om du kör en lastbalanserare, flera webbservrar eller separata subdomäner (shop, blog, app) behöver varje TLS-slutpunkt samma konfiguration — den svagaste är vad en angripare riktar in sig på.

Vad du ska komma ihåg

TLS versionen och chiffrat är de två delarna av din kryptering som faktiskt rör ditt betyg, och båda handlar om att stänga av alternativ som har brutits offentligt i år. Åtgärden är gratis, det är vanligtvis en modern konfigurationsrad per server, och för en normal besökare ändrar det ingenting förutom att deras anslutning är genuint säker. De relaterade objekten — komprimering, OCSP-fästning, säker omförhandling — är värda att känna till men påverkar inte ditt betyg, och på alla moderna konfigurationer hanteras de redan åt dig.

Vanliga frågor

Jag är inte teknisk — kan jag lösa det här själv?

Du behöver inte förstå de tekniska detaljerna. På de flesta moderna hostingalternativ är det en eller två inställningar, och det är gratis. Skicka avsnittet 'Så här åtgärdar du det' nedan till den som driver din webbplats eller hosting (eller din IT-leverantör) — det är vanligtvis en fem-till-tio-minuters ändring utan synlig skillnad för dina besökare förutom en säkrare anslutning.

Slutar gamla kunders webbläsare att fungera om vi byter till modern kryptering?

I praktiken nej. Alla moderna webbläsare och telefoner från ungefär det senaste decenniet använder redan den nya krypteringen och starka chiffrarna som standard — de har gjort det i år. Det enda som förlitade sig på de gamla versionerna eller svaga chiffrarna är i sig föråldrade och osäkra, vilket är exakt varför alla stora webbläsare redan vägrar dem. För nästan alla företag är ändringen osynlig för kunderna.

Min webbplats laddas bra med ett hänglås — varför flaggas det här fortfarande?

Hänglåset innebär bara att en säker anslutning finns; det berättar inte vilken version av TLS eller vilket chiffra som ligger bakom den. Din webbplats kan visa ett helt normalt hänglås medan den fortfarande tyst accepterar en gammal trasig version eller ett förbjudet chiffra tillsammans med de bra — och den öppna bakdörren är vad de här kontrollerna fångar. Att stänga den tar inte bort hänglåset; det ser bara till att bara de säkra alternativen tillåts.

Vad är skillnaden mellan TLS-versionen och chiffrat?

Tänk på TLS-versionen som vilken generation av låset du använder, och chiffrat som det specifika recept det använder för att kryptera datan. Du kan ha ett modernt lås (TLS 1.2 eller 1.3) men fortfarande ha ett gammalt, knäckbart recept (som RC4 eller 3DES) påslaget — eller tvärtom. Båda måste vara rätt, vilket är varför vi kontrollerar dem separat. Den goda nyheten är att samma moderna konfigurationsrad vanligtvis åtgärdar båda på en gång.

Vad gäller OCSP-fästning och TLS-komprimering — påverkar de mitt betyg?

Nej. De (tillsammans med säker omförhandling) är bara informativa — vi rapporterar om dem för att de spelar roll för prestanda och djupförsvar, men de rör inte ditt betyg. På moderna webbservrar och alla CDN som Cloudflare hanteras de korrekt som standard, så för de flesta ägare finns det ingenting att göra. Detaljen finns i avsnittet nedan för din IT-person.

Är det verkligen gratis att åtgärda?

Ja. Att inaktivera gamla TLS-versioner och svaga chiffrar, och aktivera dessa skydd, är konfigurationsändringar på din befintliga server eller hosting — det finns ingenting att köpa. Vi tar bara betalt för att övervaka att din kryptering förblir korrekt konfigurerad över tid, inte för att åtgärda det.