Allmänt

SSL (och dess efterträdare, TLS ) är ett protokoll som fungerar direkt ovanpå TCP (även om det också finns implementeringar för datagrambaserade protokoll som UDP). På så sätt kan protokoll på högre lager (t.ex. HTTP) lämnas oförändrade medan s för att ge en säker anslutning. Under SSL-lagret är HTTP identisk med HTTPS.

När du använder SSL / TLS korrekt kan allt som en angripare ser på kabeln vara vilken IP och port du är ansluten till, ungefär hur mycket data du skickar , och vilken kryptering och komprimering som används. Han kan också avsluta anslutningen, men båda sidor vet att anslutningen har avbrutits av en tredje part.

I typisk användning kommer angriparen också att kunna ta reda på vilket värdnamn du ansluter till (men inte resten av webbadressen): även om HTTPS i sig inte exponerar värdnamnet, måste din webbläsare vanligtvis göra en DNS-begäran först för att ta reda på vilken IP-adress du vill skicka begäran till.

Hög -nivåbeskrivning av protokollet

Efter att ha skapat en TCP-anslutning startas SSL-handskakningen av klienten. Klienten (som kan vara en webbläsare och alla andra program som Windows Update eller PuTTY) skickar ett antal specifikationer:

• vilken version av SSL / TLS den kör,
• vad chiffror det vill använda och
• vad komprimeringsmetoder den vill använda.

Servern identifierar den högsta SSL / TLS-versionen som stöds av både den och klienten, väljer en chifferversion från ett av klientens alternativ (om den stöder en) och väljer valfritt en komprimeringsmetod.

Efter det att den grundläggande installationen är klar skickar servern sitt certifikat. Det här certifikatet måste lita på antingen klienten själv eller en part som klienten litar på. Om klienten till exempel litar på GeoTrust kan klienten lita på certifikatet från Google.com eftersom GeoTrust kryptografiskt signerat Googles certifikat.

Efter att ha verifierat certifikatet och är säker på att den här servern verkligen är den han påstår sig vara (och inte en man i mitten) byts en nyckel ut. Detta kan vara en offentlig nyckel, en ” PreMasterSecret ” eller helt enkelt ingenting, beroende på den valda chiffran. Både servern och klienten kan nu beräkna nyckeln för symmetrisk kryptering ^{whynot PKE?} . Klienten säger till servern att från och med nu kommer all kommunikation att krypteras, och skickar ett krypterat och autentiserat meddelande till servern.

Servern verifierar att MAC (används för autentisering) är korrekt och att meddelandet kan dekrypteras korrekt. Den returnerar sedan ett meddelande som klienten verifierar som väl.

Handskakningen är nu klar och de två värdarna kan kommunicera säkert. Mer information finns på technet.microsoft.com/en-us/library/cc785811 och en.wikipedia .org / wiki / Secure_Sockets_Layer .

För att stänga anslutningen används en close_notify ”alert”. Om en angripare försöker avsluta anslutningen genom att avsluta TCP-anslutningen (injicera ett FIN-paket) vet båda sidor att anslutningen avbröts felaktigt. Anslutningen kan dock inte komprometteras av detta, utan bara avbrutet.

Några mer detaljer

Varför kan du lita på Google.com genom att lita på GeoTrust?

En webbplats vill kommunicera säkert med dig. För att bevisa sin identitet och se till att den inte är en angripare måste du ha servern ”s offentlig nyckel . Du kan dock knappast lagra alla nycklar från alla webbplatser på jorden skulle databasen vara enorm och uppdateringar måste köras varje timme!

Lösningen på detta är certifikatutfärdare, eller kort sagt CA.När du installerade ditt operativsystem eller webbläsare följer antagligen en lista med betrodda certifikatutfärdare. Denna lista kan ändras efter eget önskemål; du kan ta bort vem du inte litar på, lägga till andra eller till och med skapa din egen CA (även om du kommer att vara den enda som litar på denna CA, så det är inte mycket nytta för den offentliga webbplatsen). I den här CA-listan lagras också CA: s offentliga nyckel.

När Googles server skickar sitt certifikat till den nämns också att den är signerad av GeoTrust. Om du litar på GeoTrust kan du verifiera (med GeoTrusts offentliga nyckel) att GeoTrust verkligen undertecknade servercertifikatet. För att själv kunna underteckna ett certifikat behöver du den privata nyckeln, som endast är känd för GeoTrust. På detta sätt kan en angripare inte underteckna ett certifikat själv och felaktigt göra anspråk på att vara Google.com. När certifikatet har ändrats med en enda bit kommer tecknet att vara felaktigt och klienten kommer att avvisa det.

Så om jag känner till den offentliga nyckeln kan servern bevisa sin identitet?

Ja. Vanligtvis krypteras den offentliga nyckeln och den privata nyckeln. Kryptera ett meddelande med serverns offentliga nyckel, skicka det, och om servern kan upprepa det ursprungliga meddelandet, bevisade det bara att det fick den privata nyckeln utan att avslöja nyckeln.

Det är därför det är så viktigt för att kunna lita på den offentliga nyckeln: vem som helst kan skapa ett privat / offentligt nyckelpar, även en angripare. Du vill inte sluta använda en angripares offentliga nyckel!

Om en av de certifikatutfärdare som du litar på äventyras kan en angripare använda den stulna privata nyckeln för att underteckna ett certifikat för vilken webbplats som helst. När angriparen kan skicka ett förfalskat certifikat till din klient, undertecknat av sig själv med den privata nyckeln från en CA som du litar på, vet inte din klient att den offentliga nyckeln är en förfalskad, signerad med en stulen privat nyckel.

Men en CA kan få mig att lita på vilken server som helst!

Ja, och det är där förtroendet kommer i. Du måste lita på att CA inte gör certifikat som de vill. När organisationer som Microsoft, Apple och Mozilla litar på en CA måste CA dock ha granskningar. En annan organisation kontrollerar dem regelbundet för att se till att allt fortfarande fungerar enligt till reglerna.

Att utfärda ett certifikat görs om, och endast om, registranten kan bevisa att de äger domänen som certifikatet utfärdas för.

Vad är denna MAC för autentisering av meddelanden?

Varje meddelande signeras med en så kallad Meddelandeautentiseringskod , eller MAC för kort. Om vi är överens om en nyckel och hashing-chiffer kan du verifiera att mitt meddelande kommer från mig och jag kan verifiera att ditt meddelande kommer från dig.

Till exempel med nyckeln ” rätt häftklammerhäftning ” och meddelandet ” exempel ”, Jag kan beräkna MAC ” 58393 ”. När jag skickar detta meddelande med MAC till dig (du känner redan till nyckeln) kan du utföra samma beräkning och matcha den beräknade MAC med den MAC som jag skickade.

En angripare kan ändra meddelandet men vet inte nyckeln. Han kan inte beräkna rätt MAC, och du vet att meddelandet inte är giltigt.

Genom att inkludera ett sekvensnummer när du beräknar MAC kan du eliminera omspelning attacker . SSL gör detta.

Du sa att klienten skickar en nyckel som sedan används för att ställa in symmetrisk kryptering. Vad hindrar en angripare från att använda den?

Serverns offentliga nyckel gör det. Eftersom vi har verifierat att den offentliga nyckeln verkligen tillhör servern och ingen annan, kan kryptera nyckeln med den offentliga nyckeln. När servern tar emot den kan han dekryptera den med den privata nyckeln. När någon annan tar emot den kan de inte dekryptera den.

Det är också därför nyckelstorleken är viktig: Ju större den offentliga och privata nyckeln är, desto svårare är det att knäcka den nyckel som klienten skickar till servern.

Hur man spricker SSL

Sammanfattningsvis :

• Försök om användaren ignorerar certifikatvarningar.
• Applikationen kan ladda data från en okrypterad kanal (t.ex. HTTP), som kan manipuleras med;
• En oskyddad inloggningssida som skickas till HTTPS kan modifieras så att den skickas till HTTP;
• Ouppladdade applikationer kan vara sårbar för bedrifter som BEAST och CRIME;
• Tillvägagångssätt för andra metoder suc h som en fysisk attack;
• Utnyttja sidokanaler som meddelandelängd och tiden för att bilda meddelandet;
• Vänta på kvantattacker .

Se även: Ett schema med många attackvektorer mot SSL av Ivan Ristic ^(png)

I detalj:

Det finns ingen enkel och okomplicerad sätt; SSL är säkert när det görs korrekt. En angripare kan försöka om användaren ignorerar certifikatvarningar , vilket skulle bryta säkerheten direkt. När en användare gör detta behöver angriparen inte en privat nyckel från en CA för att förfalska ett certifikat, han måste bara skicka ett eget certifikat.

Ett annat sätt skulle vara genom en brist i applikation (server- eller klientsida). Ett enkelt exempel är på webbplatser: om en av de resurser som används av webbplatsen (t.ex. en bild eller ett skript) laddas över HTTP kan sekretessen inte garanteras längre. skicka inte HTTP-referenshuvudet när du begär osäkra resurser från en säker sida ( källa ), det är fortfarande möjligt för någon som avlyssnar trafik för att gissa var du ”besöker från; om de till exempel vet att bilderna X, Y och Z används på en sida kan de gissa att du besöker den sidan när de ser att din webbläsare begär dessa tre bilder samtidigt. När du laddar Javascript kan hela sidan dessutom äventyras. En angripare kan köra vilket skript som helst på sidan och ändra till exempel till vem banktransaktionen ska gå.

När detta händer (en resurs laddas via HTTP), ger webbläsaren en varning med blandat innehåll: Chrome , Firefox , Internet Explorer 9

Ett annat trick för HTTP är när inloggningssidan inte är säker och den skickas till en https-sida. ” Bra, ” utvecklaren trodde nog, ” nu sparar jag serverbelastning och lösenordet skickas fortfarande krypterat! ” Problemet är sslstrip , ett verktyg som ändrar den osäkra inloggningssidan så att den skickar någonstans så att angriparen kan läsa den.

Det har också skett olika attacker de senaste åren, till exempel TLS-omförhandlingssårbarhet , sslsniff , BEAST , och nyligen, BROTT . Alla vanliga webbläsare är dock skyddade mot alla dessa attacker, så dessa sårbarheter är ingen risk om du kör en uppdaterad webbläsare.

Sist men inte minst kan du använda andra metoder för att få den information som SSL förnekar dig att få. Om du redan kan se och manipulera användarens anslutning kanske det inte är så svårt att ersätta en av hans / hennes .exe-nedladdningar med en keylogger, eller helt enkelt att fysiskt attackera den personen. Kryptografi kan vara ganska säker, men människor och mänskliga fel är fortfarande en svag faktor. Enligt denna uppsats av Verizon involverade 10% av dataintrången fysiska attacker (se sidan 3), så det ” s verkligen något att tänka på.

Kommentarer

• Jag skulle vara intresserad av lite mer förklaring till ” en nyckel byts ut ” mot den symmetriska nyckeln. Hur händer detta att någon med en paketsniffer inte kan komma åt.
• @Yehosef Bra fråga! Jag glömde att förklara det i mitt svar. När man tittar runt visar det sig att det faktiskt finns en fråga tillägnad detta: security.stackexchange.com/q/6290/10863
• @ Iwazaru Alla CA gör detta sedan första dagen. Poängen med ett certifikat är att tillhandahålla den offentliga nyckeln för en viss domän, och poängen att underteckna det för att bevisa att det verkligen är rätt nyckel för domänen. Låt ’ s Kryptera gör exakt vad den ska göra: verifiera att du äger domänen och underteckna ditt certifikat (med din nyckel) om du kan bevisa det. Nu litar alla som litar på att ’ s Kryptera, vilket är praktiskt taget alla webbläsare, litar på det certifikatet.
• Er, nr. TLS implementeras verkligen ovanpå TCP.
• Hittade den här grafisk SSL-handskakningsprocess , mycket tydlig.

Eftersom det allmänna begreppet SSL redan har täckts in i några andra frågor (t.ex. den här och den där ), den här gången går jag för mer information. Detaljer är viktiga. Det här svaret kommer att vara något detaljerat.

Historia

SSL är ett protokoll med en lång historik och flera versioner.De första prototyperna kom från Netscape när de utvecklade de första versionerna av deras flaggskeppswebbläsare, Netscape Navigator (denna webbläsare dödade av Mosaic i de tidiga tiderna av Browser Wars, som fortfarande rasar, om än med nya konkurrenter). Version 1 har aldrig offentliggjorts så vi vet inte hur det såg ut. SSL-version 2 beskrivs i ett utkast som kan läsas där ; det har ett antal svagheter, några av dem ganska allvarliga, så det är utfasat och nyare SSL / TLS-implementeringar stöder inte det (medan äldre inaktiveras som standard). Jag kommer inte att tala om SSL-version 2 längre, förutom som en tillfällig referens.

SSL-version 3 (som jag kommer att kalla ”SSLv3”) var ett förbättrat protokoll som fortfarande fungerar idag och stöds allmänt. Även om det fortfarande är en egendom som tillhör Netscape Communications (eller den som äger det idag), har protokollet publicerats som en ”historisk RFC” ( RFC 6101 ). Under tiden har protokollet standardiserats med ett nytt namn för att undvika juridiska problem; det nya namnet är TLS .

Tre versioner av TLS har hittills producerats, var och en med dess dedikerad RFC: TLS 1.0 , TLS 1.1 och TLS 1.2 . De är internt mycket lika med varandra och med SSLv3, så att en implementering enkelt kan stödja SSLv3 och alla tre TLS-versionerna med minst 95% av koden som vanligt. Fortfarande, internt, är alla versioner betecknade med ett versionsnummer med formatet major.minor ; SSLv3 är då 3.0, medan TLS-versionerna är 3.1, 3.2 respektive 3.3. Således är det inte konstigt att TLS 1.0 ibland kallas SSL 3.1 (och det är inte fel heller). SSL 3.0 och TLS 1.0 skiljer sig åt med bara några minutdetaljer. TLS 1.1 och 1.2 stöds ännu inte allmänt, även om det finns en drivkraft för det på grund av möjliga svagheter (se nedan för ”BEAST attack”). SSLv3 och TLS 1.0 stöds ”överallt” (även IE 6.0 känner till dem).

Kontext

SSL syftar till att tillhandahålla en säker dubbelriktad tunnel för godtyckliga data. Tänk på TCP , det välkända protokollet för att skicka data över Internet. TCP fungerar över IP-paketen och tillhandahåller en dubbelriktad tunnel för byte. det fungerar för varje bytevärde och skickar dem till två strömmar som kan fungera samtidigt. TCP hanterar det hårda arbetet med att dela upp data i paket, bekräfta dem, återmontera dem i rätt ordning, samtidigt som man tar bort dubbletter och skickar bort förlorade paket. Ur applikationssynpunkt som använder TCP finns det bara två strömmar och paketen är osynliga; i synnerhet är strömmarna inte uppdelade i ”meddelanden” (det är upp till applikationen att ta sina egna kodningsregler om den vill ha meddelanden, och det är precis vad HTTP gör).

TCP är pålitlig i närvaro av ”olyckor”, dvs överföringsfel på grund av fläckig hårdvara, nätverksbelastning, personer med smartphones som går utanför räckvidden för en given basstation och andra icke-skadliga händelser. En dåligt avsedd individ (”angriparen”) med viss åtkomst till transportmediet kunde dock läsa all den överförda informationen och / eller ändra den avsiktligt, och TCP skyddar inte mot det. SSL.

SSL antar att det fungerar över ett TCP-liknande protokoll, vilket ger en tillförlitlig ström; SSL implementerar inte återupptagande av förlorade paket och sådant. antas ha makten för att störa kommunikationen helt på ett oundvikligt sätt (till exempel kan han klippa kablarna) så SSL: s jobb är att:

• upptäcka ändringar (angriparen får inte kunna ändra uppgifterna tyst );
• säkerställa data konfidentialitet ( angriparen får inte få kunskap om de utbytta uppgifterna.

SSL uppfyller dessa mål i stor utsträckning (men inte absolut).

Registrerar

SSL är lager och det undre lagret är protokoll . Oavsett vilken data som skickas i en SSL-tunnel delas upp i poster . Över tråden (det underliggande TCP-uttaget eller TCP-liknande medium) ser en post ut så här:

HH V1:V2 L1:L2 data

där:

• HH är en enda byte som anger typ av data i posten.Fyra typer definieras: change_cipher_spec (20), alert (21), handshake (22) och application_data ( 23).
• V1: V2 är protokollversionen, över två byte. För alla versioner som för närvarande är definierade har V1 värde 0x03, medan V2 har värde 0x00 för SSLv3, 0x01 för TLS 1.0, 0x02 för TLS 1.1 och 0x03 för TLS 1.2.
• L1: L2 är längden på data, i byte (stor endian-konvention är används: längden är 256 * L1 + L2). Den totala längden på data får inte överstiga 18432 byte, men i praktiken kan den inte ens nå det värdet.

Så en post har fem- bytehuvud, följt av högst 18 kB data. data är där symmetrisk kryptering och integritetskontroller tillämpas. När en post emitteras, ska både avsändare och mottagare komma överens om vilka kryptografiska algoritmer som för närvarande tillämpas och med vilka nycklar; detta avtal erhålls genom handskakningsprotokollet, beskrivet i nästa avsnitt. Komprimering, om någon, tillämpas också vid den punkten.

I fullständiga detaljer fungerar byggandet av en post så här:

• Ursprungligen finns det några byte att överföra ; det här är applikationsdata eller någon annan typ av byte. Denna nyttolast består av högst 16384 byte, men möjligen mindre (en nyttolast med längden 0 är laglig, men det visar sig att Internet Explorer 6.0 inte gillar det alls ) .
• Nyttolasten komprimeras sedan med den komprimeringsalgoritm som för närvarande överenskommits. Komprimering är statlig och kan därför bero på innehållet i tidigare poster. I praktiken är komprimering antingen ”null” (ingen komprimering alls) eller ”Deflate” ( RFC 3749 ), den senare visas för närvarande tillmötesgående men bestämt utgången dörr i webbsammanhang på grund av den senaste CRIME-attacken . Komprimering syftar till att förkorta data, men den måste nödvändigtvis utvidga den något i ogynnsamma situationer (på grund av principen om duvahål ). SSL möjliggör en expansion på högst 1024 byte. Naturligtvis utvidgas nollkomprimering aldrig (men förkortas aldrig heller); Tömningen expanderar med högst tio byte om implementeringen är bra.
• Den komprimerade nyttolasten skyddas sedan mot förändringar och krypteras. Om de nuvarande krypterings- och integritetsalgoritmerna är ”null”, är det här steget utan åtgärd. Annars läggs en MAC till, sedan lite stoppning (beroende på krypteringsalgoritmen) och resultatet krypteras. Dessa steg inducerar återigen en del expansion, vilket SSL-standarden begränsar till 1024 extra byte (kombinerat med maximal expansion från komprimeringssteget, detta leder oss till 18432 byte, till vilka vi måste lägga till 5-byte-rubriken).

MAC är vanligtvis HMAC med en av de vanliga hashfunktionerna (mestadels MD5, SHA-1 eller SHA-256) (med SSLv3 är detta inte den ”sanna” HMAC utan något mycket liknande och, så vitt vi vet, lika säker som HMAC). Kryptering använder antingen en blockkryptering i CBC-läge eller RC4 strömkryptering. Observera att i teorin kan andra typer av lägen eller algoritmer användas, till exempel ett av dessa fiffiga lägen som kombinerar kryptering och integritetskontroller; det finns till och med några RFC för det . I praktiken känner dock inte implementerade implementeringar till dessa ännu, så de gör HMAC och CBC. Avgörande är att MAC först beräknas och läggs till data och resultatet krypteras. Detta är MAC-då-kryptera och det är faktiskt inte så bra idé . MAC beräknas över sammankopplingen av (komprimerad) nyttolast och ett sekvensnummer så att en flitig angripare inte kan byta poster.

Handshake

handskakningen är ett protokoll som spelas inom postprotokollet. Målet är att fastställa algoritmer och nycklar som ska användas för posterna. Den består av meddelanden . Varje handskakningsmeddelande börjar med en fyra-byte-rubrik, en byte som beskriver meddelandetypen, sedan tre byte för meddelandets längd (big-endian-konvention). De på varandra följande handskakningsmeddelanden skickas sedan med poster taggade med typen ”handskakning” (den första byten i rubriken för varje post har värde 22).

Observera lagren: handskakningsmeddelandena, kompletta med fyra- bytehuvud, skickas sedan som poster, och varje post också har sin egen rubrik. Dessutom kan flera handskakningsmeddelanden skickas inom samma post, och ett givet handskakningsmeddelande kan delas över flera poster.Ur synvinkeln för modulen som bygger handskakningsmeddelandena är ”posterna” bara en ström som byte kan skickas till; det är omedvetet om den faktiska uppdelningen av den strömmen i poster.

Full Handshake

Inledningsvis ”enas” klient och server om nullkryptering utan MAC- och nullkomprimering. Detta innebär att posten de först skickar kommer att skickas som klartext och oskyddad.

Det första meddelandet i ett handskakning är en ClientHello. Det är meddelandet genom vilket klienten anger sin avsikt att göra lite SSL. Observera att ”klient” är en symbolisk roll; det betyder ”det parti som talar först”. Det händer så att alla tre lager i HTTPS-sammanhanget, som är HTTP-inom-SSL-inom-TCP, har en uppfattning om ”klient” och ”server”, och de är alla överens (TCP-klienten är också SSL-klienten och HTTP-klienten), men det är en slump.

Meddelandet ClientHello innehåller:

• det maximala protokollet version som klienten vill stödja;
• ”klienten slumpmässig” (32 byte, varav 28 är tänkt att genereras med en kryptografiskt stark talgenerator);
• ” session-ID ”(om klienten vill återuppta en session i ett förkortat handslag, se nedan).
• listan över” chiffersviter ”som klienten känner till, ordnad efter klientpreferens;
• listan över komprimeringsalgoritmer som klienten känner till, ordnad efter klientpreferens;
• några valfria tillägg.

A chiffersvit är en 16-bitars symbolisk identifierare för en uppsättning kryptografi c-algoritmer. Till exempel har TLS_RSA_WITH_AES_128_CBC_SHA krypteringssvit 0x002F och betyder ”poster använder HMAC / SHA-1 och AES-kryptering med en 128-bitars nyckel, och nyckelutbytet görs genom kryptering en slumpmässig nyckel med servern ”RSA public key”.

Servern svarar på ClientHello med en ServerHello som innehåller:

• protokollversionen som klienten och servern kommer att använda ;
• ”servern slumpmässig” (32 byte, med 28 slumpmässiga byte);
• sessions-ID för den här anslutningen;
• chiffreringssviten som kommer att användas;
• komprimeringsalgoritmen som ska användas;
• valfritt, vissa tillägg.

Hela handskakningen ser ut så här:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Detta schema har skamlöst kopierats från RFC.)

Vi ser ClientHello och ServerHello. Sedan skickar servern några andra meddelanden, som beror på krypteringssviten och några andra parametrar rs:

• Certifikat: serverns certifikat, som innehåller dess offentliga nyckel. Mer om det nedan. Det här meddelandet skickas nästan alltid, förutom om krypteringspaketet kräver en handskakning utan certifikat.
• ServerKeyExchange: några extra värden för nyckelutbytet, om vad som finns i certifikatet inte är tillräckligt. I synnerhet använder chiffersviterna ”DHE” en kortvarig Diffie-Hellman nyckelutbyte, vilket kräver det meddelandet.
• CertificateRequest: ett meddelande som begär att klienten också identifierar sig med ett eget certifikat. Det här meddelandet innehåller listan över namn på förtroendeankare (aka ”root-certifikat”) som servern kommer att använda för att validera klientcertifikatet.
• ServerHelloDone: ett markörmeddelande (med längd noll) som säger att servern är klar och klienten ska nu prata.

Klienten måste sedan svara med:

• Certifikat: klientcertifikatet, if servern begärde en. Det finns subtila variationer mellan versionerna (med SSLv3 måste klienten utelämna det här meddelandet om det inte har ett certifikat; med TLS 1.0+ måste den i samma situation skicka ett Certificate meddelande med en tom lista med certifikat).
• ClientKeyExchange: klientdelen av den faktiska nyckelutbytet (t.ex. något slumpmässigt värde krypterat med serverns RSA-nyckel).
• CertificateVerify: a digital signatur beräknad av klienten över alla tidigare handskakningsmeddelanden. Detta meddelande skickas när servern begärde ett klientcertifikat och klienten följde. Så här bevisar klienten för servern att den verkligen ”äger” den offentliga nyckeln som är kodad i certifikatet den skickade.

Sedan skickar klienten en ChangeCipherSpec meddelande, vilket inte är ett handskakningsmeddelande: det har sin egen posttyp, så det skickas i en egen post.Innehållet är rent symboliskt (en enda byte med värde 1). Det här meddelandet markerar den tidpunkt då klienten byter till nyförhandlat krypteringssvit och nycklar. De efterföljande posterna från klienten krypteras sedan.

Meddelandet Färdigt är en kryptografisk kontrollsumma som beräknas över alla tidigare handskakningsmeddelanden (från både klienten och servern). Eftersom den avges efter ChangeCipherSpec täcks den också av integritetskontrollen och krypteringen. När servern tar emot meddelandet och verifierar innehållet får det ett bevis på att det verkligen har pratat med samma klient hela tiden. Det här meddelandet skyddar handskakningen från ändringar (angriparen kan inte ändra handskakningsmeddelandena och ändå få Finished meddelandet rätt).

Servern svarar slutligen med sin egen ChangeCipherSpec och sedan Finished. Vid den tidpunkten är handskakningen klar och klienten och servern kan utbyta applikationsdata (i krypterade poster taggade som sådana).

Att komma ihåg: klienten föreslår men servern väljer . Chifferpaketet är i serverns händer. Hövliga servrar ska följa klientens preferenser (om möjligt), men de kan göra det på annat sätt och vissa gör det (t.ex. som en del av skyddet mot BEAST).

Förkortad handskakning

I hela handskakningen skickar servern ett ”session-ID” (dvs. en massa upp till 32 byte) till klienten. Senare kan klienten komma tillbaka och skicka samma session-ID som en del av hans ClientHello. Detta innebär att klienten fortfarande kommer ihåg chifferpaketet och nycklarna från föregående handskakning och vill återanvända dessa parametrar. Om servern också kommer ihåg krypteringspaketet och nycklarna kopieras det specifika session-ID: t i dess ServerHello och följer sedan förkortad handskakning :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

Den förkortade handskakningen är kortare: färre meddelanden, inget asymmetrisk kryptografivirksomhet och, viktigast av allt, minskad latens . Webbläsare och servrar gör det mycket. En typisk webbläsare öppnar en SSL-anslutning med en fullständig handskakning, gör sedan förkortade handskakningar för alla andra anslutningar till samma server: de andra anslutningarna öppnas parallellt och även efterföljande anslutningar till samma server. Typiska webbservrar stänger faktiskt anslutningar efter 15 sekunders inaktivitet, men de kommer ihåg sessioner (krypteringssviten och nycklarna) mycket längre (möjligen i timmar eller till och med dagar).

Nyckelutbyte

Det finns flera nyckelutbytesalgoritmer som SSL kan använda. Detta anges av chifferpaketet; varje nyckelutbytesalgoritm fungerar med vissa typer av servernycklar. De vanligaste nyckelutbytesalgoritmerna är:

• RSA: serverns nyckel är av typ RSA. Klienten genererar ett slumpmässigt värde (” pre-master-hemlighet ”av 48 byte, varav 46 är slumpmässiga) och krypterar den med serverns offentliga nyckel. Det finns ingen ServerKeyExchange.
• DHE_RSA: serverns nyckel är av typ RSA, men används endast för Den faktiska nyckelutbytet använder Diffie-Hellman. Servern skickar ett ServerKeyExchange -meddelande som innehåller DH-parametrarna (modul, generator) och en nygenererad DH-allmän nyckel; dessutom servern undertecknar detta meddelande. Klienten kommer att svara med ett ClientKeyExchange -meddelande som också innehåller en nyligen genererad allmän DH-nyckel. DH ger ”pre-master secret” ”.
• DHE_DSS: som DHE_RSA, men servern har en DSS-nyckel (” DSS ”är också känd som ”DSA” ). DSS är en enda signaturalgoritm.

Mindre vanliga nyckelutbytesalgoritmer inkluderar:

• DH: serverns nyckel är av typen Diffie-Hellman (vi talar om ett certifikat som innehåller en DH-nyckel). Detta brukade vara ”populärt” på ett administrativt sätt (USA: s federala regering föreskrev dess användning) när RSA-patentet fortfarande var aktivt (detta var under föregående århundrade). Trots det byråkratiska trycket distribuerades det aldrig så mycket som RSA.
• DH_anon: som DHE sviterna, men utan signaturen från servern. Detta är en certifikatfri chiffersvit. Genom konstruktion är den sårbar för Man-in-the-Middle-attacker , vilket alltså mycket sällan aktiveras alls.
• PSK: fördelad nyckel krypteringssviter. Det enda symmetriska nyckelutbytet bygger på en förutbestämd delad hemlighet.
• SRP: tillämpningen av SRP-protokoll vilket är ett Protokoll för lösenordsautentiserad nyckelutbyte . Klient och server autentiserar varandra med avseende på en delad hemlighet, vilket kan vara ett lågentropilösenord (medan PSK kräver en delad hemlighet med hög entropi). Mycket smidig. Stöds inte allmänt än.
• En kortvarig RSA-nyckel: som DHE men med ett nyligen genererat RSA-nyckelpar. Eftersom det är dyrt att generera RSA-nycklar är detta inte ett populärt alternativ och specificerades endast som en del av ”export” -krypteringssviter som överensstämde med USA: s exportregler för kryptografi före 2000 (dvs. RSA-nycklar på högst 512 bitar). Ingen gör det nuförtiden.
• Varianter av DH* algoritmer med elliptiska kurvor . Mycket moderiktigt. Bör bli vanligt i framtiden.

Certifikat och autentisering

Digitala certifikat är fartyg för asymmetriska nycklar. De är avsedda att lösa nyckeldistribution. Klienten vill nämligen använda servern ”s offentlig nyckel . Angriparen försöker få klienten att använda angriparens” offentliga nyckel. Så klienten måste ha ett sätt att se till att den använder rätt nyckel.

SSL ska använda X.509 . Detta är en standard för certifikat. Varje certifikat är undertecknat av en certifieringsmyndighet . Tanken är att klienten i sig känner till de offentliga nycklarna för en handfull CA (dessa är ”trust anchors” eller ”root certifikat”). Med dessa nycklar kan klienten verifiera signaturen som beräknas av en CA över ett certifikat som har utfärdats till servern. Denna process kan utvidgas rekursivt: en CA kan utfärda ett certifikat för en annan CA (dvs. tecken certifikatstrukturen som innehåller det andra CA-namnet och nyckeln). En kedja av certifikat som börjar med en rot-CA och slutar med serverns certifikat, med mellanliggande CA-certifikat däremellan, varvid varje certifikat är undertecknat relativt den offentliga nyckeln som är kodad i det tidigare certifikatet, kallas, fantasilöst, en certifikatkedja .

Så klienten ska göra följande:

• Skaffa en certifikatkedja som slutar med serverns certifikat. Meddelandet Certificate från servern ska innehålla exakt en sådan kedja.
• Validera kedjan, dvs. verifiera alla signaturer och namn och de olika X.509 bitarna. Klienten bör också kontrollera återkallningsstatus för alla certifikat i kedjan, vilket är komplext och tungt (webbläsare gör det nu, mer eller mindre, men det är en ny utveckling).
• Kontrollera att det avsedda servernamnet verkligen är skrivet i serverns certifikat. Eftersom klienten inte bara vill använda en validerad offentlig nyckel, den vill också använda den offentliga nyckeln på en viss server . Se RFC 2818 för information om hur detta görs i ett HTTPS-sammanhang .

Certifieringsmodellen med X.509-certifikat har ofta kritiserats, inte egentligen av tekniska skäl, utan snarare av politiskt-ekonomiska skäl. Den koncentrerar valideringsmakt i några spelares händer , som inte nödvändigtvis är välmenande eller åtminstone inte alltid behöriga . Ibland publiceras förslag på andra system (t.ex. Konvergens eller

Efter den långa presentationen av SSL i föregående svar , låt oss gå med det roliga, nämligen:

Attacker på SSL

Det har förekommit många attacker mot SSL, en del bygger på implementeringsfel, andra på sanna protokollsvagheter.

Man måste komma ihåg att medan SSL är ett av de mest attackerade protokollen (eftersom det är väldigt högt: en framgångsrik applikation för SSL ser väldigt snygg ut i abstrakt av en forskningsartikel), SSL är också ett av de mest reparerade protokollen.Det ska anses vara robust just för att alla kända sätt att angripa transportprotokoll har testats på SSL och SSL har patchats där så är lämpligt.

Version återställning

I de första dagarna av SSLv3 användes SSLv2 fortfarande i stor utsträckning och därför skickade klienter ofta SSLv2-kompatibla ClientHello meddelanden, som bara indikerade att SSLv3 stöds också; servern skulle sedan ta ledtråden och svara i SSLv3 + dialekt (se bilaga E till RFC 2246 för mer information). Eftersom SSLv2 hade svagheter var det i angriparens bästa att ordna för en klient och server, som båda känner till SSLv3, att ändå prata med varandra med hjälp av SSLv2. Detta kallas en versionbackback-attack . Konceptet sträcker sig formellt även till senare versioner.

Kludges har lagts till för att upptäcka återförsök. För back-to-SSLv2-återställningar bör en klient som känner till SSLv3 + använda en speciell stoppning för RSA-krypteringssteget (SSLv2 stöder endast RSA-baserad nyckelutbyte): i PKCS # 1 , ska de data som ska krypteras vara vadderade med ett antal slumpmässiga byte; en SSLv3-medveten klient ska sedan ställa in var och en av de sista åtta utbytesbyten till det fasta värdet 0x03. Servern kontrollerar sedan dessa byte; om de åtta 0x03 hittas, försökas troligen en återställning och servern avvisar försöket (en SSLv2-enbart klient har sannolikheten endast 255 ^-8 att använda sådana utfyllnadsbyte av ren brist på tur, så falska positiva inträffar i en försumbar takt).

För återgång till en gammal version av SSL / TLS, men inte äldre än SSLv3, tillsattes ytterligare en kludge: i pre-master-hemligheten av 48 byte som klienten krypterar med serverns RSA-nyckel, de två första byten är inte slumpmässiga, men ska motsvara den ”maximala stödda protokollversionen” som klienten skrev först i sin ClientHello -meddelande. Tyvärr har vissa klienter fått fel, och detta kludge fungerar bara med ett RSA-baserat nyckelutbyte, så skyddet mot återställning är mycket begränsat där. Lyckligtvis har SSLv3 + ett annat, mycket kraftfullare skydd mot återgångar, det vill säga att handskakningsmeddelandena hashades tillsammans när Finished meddelanden byggs. Detta pro mot återställningar om inte den ”gamla versionen” skulle vara så grundligt svag att angriparen helt kunde bryta hela krypteringen innan själva handskakningen slutade. Detta har inte hänt ännu (SSLv3 är fortfarande rimligt robust).

Svaga chiffersviter

Några av de standardkodade sviterna är medvetet svaga på något sätt. Det finns:

• vissa krypteringssviter utan kryptering alls, bara integritetskontroll, t.ex. TLS_RSA_WITH_NULL_SHA;
• vissa krypteringssviter med 40-bitars kryptering, till exempel TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (krypteringssviter avsedda att följa de strikta amerikanska exportreglerna från förra seklet – dessa regler har mestadels upphävts i slutet av Bill Clinton-eran);
• vissa krypteringssviter med 56-bitars kryptering, till exempel TLS_RSA_WITH_DES_CBC_SHA. 56-bitars DES går att bryta med befintlig teknik , men det är fortfarande lite svårt för en amatör (till och med en uttråkad student med tillgång till några hundra universitetsmaskiner ), så jag brukar kvalificera 56-bitars DES som ”medium strength”.

Detta öppnar vägen för en variant av versionbackback-attacker, där angriparen tvingar klient och server att komma överens på en svag chiffersvit, idén är att angriparen ändrar listan över chiffersviter som meddelats av klienten. Detta fungerar för angriparen om den valda chiffersviten är så svag att han kan bryta den för att beräkna en uppenbarligen korrekt Finished meddelande. Egentligen är den MAC som används i SSLv3 + (även när den är baserad på MD5) tillräckligt robust för att förhindra det. Så ingen egentlig oro här. Min åsikt är också att någon verklig svaghet här är när en klient eller en server accepterar att använda en svag chiffersvit alls.

Som standard tillåter moderna webbläsare inte användning av sådana svaga chiffersviter.

Stöld av privat nyckel

Om en SSL-anslutning använder RSA-nyckelutbyte, och en angripare behåller en kopia av posterna och sedan senare (möjligen månader efter, eventuellt genom att inspektera alla säkerhetskopior på kasserade hårddiskar eller band) får en kopia av den privata nyckeln, då kan han riva upp handskakningen och dekryptera data.

Perfect Forward Secrecy handlar om att motverka detta ”senare”. Du får det genom att använda DHE krypteringssviter. Med en DHE-chiffersvit är den faktiska privata nyckeln som kan användas för att riva upp handskakningen den kortvariga Diffie-Hellman-nyckeln, inte serverns RSA (eller DSS) privata nyckel.Eftersom det var kortvarigt fanns det bara i RAM och det skrevs aldrig till hårddisken; som sådan borde det vara mycket mer motståndskraftigt mot dold stöld.

Så lektionen är: försök som regel att använda en DHE-chiffersvit om det är möjligt. Du bör fortfarande tänka på dina säkerhetskopior och inte låta din privata nyckel läcka, men åtminstone DHE-sviterna gör sådan läckage lite mindre problem, speciellt om det händer efter slutet av nyckeltiden (dvs. motsvarande certifikat är inget längre giltig).

Certifikat woes

Hela certifikatverksamheten är en öm plats i SSL.

Tekniskt sett är SSL ganska oberoende av X.509. Certifikatkedjorna byts ut som ogenomskinliga blobs. Vid något tillfälle måste klienten använda serverns offentliga nyckel, men klienten är fri att ”känna” den nyckeln på vilket sätt som helst. I vissa specifika scenarier där SSL kan användas, känner klienten redan servern ”s offentliga nyckel (hårdkodad i koden) och ignorerar bara certifikatet som skickas av servern. I det vanliga fallet med HTTPS gör klienten dock validering av serverns certifikatkedja som beskrivs i X.509 ( läs det på bekostnad av din sanity; du har blivit varnad).

Detta ger ett antal attackvektorer, till exempel:

• Validering innebär att verifiera att certifikaten är fortfarande giltiga vid det aktuella datumet. Hur vet klientmaskinen det aktuella datumet? Med sin interna klocka och eventuellt genom att prata med NTP-servrar (i ett ganska oskyddat sätt!). Klienten kan vara av med flera minuter, timmar, dagar, till och med år (jag har sett det), och till viss del kan en kraftfull angripare tvinga det genom att fitta med NTP-meddelanden. Detta skulle möjliggöra angriparen att använda föråldrade certifikat som har återkallats för flera år sedan. Observera ett roligt faktum: SSL ”klient slumpmässigt” och ”server slumpmässigt” bör innehålla 28 slumpmässiga byte och lokalt datum och tid (över 4 Denna byte Tiden var tänkt att vara en del av en lösning mot tidsbaserade attacker. Jag är inte medveten om någon implementering som verkligen kontrollerar den.

• Fram till cirka 2003 bearbetade inte implementeringen av certifikatvalidering i Internet Explorer / Windows tillägget ”Basic Constraints” ordentligt. Nettoeffekten var att någon med ett 100 € -certifikat kunde fungera som CA och utfärda ”certifikat” med godtyckligt valt namn och nycklar.

• X .509 innehåller en funktion för skador som kallas återkallande : det handlar om att publicera en lista över förvisade certifikat, som ser bra ut, kryptografiskt sett, men inte bör lita på (t.ex. att deras privata nyckel stulits eller de innehåller ett felaktigt namn). Återkallande fungerar bara så långt som de berörda parterna (dvs. webbläsare) accepterar att ladda ner mammutåterkallningslistor (som kan vara flera megabyte långa!) Eller att kontakta OCSP-servrar . Moderna webbläsare gör det nu, men lite motvilligt, och många kommer att acceptera att ansluta ändå om de inte kunde få återkallningsstatusinformation i rätt tid (eftersom den mänskliga användaren inte är tålmodig). Den övergripande situationen förbättras med åren, men ganska långsamt.

• Vissa rot-CA begick några misstag tidigare (t.ex. Comodo och DigiNotar). Detta resulterade i utfärdandet av falska certifikat (namnet är www.microsoft.com men den privata nyckeln är inte i Microsofts hand alls …). Dessa misstag upptäcktes och certifikaten återkallades, men det väcker fortfarande några obekväma frågor (t.ex. finns det andra CA som hade sådana problem men inte avslöjade dem, eller, ännu värre, aldrig märkt dem?).

X.509 är en mycket komplex sammansättning av algoritmer, tekniker, specifikationer och kommittéer, och det är väldigt svårt att få rätt. Att försöka avkoda X.509-certifikat ”för hand” på ett oskyddat programmeringsspråk som C är ett enkelt sätt att få buffertöverflöden.

Bleichenbacher Attacks

Daniel Bleichenbacher hittade 1998 en trevlig attack mot RSA. När du krypterar en datadel med RSA (som förekommer för ClientKeyExchange -meddelandet i SSL) måste de data som ska krypteras vadderas för att för att skapa en bytesekvens av samma längd som RSA-modulen. Utfyllningen består mestadels av slumpmässiga byte, men det finns lite struktur (särskilt de två första byten efter utfyllnad måste vara 0x00 0x02).

Vid dekryptering (på servern, då) måste stoppningen hittas och tas bort. Det händer så att vid den tiden, när servern dekrypterades men fick en ogiltig stoppning (0x00 0x02 byte inte fanns), rapporterade den det med ett varningsmeddelande (enligt SSL-specifikationen), medan en giltig stoppning resulterade i servern använder det till synes dekrypterade värdet och fortsätter med handskakningen.

Den här typen av saker kallas ett stoppningsorakel . Det tillåter en angripare att skicka en godtycklig bytesekvens som om det var en krypterad pre-masterhemlighet, och veta om dekrypteringen av den sekvensen skulle ge en giltig stoppning eller inte. Det ”är bara 1-bitars information, men det räcker att återställa den privata nyckeln med några miljoner förfrågningar (med listigt utformade” krypterade ”strängar).

Lösning: när dekrypteringen resulterar i en ogiltig padding, servern fortsätter att använda en slumpmässig pre-master-hemlighet. Handskakningen misslyckas senare med meddelandena Finished. Alla nuvarande implementeringar av SSL gör det.

Padding Oracle slår tillbaka

Ett annat område där ett stoppningsorakel hittades finns i registrerar sig själva. Tänk på CBC-kryptering och HMAC. Data som ska krypteras först MACed, sedan krypteras resultatet. Med CBC-kryptering måste data som ska krypteras ha en längd som är en multipel av blockstorleken (8 byte för 3DES, 16 byte för AES). Så lite stoppning tillämpas, med viss struktur.

Vid den tiden (attacken upptäcktes av Vaudenay 2002), när en SSL-implementering behandlade en mottagning d-posten returnerade den distinkta varningsmeddelanden för dessa två villkor:

• Vid dekryptering hittades ingen giltig stoppningsstruktur.
• Vid dekryptering, en giltig utfyllnad hittades, men sedan verifierades MAC och det matchade inte.

Detta är ett utfyllnadsorakel, och det kan användas för att återställa vissa krypterade data. Det kräver en aktiv angripare, men det är inte så svårt. Vaudenay implementerade det, och det utvidgades till fallet där en modifierad SSL-implementering returnerade samma varningsmeddelande i båda fallen, men det tog längre tid att återvända i det andra fallet, på grund av det tar tid att beräkna MAC (en trevlig demonstration av a timing attack ).

Eftersom människor aldrig lär sig var Microsoft-implementeringen av SSL som användes i ASP.NET fortfarande inte uppdaterade från och med 2010 (åtta år senare!) när Rizzo och Duong återimplementerade Vaudenay-attacken och byggde en demonstration som återhämtade HTTP-kakor.

Se den här sidan för några pekare. Man måste notera att om SSL hade använt kryptera-då-MAC , skulle sådana problem ha undvikits (felaktiga poster skulle ha avvisats på MAC-nivå, innan även överväger dekryptering).

BEAST

BEAST-attacken är igen från Duong och Rizzo, och återigen, det är en remake av en äldre attack (från Philip Rogaway 2002). För att få idén, överväg CBC . I detta driftsätt XORedas varje datablock först med resultatet av krypteringen av det föregående blocket; och att ”är resultatet för XOR som är krypterad. Detta görs för att” randomisera ”blocken och för att undvika läckor som finns med ECB-läge. Eftersom det första blocket inte har ett ”föregående” block, det måste finnas en Initialiseringsvektor (IV), som spelar rollen som föregående block för det första blocket.

Det visar sig att om en angripare kan kontrollera en del av de data som ska krypteras, och också kan förutsäga IV som kommer att användas, så kan han förvandla krypteringsmaskinen till ännu en dekryptering oracle och använd den för att återställa vissa andra krypterade data (som angriparen inte väljer). Men i SSLv3 och TLS 1.0 kan angriparen förutsäga IV för en post: det är det sista blocket av den tidigare posten! Så angriparen måste kunna skicka lite data i strömmen för att ”pressa” måldata, vid en punkt där implementeringen byggde och skickade den tidigare posten (vanligtvis när 16 kB värt data har ackumulerats), men började inte bygga nästa.

TLS 1.1+ är skyddad mot det eftersom i TLS 1.1 (och efterföljande versioner) används en slumpmässig IV per post. För SSLv3 och TLS 1.0 är en lösning att skicka nollängdsposter: det vill säga poster med en nyttolast på längden noll – men med en MAC och padding och kryptering, och MAC beräknas från en hemlig nyckel och över sekvensen så detta spelar rollen som en slumptalsgenerator. Tyvärr kväver IE 6.0 på nollängdslistor. Andra strategier involverar en 1 / n-1-delning (en n bytespost skickas som två poster, en med en enda nyttolastbyte, den andra med återstående n-1 ).

En annan lösning är att tvinga användningen av en icke-CBC-chiffersvit när det är möjligt – servern väljer en RC4-baserad chiffersvit om det finns en i listan över chiffersviter som skickas av även om klienten skulle ha föredragit en CBC-baserad chiffersvit. Detta verktyg kan berätta om en viss server tydligen fungerar så.(Obs: BEAST är en attack mot klienten men genom att välja en RC4-chiffersvit kan servern skydda en slarvig klient.)

Se den här sidan för några pekare. Medan TLS 1.1 är från 2006 kan BEAST-attacken tvinga webbläsarleverantörerna att slutligen uppgradera.

CRIME

Som för alla Hollywood-franchise publicerade Duong och Rizzo 2012 uppföljaren av uppföljaren. CRIME utnyttjar ett läckage som teoretiserades för många år sedan men som bara visades tydligt i demonstrationen de nyligen publicerade. CRIME utnyttjar komprimering i samma inställning som BEAST-attacken (angriparen kan skicka en del data i en SSL-anslutning, där intressanta måldata som en cookie också skickas). Grovt sett sätter angriparen in sina data ett potentiellt värde för målsträngen, och om den matchar, komprimering gör de resulterande posterna kortare. Se den här frågan för en (prekognitiv) analys.

CRIME undviks genom att inte använda TLS-nivåkomprimering alls, vilket är vad webbläsare nu gör. Internet Explorer och IIS implementerade aldrig TLS-nivåkomprimering i första hand (för en gångs skull räddade dagen); Firefox och Chrome implementerade det och inaktiverade i sommar (de varnades av Duong och Rizzo, som är ganska ansvariga i sin aktivitet).

CRIME visar varför jag skrev, nära början av min SSL-förklaringar :

SSL uppfyller dessa mål i stor utsträckning (men inte absolut).

Kryptering läcker faktiskt längden på den krypterade data. Det finns ingen känd bra lösning mot det. Och längden ensam kan avslöja många saker. När vi till exempel observerar en SSL-anslutning med en nätverksövervakare kan vi upptäcka ”extra handskakningar” i strömmen (eftersom den första byten i varje post identifierar typen av data i posten och den inte är krypterad); med posternas längder är det ganska lätt att se om klienten tillhandahöll ett certifikat eller inte.

Pudel

( redigera: detta avsnitt har lagts till den 2014-10-15)

”Pudel” -attacken utnyttjar ett fel som är specifikt för SSL 3.0 med CBC-baserade krypteringssviter. Det är beroende av en ofta förbises funktion i SSL 3.0: de flesta utfyllnadsbyte ignoreras. I TLS 1.0 är vadderingen (byte adderade i en post för att göra längden kompatibel med CBC-kryptering, som endast bearbetar hela block) helt specificerad; alla byte måste ha ett specifikt värde och mottagaren kontrollerar det. I SSL 3.0 ignoreras vadderingsbyteinnehåll, vilket gör det möjligt för en angripare att utföra ändringar som oftast går obemärkt förbi. Ändringen påverkar endast data som inte är applikativa men kan användas som ett dekrypteringsorakel på ett sätt som vagt liknar BEAST.

Mer information kan läsas i detta svara .

Framtiden

Människor lär sig aldrig. Det finns mycket tryck att lägga till snygga tillägg till SSL av många anledningar som alltid ser bra ut i början, men som kan orsaka extra problem.

Tänk till exempel på SSL FalseStart . Det handlar främst om att klienten skickar sin applikationsinformation direkt efter att ha skickat sitt Finished meddelande (i ett fullständigt handskakning), utan att vänta på Finished meddelande från servern. Detta minskar latens, vilket är bra och välmenande. Det ändrar dock säkerhetssituationen: innan den mottagit Finished meddelandet från servern, är den senare bara implicit autentiserad (klienten har ännu inga bevis för att den avsedda servern verkligen var inblandad i allt; det vet bara att vad det än skickar kommer bara att läsas av den avsedda servern). Detta kan ha effekter; till exempel kan en angripare emulera servern upp till den punkten och tvinga t.ex. klienten att använda en CBC-baserad krypteringssvit eller TLS-komprimering. Därför, om en klient implementerar FalseStart, minskar det effektiviteten i skyddsåtgärder mot BEAST och CRIME, vilket annars skulle kunna genomföras av servern.

(Google inaktiverade FalseStart i våras, uppenbarligen på grund av kompatibilitetsproblem med vissa servrar. Hur som helst såg ”30% latensminskning” konstigt ut, eftersom FalseStart bara skulle ha inflytande på fulla handskakningar, inte förkortade handskakningar, så jag gör det inte t tror på dessa påstådda fördelar, åtminstone inte i den omfattningen.)

Kommentarer

• Mängden ansträngning du lägger på att tillhandahålla god information genom den här webbplatsen är verkligen galen och extremt beundransvärd. Mycket uppskattad.
• Se även tools.ietf.org / html / rfc7457