Vilka typer av attacker förhindrar SSL?

SSL/TLS förhindrar avlyssning, manipulering och personifiering genom att kryptera data under överföring och verifiera serveridentitet via ett digitalt certifikat, även om felkonfigurerade eller föråldrade implementeringar fortfarande är sårbara för specifika nedgraderings- och protokollattacker.

SSL/TLS förhindrar angripare från att läsa eller modifiera data under överföring och från att utge sig för att vara en betrodd server, vilket skyddar mot avlyssning, man-in-the-middle-attacker och datamanipulering. Det förhindrar inte automatiskt attacker på protokollnivå som POODLE, FREAK eller Logjam, som utnyttjar föråldrade versioner, svaga chiffersviter eller felkonfigurationer snarare än att bryta krypteringen direkt.

Key Takeaways

• TLS 1.3, definierad i RFC 8446, är den nuvarande säkerhetsstandarden. SSL och TLS 1.0/1.1/1.2 är föråldrade; äldre versioner är fortfarande sårbara för nedgraderingsattacker som POODLE.
• De flesta namngivna SSL/TLS-attacker utnyttjar konfigurationen, inte själva protokollet. POODLE, FREAK, Logjam och DROWN förlitar sig alla på en server som fortfarande stöder föråldrade protokoll eller svaga chiffersviter tillsammans med TLS 1.3.
• Fel under certifikatlivscykeln orsakar lika många incidenter som protokollattacker. Utgångna, självsignerade eller oåterkallade komprometterade certifikat skapar öppningar för man-in-the-middle-attacker som inte har något att göra med själva TLS-handskakningen.
• Wildcard-certifikat bör inte täcka känsliga underdomäner. En enda komprometterad jokerteckennyckel kan exponera alla underdomäner den täcker, inklusive inloggnings- och betalningssidor.
• Om du inaktiverar stöd för äldre protokoll stängs de flesta namngivna attackvektorer. Att endast stödja TLS 1.2 och TLS 1.3, med moderna chiffersviter, eliminerar POODLE, FREAK, Logjam och BEAST som gångbara attacker.

SSL vs TLS

TLS är den direkta efterföljaren till SSL, och TLS 1.3 är den nuvarande, säkraste versionen som används i stor utsträckning idag.

TLS 1.3 definieras i RFC 8446 och skyddar själva handskakningen mot nedgraderingsattacker som drabbade tidigare versioner. SSL och TLS 1.0/1.1 är föråldrade i större webbläsare på grund av kända sårbarheter, och TLS 1.2 stöds fortfarande men fasas ut till förmån för 1.3.

Vanliga SSL/TLS-attacker och hur de kan mildras

Sex namngivna attacker står för de flesta av de historiska SSL/TLS-exploateringsteknikerna, och var och en har en specifik, väl dokumenterad lösning.

Attack	Vad den utnyttjar	Mitigation
PUDEL	Sårbarhet i SSLv3-utfyllnad i Oracle	Inaktivera SSLv3; stöder endast TLS 1.2 eller högre
FREAK	Svaga RSA-krypteringssviter av exportkvalitet	Inaktivera stöd för exportklassad chiffersvit
logjam	512-bitars Diffie-Hellman-grupper av exportkvalitet	Inaktivera Diffie-Hellman-krypteringssviter av exportkvalitet
DRUNKNA	Servrar som fortfarande stöder SSLv2	Se till att privata nycklar aldrig används på SSLv2-aktiverade servrar
Sweet32	64-bitars blockchiffer i CBC-läge	Inaktivera äldre 64-bitarschiffrar som DES och 3DES
FÄ	CBC-implementeringsfel i TLS 1.0	Använd webbläsare och servrar som stöder TLS 1.1 eller högre

Var och en av dessa attacker riktar sig mot en specifik funktion i äldre protokoll eller en svag chiffersvit snarare än att bryta TLS 1.3 direkt, vilket är anledningen till att inaktivering av stöd för äldre protokoll stänger de flesta av dem samtidigt.

Attacker som utnyttjar certifikathantering, inte protokollet

Man-in-the-middle-attacker lyckas ofta genom felaktig certifikathantering snarare än en brist i själva TLS.

• Självsignerade certifikat i produktion. Ett självsignerat certifikat har ingen oberoende validering och bör begränsas till testmiljöer, aldrig produktionssystem.
• Oåterkallade komprometterade certifikat. Ett certifikat som borde ha återkallats efter en nyckelkompromettering förblir användbart av en angripare tills det faktiskt återkallas, inte bara ersätts.
• Otillförlitliga eller okända certifikatutfärdare. Certifikat från okända, oreviderade certifikatutfärdare skapar risker om certifikatutfärdaren senare komprometteras eller utges för att vara en certifikatutfärdare.
• SSL-stripping och sessionskapning. Dessa attacker lurar en användare till en okrypterad anslutning eller stjäl ett aktivt sessions-ID snarare än att attackera krypteringen direkt; HSTS och säkra cookieflaggor är standardförsvaret.

Minska din SSL/TLS-attackyta

En liten uppsättning konfigurationsval stänger större delen av attackytan som beskrivs ovan.

• Undvik jokerteckencertifikat på känsliga underdomäner. Använd individuella certifikat för inloggning, betalning och administratörsunderdomäner så att en enskild komprometterad nyckel har begränsad räckvidd.
• Undvik okända eller opålitliga certifikatutfärdare. Identifiera varje certifikatutfärdare som används och ersätt certifikat från okända källor med certifikat från betrodda, granskade certifikatutfärdare.
• Håll certifikatens livscykler aktuella. Utgångna certifikat är fortfarande en av de vanligaste orsakerna till både avbrott och MITM-exponering.
• Aktivera HSTS. HTTP Strict Transport Security tvingar webbläsare att använda HTTPS som standard stängs den initiala okrypterade begäran som SSL-stripping är beroende av.

SSL/TLS-sårbarhetsattacker

Precis som med andra protokoll har även SSL/TLS-protokoll sina brister. Nedan följer attacker som påverkar SSL/TLS 1.2 och äldre versioner.

• BEAST Attack

  BEAST-attacker (Browser Exploit Against SSL/TLS) påverkar SSL 3.0 och TLS 1.0 genom att utnyttja sårbarheten (CVE-2011-3389). I denna attack kan angriparen utnyttja en sårbarhet i implementeringen av CBC (chifferblockkedja) i TLS 1.0. Detta gör det möjligt för angriparen att dekryptera krypterad data mellan två användare/system genom att injicera de skapade paketen i TLS-strömmar med hjälp av MITM-tekniker.

  Dessa tekniker gör det möjligt för angriparen att gissa initialiseringsvektorn som används med det injicerade meddelandet. De kan sedan jämföra resultaten med resultaten i blocket som de vill dekryptera. Denna attack kräver åtkomst till klientens (offrets) dators webbläsare som en förutsättning. För att genomföra denna attack framgångsrikt kan angriparen använda andra attackvektorer i de inledande skedena. För att övervinna denna attack, använd webbläsare som stöder TLS 1.1 eller högre.

• BROTTSANFATTNING

  I CRIME-attacker (Compression Ratio Info Leak Made Easy) utnyttjas mekanismen för komprimeringsalgoritmer, vilket täcks av sårbarheten (CVE-2012-4929). Generellt sett inkluderas komprimeringsmetoden i serverns hello-meddelande som svar på klientens hello-meddelande för att minska bandbreddskravet för datautbytet. För att underlätta denna process skickar servern "komprimeringsmetoden" (DEFLATE används oftast) till klienten, medan servern skickar komprimeringsmetoden "NULL" till klienten om ingen komprimering krävs.

  En av de primära teknikerna som används av komprimeringsalgoritmer är att ersätta de upprepade bytesekvenserna i meddelandet med en pekare till den första förekomsten av den sekvensen. Ju större de upprepade sekvenserna är, desto högre är komprimeringsförhållandet. För att åtgärda denna attack, använd din webbläsare som stöder det senaste TLS-protokollet (TLS 1.3).

• BREACH-attack

  BREACH-attacken (Browser Reconnaissance and Exfiltration via Compression of Hypertext) syftar till att utnyttja komprimeringsmekanismen som används av HTTP snarare än TLS, vilket är fallet vid CRIME-attacker. Denna sårbarhet listas i NIST NVD-databasen som CVE-2013-3587. Denna sårbarhet kan utnyttjas även när TLS-komprimeringen är avstängd. Detta görs genom att omdirigera klientens (offrets) webbläsartrafik till en tredjeparts-URL som är TLS-aktiverad, och övervaka trafiken mellan server och klient med hjälp av MITM-attacktekniker. Webbservrarna som använder HTTP-komprimering reflekterar användarinmatning/hemligheter i HTTP-svarstexter och är benägna att vara sårbara för detta. För att kontrollera denna sårbarhet kan du inaktivera HTTP-nivåkomprimering, separera hemligheter från användarinmatningar och maskera hemligheter.

• HJÄRTBLÖDNINGSattack

  Heartbleed var en kritisk attack som avslöjade sårbarheten i heartbeat-tillägget i openssl-biblioteket, och listas i NIST NVD-databasen som CVE-2014-0160. Heartbeat-tillägget används för att hålla en anslutning vid liv så länge båda parter fortfarande är där.

  Låt oss förstå Heartbleed-funktionen i OpenSSL-biblioteket. Klienten skickar heartbeat-meddelandet med data och storlek till servern. Servern svarar sedan tillbaka med klientens mottagna data och storleksdata. Heartbleed-sårbarheten syftade till att utnyttja det faktum att om klienten skickar en falsk datalängd till servern, så skulle servern svara tillbaka med slumpmässig data från sitt minne för att uppfylla det längdkrav som klienten angett.

  Slumpmässig okrypterad data från serverns minne kan innehålla kritisk information, såsom privata nycklar, kreditkortsuppgifter och annan känslig information. För att åtgärda Heartbleed-sårbarheten, uppgradera antingen till den senaste versionen av openssl-biblioteket eller kompilera om den installerade versionen med flaggan "DOPENSSL_NO_HEARTBEATS".

Hur skyddar man sig mot SSL-attacker?

Som förklarats i avsnitten ovan angående några av de vanliga SSL-attackerna är det viktigt att organisationer granskar sina säkerhetspolicyer relaterade till SSL-skydd. Att bara implementera SSL eller TLS garanterar inte säkerheten för din infrastruktur och ditt företag. Det måste istället hanteras med rätt policyer, processer och procedurer för att minimera riskerna. Dessutom finns det flera tekniker och verktyg tillgängliga på marknaden för att säkra ditt företag. Valet av dessa verktyg/säkerhetsprodukter är dock en funktion av ditt företags natur och säkerhetsmål och bör bestämmas efter en noggrann undersökning av varje aspekt av säkerheten.

Hur kan krypteringskonsulting hjälpa till?

CertSecure Manager minskar certifikathanteringssidan av SSL/TLS-risken genom att automatisera upptäckt, återkallelse och förnyelse så att utgångna, självsignerade eller oåterkallade certifikat inte dröjer sig kvar i produktionen. Encryption Consultings krypteringsrådgivningstjänster utvärderar protokoll- och krypteringskonfigurationer för att stänga den återstående attackytan för nedgraderingar och äldre protokoll. Stöds av ISO/IEC 27001:2022- och SOC 2-certifierade metoder.

Vanliga frågor om partihandel med mat och dryck

Gör SSL/TLS en webbplats helt säker?

Nej. SSL/TLS krypterar data under överföring och verifierar serveridentitet, men det skyddar inte mot alla hot. Felkonfigurerade servrar, utgångna eller ej återkallade certifikat, svaga krypteringssviter och sårbarheter på applikationsnivå är alla möjliga även med TLS aktiverat.

Vad är skillnaden mellan SSL och TLS?

TLS är efterföljarprotokollet till SSL, och namnet ändrades när SSL 3.0 uppdaterades till TLS 1.0. SSL och TLS 1.0/1.1 är nu föråldrade på grund av kända sårbarheter; TLS 1.3, definierad i RFC 8446, är den nuvarande standarden.

Varför är jokerteckencertifikat ett säkerhetsproblem?

Ett jokerteckencertifikat använder en privat nyckel för varje underdomän det täcker. Om nyckeln komprometteras exponeras varje underdomän samtidigt. Känsliga underdomäner som inloggnings- eller betalningssidor bör istället använda individuella certifikat.

Kan ett utgånget certifikat leda till en man-in-the-middle-attack?

Ja. Organisationer som inte hanterar certifikatlivscykler korrekt kan få komprometterade eller utgångna certifikat som aldrig återkallats. En angripare kan fortsätta använda ett sådant certifikat för att skapa förtroende hos en komprometterad webbplats och avlyssna trafik som ser krypterad ut.

Vad är HSTS och varför är det viktigt för SSL/TLS-säkerhet?

HTTP Strict Transport Security (HSTS) instruerar webbläsare att alltid ansluta via HTTPS, vilket förhindrar den initiala okrypterade begäran som SSL-strippingattacker är beroende av. Det kräver att man lägger till en specifik svarsrubrik och är ett av de mer effektiva och ansträngningsfria försvaren mot nedgraderingsliknande attacker.

Stäng din SSL/TLS-attackyta

Se CertSecure Manager i praktiken för att hålla certifikat aktuella och återkallade i tid, eller prata med en krypteringskonsult om din TLS-konfiguration.