Generelt

SSL (og dens efterfølger, TLS ) er en protokol, der fungerer direkte oven på TCP (selvom der også er implementeringer for datagrambaserede protokoller som UDP). På denne måde kan protokoller på højere lag (såsom HTTP) være uændrede, mens s indtil det giver en sikker forbindelse. Under SSL-laget er HTTP identisk med HTTPS.

Når du bruger SSL / TLS korrekt, kan alt, hvad en hacker kan se på kablet, hvilken IP og port du er tilsluttet, omtrent hvor meget data du sender , og hvilken kryptering og komprimering der bruges. Han kan også afslutte forbindelsen, men begge sider ved, at forbindelsen er afbrudt af en tredjepart.

I typisk brug vil angriberen også være i stand til at finde ud af, hvilket værtsnavn du opretter forbindelse til (men ikke resten af URLen): selvom HTTPS i sig selv ikke udsætter værtsnavnet, skal din browser normalt først foretage en DNS-anmodning for at finde ud af, hvilken IP-adresse du vil sende anmodningen til.

Høj -niveaubeskrivelse af protokollen

Efter opbygning af en TCP-forbindelse startes SSL-håndtrykket af klienten. Klienten (som kan være en browser såvel som ethvert andet program såsom Windows Update eller PuTTY) sender et antal specifikationer:

• hvilken version af SSL / TLS den kører,
• hvad ciphersuites det vil bruge, og
• hvad komprimeringsmetoder den vil bruge.

Serveren identificerer den højeste SSL / TLS-version, der understøttes af både den og klienten, vælger en cifhersuite fra en af klientens muligheder (hvis den understøtter en) og vælger eventuelt en komprimeringsmetode.

Herefter sender den grundlæggende opsætning sit certifikat. Dette certifikat skal have tillid til enten klienten selv eller en part, som klienten stoler på. For eksempel, hvis klienten stoler på GeoTrust, kan klienten stole på certifikatet fra Google.com, fordi GeoTrust kryptografisk underskrevet Googles certifikat.

Efter at have bekræftet certifikatet og er sikker på, at denne server virkelig er den, han hævder at være (og ikke en mand i midten), udveksles en nøgle. Dette kan være en offentlig nøgle, en ” PreMasterSecret ” eller simpelthen ingenting, afhængigt af den valgte cifhersuite. Både serveren og klienten kan nu beregne nøglen til symmetrisk kryptering ^{whynot PKE?} . Klienten fortæller serveren, at al kommunikation fra nu af bliver krypteret, og sender en krypteret og godkendt meddelelse til serveren.

Serveren verificerer, at MAC (bruges til godkendelse) er korrekt, og at meddelelsen kan dekrypteres korrekt. Den returnerer derefter en meddelelse, som klienten verificerer som godt.

Håndtrykket er nu færdigt, og de to værter kan kommunikere sikkert. For mere information, se technet.microsoft.com/en-us/library/cc785811 og da.wikipedia .org / wiki / Secure_Sockets_Layer .

For at lukke forbindelsen bruges en close_notify “alarm”. Hvis en angriber forsøger at afslutte forbindelsen ved at afslutte TCP-forbindelsen (injicere en FIN-pakke), ved begge sider, at forbindelsen blev forkert afbrudt. Forbindelsen kan dog ikke kompromitteres af dette, men kun afbrudt.

Nogle flere detaljer

Hvorfor kan du stole på Google.com ved at stole på GeoTrust?

Et websted ønsker at kommunikere sikkert med dig. For at bevise sin identitet og sikre, at den ikke er en angriber, skal du have serveren “s offentlig nøgle . Du kan dog næppe gemme alle nøgler fra alle hjemmesider på jorden ville databasen være enorm, og opdateringer skulle køre hver time!

Løsningen på dette er Certificate Authorities, eller kort sagt CA.Når du installerede dit operativsystem eller din browser, fulgte sandsynligvis en liste med tillid til CAer. Denne liste kan ændres efter ønske; du kan fjerne hvem du ikke stoler på, tilføje andre eller endda oprette din egen CA (selvom du vil være den eneste, der stoler på denne CA, så det er ikke meget brug for det offentlige websted). På denne CA-liste er CAs offentlige nøgle også gemt.

Når Googles server sender dig sit certifikat, nævner den også, at den er underskrevet af GeoTrust. Hvis du stoler på GeoTrust, kan du bekræfte (ved hjælp af GeoTrusts offentlige nøgle), at GeoTrust virkelig underskrev serverens certifikat. For selv at underskrive et certifikat skal du bruge den private nøgle, som kun er kendt af GeoTrust. På denne måde kan en hacker ikke underskrive et certifikat selv og fejlagtigt hævde at være Google.com. Når certifikatet er blevet ændret med en enkelt bit, vil tegnet være forkert, og klienten vil afvise det.

Så hvis jeg kender den offentlige nøgle, kan serveren bevise sin identitet?

Ja. Typisk krypteres den offentlige nøgle og den private nøgle. Krypter en besked med serverens offentlige nøgle, send den, og hvis serveren kan gentage den oprindelige besked, viste det sig bare, at den fik den private nøgle uden at afsløre nøglen.

Dette er grunden til, at den er så vigtigt at være i stand til at stole på den offentlige nøgle: enhver kan generere et privat / offentligt nøglepar, også en angriber. Du vil ikke ende med at bruge den offentlige nøgle til en angriber!

Hvis en af de CAer, som du stoler på, er kompromitteret, kan en angriber bruge den stjålne private nøgle til at underskrive et certifikat for ethvert websted, de kan lide. Når angriberen kan sende et forfalsket certifikat til din klient, underskrevet af sig selv med den private nøgle fra en CA, som du har tillid til, ved din klient ikke, at den offentlige nøgle er en forfalsket, underskrevet med en stjålet privat nøgle.

Men en CA kan få mig til at stole på enhver server, de vil have!

Ja, og det er her tilliden kommer i. Du skal stole på, at CA ikke laver certifikater, som de vil. Når organisationer som Microsoft, Apple og Mozilla har tillid til en CA, skal CA dog have revisioner; en anden organisation kontrollerer dem med jævne mellemrum for at sikre, at alt stadig kører i henhold til til reglerne.

Udstedelse af et certifikat sker, hvis og kun hvis, registranten kan bevise, at de ejer det domæne, som certifikatet er udstedt til.

Hvad er denne MAC til meddelelsesgodkendelse?

Hver meddelelse er underskrevet med en såkaldt Beskedgodkendelseskode eller MAC for kort. Hvis vi er enige om en nøgle og hashing-chiffer, kan du kontrollere, at min besked kommer fra mig, og jeg kan kontrollere, at din besked kommer fra dig.

For eksempel med nøglen ” korrekt hæfteklammer til hestebatteri ” og meddelelsen ” eksempel “, Jeg kan beregne MAC ” 58393 “. Når jeg sender denne besked med MAC til dig (du kender allerede nøglen), kan du udføre den samme beregning og matche den beregnede MAC med den MAC, som jeg sendte.

En angriber kan ændre meddelelsen men kender ikke nøglen. Han kan ikke beregne den korrekte MAC, og du ved, at beskeden ikke er autentisk.

Ved at inkludere et sekvensnummer, når du beregner MAC, kan du fjerne replay angreb . SSL gør dette.

Du sagde, at klienten sender en nøgle, som derefter bruges til opsætning symmetrisk kryptering. Hvad forhindrer en angriber i at bruge den?

Serverens offentlige nøgle gør. Da vi har bekræftet, at den offentlige nøgle virkelig tilhører serveren og ingen andre, kan kryptere nøglen ved hjælp af den offentlige nøgle. Når serveren modtager denne, kan han dekryptere den med den private nøgle. Når nogen anden modtager den, kan de ikke dekryptere den.

Dette er også grunden til, at nøglestørrelse betyder noget: Jo større den offentlige og private nøgle er, desto sværere er det at knække den nøgle, som klienten sender til serveren.

Sådan knækker du SSL

Sammenfattende :

• Prøv, hvis brugeren ignorerer certifikatadvarsler;
• Applikationen kan indlæse data fra en ukrypteret kanal (f.eks. HTTP), som kan manipuleres med;
• En ubeskyttet login-side, der indsendes til HTTPS, kan ændres, så den indsendes til HTTP;
• Ikke-udpakkede applikationer kan være sårbar over for bedrifter som BEAST og CRIME;
• Brug af andre metoder suc h som et fysisk angreb;
• Udnyt sidekanaler som meddelelseslængde og tid taget for at danne meddelelsen;
• Vent på kvanteangreb .

Se også: Et skema med mange angrebsvektorer mod SSL af Ivan Ristic ^(png)

I detaljer:

Der er ingen enkel og ligetil vej; SSL er sikkert, når det gøres korrekt. En angriber kan prøve, hvis brugeren ignorerer certifikatadvarsler , hvilket vil bryde sikkerheden med det samme. Når en bruger gør dette, behøver angriberen ikke en privat nøgle fra en CA for at smede et certifikat, han skal blot sende et eget certifikat.

En anden måde ville være ved en fejl i applikation (server- eller klientside). Et let eksempel er på websteder: Hvis en af de ressourcer, der bruges af hjemmesiden (f.eks. et billede eller et script) er indlæst via HTTP, kan fortroligheden ikke garanteres længere. Selvom browsere send ikke HTTP Referer-overskriften, når du anmoder om ikke-sikre ressourcer fra en sikker side ( kilde ), det er stadig muligt for nogen, der aflytter trafik til at gætte, hvor du “besøger fra; for eksempel, hvis de ved, at billeder X, Y og Z bruges på en side, kan de gætte på, at du besøger den side, når de ser din browser bede om disse tre billeder på én gang. Derudover kan hele siden blive kompromitteret ved indlæsning af Javascript. En hacker kan udføre ethvert script på siden og ændre for eksempel til hvem banktransaktionen vil gå.

Når dette sker (en ressource indlæses via HTTP), giver browseren en advarsel om blandet indhold: Chrome , Firefox , Internet Explorer 9

Et andet trick for HTTP er, når login-siden ikke er sikret, og den sender til en https-side. ” Fantastisk, ” udvikleren sandsynligvis troede, ” nu gemmer jeg serverbelastning og adgangskoden sendes stadig krypteret! ” Problemet er sslstrip , et værktøj, der ændrer den usikre login-side, så den sender et eller andet sted, så angriberen kan læse det.

Der har også været forskellige angreb i de sidste par år, såsom TLS-genforhandlingssårbarhed , sslsniff , BEAST , og for nylig KRIMINALITET . Alle almindelige browsere er dog beskyttet mod alle disse angreb, så disse sårbarheder er ikke nogen risiko, hvis du kører en opdateret browser.

Sidst men ikke mindst kan du ty til andre metoder for at få den information, som SSL nægter at få. Hvis du allerede kan se og manipulere med brugerens forbindelse, er det måske ikke så svært at erstatte en af hans / hendes .exe-downloads med en keylogger eller bare at fysisk angribe den pågældende person. Kryptografi kan være ret sikker, men mennesker og menneskelige fejl er stadig en svag faktor. Ifølge dette papir af Verizon , involverede 10% af databrudene fysiske angreb (se side 3), så det ” s bestemt noget at huske på.

Kommentarer

• Jeg ville være interesseret i lidt mere forklaring på ” en nøgle udveksles ” til den symmetriske nøgle. Hvordan sker dette, at nogen med en pakkesniffer ikke kan få adgang.
• @Yehosef Godt spørgsmål! Jeg glemte at forklare det i mit svar. Når man ser sig rundt, viser det sig, at der faktisk er et spørgsmål dedikeret til dette: security.stackexchange.com/q/6290/10863
• @ Iwazaru Alle CAer gør dette siden første dag. Pointen med et certifikat er at give den offentlige nøgle til et givet domæne, og pointen med at underskrive det for at bevise, at det virkelig er den rigtige nøgle til domænet. Lad ‘ s Encrypt gør nøjagtigt, hvad det skal gøre: Bekræft, at du ejer domænet, og underskriv dit certifikat (med din nøgle), hvis du kan bevise det. Nu vil alle, der stoler på, at ‘ s Encrypt, som praktisk talt er enhver browser, stoler på dette certifikat.
• Er, nr. TLS er faktisk lige implementeret oven på TCP.
• Fundet denne grafisk SSL-håndtryksproces , meget klar.

Da det generelle koncept med SSL allerede er dækket af nogle andre spørgsmål (f.eks. denne og den ene ), denne gang vil jeg gå efter detaljer. Detaljer er vigtige. Dette svar vil være noget detaljeret.

Historie

SSL er en protokol med en lang historie og flere versioner.De første prototyper kom fra Netscape, da de udviklede de første versioner af deres flagskibsbrowser, Netscape Navigator (denne browser dræbte Mosaic i de tidlige tider af Browser Wars, som stadig raser, omend med nye konkurrenter). Version 1 er aldrig blevet offentliggjort, så vi ved ikke, hvordan det så ud. SSL-version 2 er beskrevet i et kladde, der kan læses der ; det har en række svagheder, nogle af dem ret alvorlige, så det er udfaset, og nyere SSL / TLS-implementeringer understøtter det ikke (mens ældre deaktiveres som standard). Jeg vil ikke tale om SSL version 2 længere, undtagen som en lejlighedsvis reference.

SSL version 3 (som jeg vil kalde “SSLv3”) var en forbedret protokol, der stadig fungerer i dag og understøttes bredt. Selvom det stadig er en ejendom tilhørende Netscape Communications (eller den, der ejer det i dag), er protokollen blevet offentliggjort som en “historisk RFC” ( RFC 6101 ). I mellemtiden er protokollen standardiseret med et nyt navn for at undgå juridiske problemer; det nye navn er TLS .

Tre versioner af TLS er hidtil produceret, hver med sin dedikeret RFC: TLS 1.0 , TLS 1.1 og TLS 1.2 . De er internt meget ens med hinanden og med SSLv3, til det punkt, at en implementering let kan understøtte SSLv3 og alle tre TLS-versioner, hvor mindst 95% af koden er almindelig. Internt er alle versioner stadig udpeget med et versionsnummer med formatet major.minor ; SSLv3 er derefter 3.0, mens TLS-versionerne er henholdsvis 3.1, 3.2 og 3.3. Således er det ikke underligt, at TLS 1.0 undertiden kaldes SSL 3.1 (og det er heller ikke forkert). SSL 3.0 og TLS 1.0 adskiller sig kun med nogle få minutdetaljer. TLS 1.1 og 1.2 understøttes endnu ikke bredt, skønt der er en drivkraft for det på grund af mulige svagheder (se nedenfor for “BEAST-angrebet”). SSLv3 og TLS 1.0 understøttes “overalt” (selv IE 6.0 kender dem).

Kontekst

SSL sigter mod at give en sikker tovejstunnel til vilkårlige data. Overvej TCP , den velkendte protokol til afsendelse af data over internettet. TCP fungerer over IP “pakker” og tilvejebringer en tovejs tunnel til bytes; det fungerer for hver byteværdi og sender dem i to strømme, som kan fungere samtidigt. TCP håndterer det hårde arbejde med at opdele dataene i pakker, anerkende dem, samle dem tilbage i deres rigtige rækkefølge, mens de fjerner dubletter og genudsender mistede pakker. Fra applikationens synspunkt, der bruger TCP, er der kun to streams, og pakkerne er usynlige; især streams er ikke opdelt i “meddelelser” (det er op til applikationen at tage sine egne kodningsregler, hvis det ønsker at have beskeder, og det er præcis, hvad HTTP gør).

TCP er pålidelig i nærvær af “ulykker”, dvs. transmissionsfejl på grund af flakket hardware, netværksbelastning, mennesker med smartphones, der går ud for en given basestations rækkevidde. , og andre ikke-ondsindede begivenheder. Imidlertid kunne en ubevidst person (“angriberen”) med en vis adgang til transportmediet læse alle de transmitterede data og / eller ændre det med vilje, og TCP beskytter ikke mod det. SSL.

SSL antager at det fungerer via en TCP-lignende protokol, som giver en pålidelig stream; SSL implementerer ikke genudsendelse af mistede pakker og lignende. Angriberen er formodes at have magten til at afbryde kommunikationen fuldstændigt på en uundgåelig måde (for eksempel kan han klippe kablerne), så SSLs job er at:

• opdage ændringer (angriberen må ikke være i stand til at ændre data stille );
• sikre data fortrolighed ( angriberen må ikke få kendskab til de udvekslede data).

SSL opfylder disse mål i stort (men ikke absolut) omfang.

Registrerer

SSL er lagdelt og bundlaget er protokollen . Uanset hvilke data der sendes i en SSL-tunnel, er den opdelt i poster . Over ledningen (det underliggende TCP-stik eller TCP-lignende medium) ser en post sådan ud:

HH V1:V2 L1:L2 data

hvor:

• HH er en enkelt byte, der angiver typen af data i posten.Fire typer er defineret: change_cipher_spec (20), alert (21), handshake (22) og application_data ( 23).
• V1: V2 er protokolversionen over to byte. For alle versioner, der aktuelt er defineret, har V1 værdi 0x03, mens V2 har værdi 0x00 for SSLv3, 0x01 for TLS 1.0, 0x02 for TLS 1.1 og 0x03 for TLS 1.2.
• L1: L2 er længden af data i byte (big-endian-konvention er brugt: længden er 256 * L1 + L2). Den samlede længde på data må ikke overstige 18432 bytes, men i praksis kan den ikke engang nå den værdi.

Så en post har en fem- byteoverskrift, efterfulgt af højst 18 kB data. data er, hvor symmetrisk kryptering og integritetskontrol anvendes. Når en post udsendes, skal både afsender og modtager være enige om, hvilke kryptografiske algoritmer, der aktuelt anvendes, og med hvilke nøgler; denne aftale opnås gennem håndtrykprotokollen, beskrevet i det næste afsnit. Kompression, hvis nogen, anvendes også på det tidspunkt.

I alle detaljer fungerer opbygningen af en post som denne:

• Oprindeligt er der nogle byte, der skal overføres ; disse er applikationsdata eller en anden slags bytes. Denne nyttelast består højst af 16384 bytes, men muligvis mindre (en nyttelast med længde 0 er lovlig, men det viser sig, at Internet Explorer 6.0 ikke kan lide det overhovedet ) .
• Nyttelasten komprimeres derefter med den kompressionsalgoritme, der i øjeblikket er aftalt. Komprimering er stateful og kan derfor afhænge af indholdet af tidligere poster. I praksis er kompression enten “null” (slet ingen komprimering) eller “Deflate” ( RFC 3749 ), idet sidstnævnte i øjeblikket er høfligt, men bestemt vist udgangen dør i websammenhæng på grund af det nylige CRIME-angreb . Kompression sigter mod at forkorte data, men den skal nødvendigvis udvide dem lidt i nogle ugunstige situationer (på grund af pigeonhole-princippet ). SSL giver mulighed for en udvidelse på højst 1024 byte. Selvfølgelig udvides nul komprimering aldrig (men forkorter heller ikke); Deflater udvides med højst 10 byte, hvis implementeringen er god.
• Den komprimerede nyttelast beskyttes derefter mod ændringer og krypteres. Hvis de nuværende krypterings- og integritetsalgoritmer er “null”, er dette trin ikke-operation. Ellers tilføjes en MAC , derefter polstring (afhængigt af krypteringsalgoritmen), og resultatet krypteres. Disse trin fremkalder igen en vis udvidelse, som SSL-standarden begrænser til 1024 ekstra byte (kombineret med den maksimale udvidelse fra kompressionstrinet, dette bringer os til 18432 bytes, hvortil vi skal tilføje 5-byte-overskriften).

MAC er normalt HMAC med en af de sædvanlige hashfunktioner (for det meste MD5, SHA-1 eller SHA-256) (med SSLv3 er dette ikke den “sande” HMAC, men noget meget ens, og efter vores bedste viden så sikker som HMAC). Kryptering bruger enten en blokciffer i CBC-tilstand eller RC4 stream-chiffer. Bemærk, at der i teorien kunne anvendes andre former for tilstande eller algoritmer, f.eks. En af disse smarte tilstande, der kombinerer kryptering og integritetskontrol; der er endda nogle RFC til det . I praksis kender dog implementerede implementeringer ikke disse endnu, så de gør HMAC og CBC. Afgørende er, at MAC først beregnes og føjes til dataene, og resultatet krypteres. Dette er MAC-derefter-krypteret, og det er faktisk ikke en særlig god idé . MAC beregnes over sammenkædningen af (komprimeret) nyttelast og et sekvensnummer, så en flittig angriber muligvis ikke bytter poster.

Håndtryk

håndtrykket er en protokol, der afspilles inden for protokollen. Dets mål er at etablere de algoritmer og nøgler, der skal bruges til posterne. Den består af beskeder . Hver håndtryksmeddelelse begynder med en fire-byte-overskrift, en byte, der beskriver meddelelsestypen, derefter tre byte for meddelelsens længde (big-endian-konvention). De på hinanden følgende håndtryksmeddelelser sendes derefter med poster, der er tagget med typen “håndtryk” (den første byte i overskriften på hver post har værdi 22).

Bemærk lagene: håndtryksmeddelelserne, komplet med fire- byte header, sendes derefter som poster, og hver post også har sin egen header. Derudover kan flere håndtryksmeddelelser sendes inden for den samme post, og en given håndtryksmeddelelse kan opdeles over flere poster.Fra det modul, der bygger håndtryksmeddelelserne, er “optegnelserne” bare en strøm, hvorpå bytes kan sendes; det er ikke opmærksom på den faktiske opdeling af denne strøm i poster.

Fuldt håndtryk

Oprindeligt er klient og server “enige om” nulkryptering uden MAC- og nullkomprimering. Dette betyder, at den post, de først sender, sendes som klar tekst og ubeskyttet.

Den første meddelelse om et håndtryk er en ClientHello. Det er den meddelelse, hvormed klienten siger, at den har til hensigt at lave noget SSL. Bemærk, at “klient” er en symbolsk rolle; det betyder “det parti, der taler først”. Det sker således, at alle tre lag i HTTPS-sammenhæng, som er HTTP-inden-SSL-inden for TCP, har en forestilling om “klient” og “server”, og de er alle enige (TCP-klienten er også SSL-klienten og HTTP-klienten), men det er en slags tilfældighed.

Meddelelsen ClientHello indeholder:

• den maksimale protokol version, som klienten ønsker at understøtte;
• “klienten tilfældig” (32 byte, hvoraf 28 formodes at blive genereret med en kryptografisk stærk talgenerator);
• ” session ID “(hvis klienten ønsker at genoptage en session i et forkortet håndtryk, se nedenfor);
• listen over” chifferpakker “, som klienten kender til, ordnet efter klientpræference;
• listen over komprimeringsalgoritmer, som klienten kender til, ordnet efter klientindstilling;
• nogle valgfrie udvidelser.

A cipher suite er en 16-bit symbolsk identifikator for et sæt kryptografi c algoritmer. For eksempel har TLS_RSA_WITH_AES_128_CBC_SHA -krypteringssættet værdi 0x002F og betyder “poster bruger HMAC / SHA-1 og AES-kryptering med en 128-bit nøgle, og nøgleudvekslingen sker ved kryptering en tilfældig nøgle med serverens “RSA offentlige nøgle”.

Serveren reagerer på ClientHello med en ServerHello som indeholder:

• den protokolversion, som klienten og serveren vil bruge;
• “serveren tilfældig” (32 bytes med 28 tilfældige byte);
• session-idet for denne forbindelse;
• den chiffreringssuite, der skal bruges;
• den komprimeringsalgoritme, der skal bruges; li>
• valgfrit, nogle udvidelser.

Det fulde håndtryk ser sådan ud:

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

(Dette skema er skamløst kopieret fra RFC.)

Vi ser ClientHello og ServerHello. Derefter sender serveren et par andre beskeder, der afhænger af chifferpakken og nogle andre parametre rs:

• Certifikat: serverens certifikat, som indeholder dens offentlige nøgle. Mere om det nedenfor. Denne meddelelse sendes næsten altid, undtagen hvis krypteringssuiten kræver et håndtryk uden et certifikat.
• ServerKeyExchange: nogle ekstra værdier til nøgleudvekslingen, hvis det, der er i certifikatet, ikke er tilstrækkeligt. Især bruger “DHE” -kodningssuiterne en kortvarig Diffie-Hellman nøgleudveksling, som kræver denne besked.
• CertificateRequest: en besked, der anmoder om, at klienten også identificerer sig med et eget certifikat. Denne meddelelse indeholder listen over navne på tillidsankre (aka “rodcertifikater”), som serveren vil bruge til at validere klientcertifikatet.
• ServerHelloDone: en markeringsmeddelelse (med længde nul), der siger, at serveren er færdig, og klienten skal nu tale.

Klienten skal derefter svare med:

• Certifikat: klientcertifikatet, hvis serveren anmodede om en. Der er subtile variationer mellem versioner (med SSLv3 skal klienten udelade denne meddelelse, hvis den ikke har et certifikat; med TLS 1.0+ skal den i samme situation sende en Certificate besked med en tom liste med certifikater).
• ClientKeyExchange: klientdelen af den aktuelle nøgleudveksling (f.eks. en tilfældig værdi krypteret med serverens RSA-nøgle).
• CertificateVerify: a digital signatur beregnet af klienten over alle tidligere håndtryksmeddelelser. Denne meddelelse sendes, når serveren anmodede om et klientcertifikat, og klienten overholdt det. Dette beviser klienten overfor serveren, at den virkelig “ejer” den offentlige nøgle, der er kodet i det certifikat, den sendte.

Derefter sender klienten en ChangeCipherSpec besked, som ikke er en håndtryksmeddelelse: den har sin egen posttype, så den sendes i en egen post.Indholdet er rent symbolsk (en enkelt byte med værdi 1). Denne meddelelse markerer det punkt, hvor klienten skifter til den nyforhandlede krypteringssuite og nøgler. De efterfølgende poster fra klienten krypteres derefter.

Meddelelsen Færdig er en beregnet kryptografisk kontrolsum over alle tidligere håndtryksmeddelelser (fra både klienten og serveren). Da det udsendes efter ChangeCipherSpec, er det også dækket af integritetskontrol og kryptering. Når serveren modtager denne meddelelse og verificerer dens indhold, får den et bevis på, at den faktisk har talt med den samme klient hele tiden. Denne meddelelse beskytter håndtrykket mod ændringer (angriberen kan ikke ændre håndtryksmeddelelserne og stadig få Finished beskeden rigtigt).

Serveren reagerer endelig med sin egen ChangeCipherSpec derefter Finished. På det tidspunkt er håndtrykket færdigt, og klienten og serveren kan udveksle applikationsdata (i krypterede poster, der er mærket som sådan).

Husk: klienten foreslår men serveren vælger . Chifferpakken er i serverens hænder. Høflige servere skal følge klientens præferencer (hvis det er muligt), men de kan gøre det ellers, og nogle gør det faktisk (f.eks. Som en del af beskyttelsen mod BEAST).

Forkortet håndtryk

I det fulde håndtryk sender serveren et “session ID” (dvs. en flok på op til 32 byte) til klienten. Senere kan klienten vende tilbage og sende det samme session-id som en del af hans ClientHello. Dette betyder, at klienten stadig husker chifferpakken og nøglerne fra det forrige håndtryk og gerne vil genbruge disse parametre. Hvis serveren også husker krypteringssuiten og nøglerne, kopierer den det specifikke session-id i dens ServerHello og følger derefter forkortet håndtryk :

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

Det forkortede håndtryk er kortere: færre beskeder, ingen asymmetrisk kryptografivirksomhed og vigtigst af alt reduceret ventetid . Webbrowsere og servere gør det meget. En typisk webbrowser åbner en SSL-forbindelse med et fuldt håndtryk, gør derefter forkortede håndtryk for alle andre forbindelser til den samme server: de andre forbindelser, den åbner parallelt, og også de efterfølgende forbindelser til den samme server. Typiske webservere lukker faktisk forbindelser efter 15 sekunders inaktivitet, men de vil huske sessioner (chifferpakken og nøglerne) meget længere (muligvis i flere timer eller endda dage).

Nøgleudveksling

Der er flere nøgleudvekslingsalgoritmer, som SSL kan bruge. Dette specificeres af chifferpakken; hver nøgleudvekslingsalgoritme fungerer med nogle former for server-offentlig nøgle. De mest almindelige nøgleudvekslingsalgoritmer er:

• RSA: serverens nøgle er af typen RSA. Klienten genererer en tilfældig værdi (” pre-master-hemmelighed “på 48 byte, hvoraf 46 er tilfældige) og krypterer den med serverens offentlige nøgle. Der er ingen ServerKeyExchange.
• DHE_RSA: serverens nøgle er af typen RSA, men bruges kun til Den aktuelle nøgleudveksling bruger Diffie-Hellman. Serveren sender en ServerKeyExchange -meddelelse, der indeholder DH-parametrene (modul, generator) og en nygenereret DH-offentlig nøgle; desuden serveren underskriver denne meddelelse. Klienten vil svare med en ClientKeyExchange -meddelelse, som også indeholder en ny genereret DH-offentlig nøgle. DH giver “pre-master-hemmeligheden “.
• DHE_DSS: som DHE_RSA, men serveren har en DSS-nøgle (” DSS “er også kendt som “DSA” ). DSS er kun en signaturalgoritme.

Mindre almindeligt anvendte nøgleudvekslingsalgoritmer inkluderer:

• DH: serverens nøgle er af typen Diffie-Hellman (vi taler om et certifikat som indeholder en DH-nøgle). Dette plejede at være “populært” på en administrativ måde (amerikansk føderal regering pålagde dets anvendelse), da RSA-patentet stadig var aktivt (dette var i det foregående århundrede). På trods af det bureaukratiske skub blev det aldrig brugt så bredt som RSA.
• DH_anon: ligesom DHE suiterne, men uden signatur fra serveren. Dette er en certificeringsfri chifferpakke. Ved konstruktion er den sårbar over for Man-in-the-Middle angreb , og er derfor meget sjældent aktiveret overhovedet.
• PSK: foruddelte nøgler krypteringspakker. Den symmetriske eneste nøgleudveksling, der bygger på en forud fastlagt delt hemmelighed.
• SRP: anvendelsen af SRP-protokol , som er en Adgangskodegodkendt nøgleudveksling -protokol. Klient og server godkender hinanden med hensyn til en delt hemmelighed, som kan være en adgangskode med lav entropi (mens PSK kræver en delt hemmelighed med høj entropi). Meget smidig. Ikke bredt understøttet endnu.
• En kortvarig RSA-nøgle: som DHE men med et nyligt genereret RSA-nøglepar. Da generering af RSA-nøgler er dyrt, er dette ikke en populær mulighed og blev kun specificeret som en del af “eksport” -krypteringssuiter, der overholdt de amerikanske eksportregler for kryptografi før 2000 (dvs. RSA-nøgler på højst 512 bit). Ingen gør det i dag.
• Varianter af DH* algoritmer med elliptiske kurver . Meget moderigtigt. Skal blive almindeligt i fremtiden.

Certifikater og godkendelse

Digitale certifikater er beholdere til asymmetriske nøgler. De er beregnet til at løse nøgledistribution. Klienten ønsker nemlig at bruge serveren “s offentlig nøgle . Angriberen vil forsøge at få klienten til at bruge angriberens” offentlige nøgle. Så klienten skal have en måde at sikre sig, at den bruger den rigtige nøgle.

SSL skal bruge X.509 . Dette er en standard for certifikater. Hvert certifikat er underskrevet af en certificeringsmyndighed . Tanken er, at klienten iboende kender de offentlige nøgler til en håndfuld CA (disse er “tillidsankre” eller “rodcertifikater”). Med disse nøgler kan klienten verificere signaturen beregnet af en CA over et certifikat, der er udstedt til serveren. Denne proces kan udvides rekursivt: en CA kan udstede et certifikat til en anden CA (dvs. tegn certifikatstrukturen, der indeholder det andet CA-navn og nøgle). En kæde af certifikater, der begynder med en rod-CA og slutter med serverens certifikat, med mellemliggende CA-certifikater imellem, hvor hvert certifikat er underskrevet relativt til den offentlige nøgle, der er kodet i det forrige certifikat, kaldes fantasifuldt en certifikatkæde .

Så det er meningen, at klienten skal gøre følgende:

• Få en certifikatkæde, der slutter med serverens certifikat. Meddelelsen Certificate fra serveren skal indeholde netop en sådan kæde.
• Valider kæden, dvs. bekræft alle underskrifter og navne og de forskellige X.509 bits. Klienten skal også kontrollere tilbagekaldelsesstatus for alle certifikater i kæden, hvilket er komplekst og tungt (webbrowsere gør det nu mere eller mindre, men det er en nylig udvikling).
• Bekræft, at det tilsigtede servernavn faktisk er skrevet i serverens certifikat. Fordi klienten ikke kun vil bruge en valideret offentlig nøgle, det ønsker også at bruge den offentlige nøgle på en bestemt server . Se RFC 2818 for detaljer om, hvordan dette gøres i en HTTPS-kontekst .

Certificeringsmodellen med X.509-certifikater er ofte blevet kritiseret, ikke rigtig af tekniske grunde, men snarere af politisk-økonomiske årsager. Den koncentrerer valideringskraft i nogle få aktørers hænder , som ikke nødvendigvis er velmenende eller i det mindste ikke altid kompetente . Nu og igen offentliggøres forslag til andre systemer (f.eks. Konvergens eller

Efter den lange præsentation af SSL i forrige svar , lad os gå med de sjove ting, nemlig:

Angreb på SSL

Der har været mange angreb på SSL, nogle bygger på implementeringsfejl, andre på ægte protokolsvagheder.

Man skal huske, at mens SSL er en af de mest angrebne protokoller (da det er meget høj profil: en vellykket applikation til SSL ser meget flot ud i abstrakt af en forskningsartikel), SSL er også en af de mest reparerede protokoller.Det skal betragtes som robust netop fordi alle kendte måder at angribe transportprotokoller er blevet prøvet på SSL, og SSL er blevet patched, hvor det er relevant.

Version rollback

I de første dage af SSLv3 blev SSLv2 stadig meget udbredt, og derfor sendte klienter ofte SSLv2-kompatible ClientHello beskeder, som blot angav, at SSLv3 også blev understøttet; serveren ville derefter tage antydningen og svare i SSLv3 + dialekt (se tillæg E til RFC 2246 for detaljer). Da SSLv2 havde svagheder, var det i den bedste interesse for angriberen at sørge for, at en klient og server, begge kendte SSLv3, ikke desto mindre talte med hinanden ved hjælp af SSLv2. Dette kaldes et versionbackback-angreb . Konceptet strækker sig formelt også til senere versioner.

Kludges er tilføjet for at detektere tilbageførselsforsøg. For back-to-SSLv2-tilbagesendelser skal en klient, der kender SSLv3 +, anvende en særlig polstring til RSA-krypteringstrinnet (SSLv2 understøtter kun RSA-baseret nøgleudveksling): i PKCS # 1 skal de data, der skal krypteres, polstres med et antal tilfældige bytes; en SSLv3-opmærksom klient skal derefter indstille hver af de sidste otte polstringsbyte til den faste værdi 0x03. Serveren kontrollerer derefter disse bytes; hvis de otte 0x03 findes, forsøges sandsynligvis en tilbagevenden, og serveren afviser forsøget (en SSLv2-eneste klient har sandsynligheden kun 255 ^-8 til at bruge sådanne polstringsbyte på grund af manglende held, så falske positive opstår i en ubetydelig hastighed).

For tilbageførsler til en gammel version af SSL / TLS, men ikke ældre end SSLv3, blev der tilføjet en anden kludge: i pre-master-hemmeligheden af 48 bytes, som klienten krypterer med serverens RSA-nøgle, er de to første bytes ikke tilfældige, men skal svare til den “maksimale understøttede protokolversion”, som klienten skrev først i sin ClientHello -besked. Desværre fik nogle klienter det forkert, og denne kludge fungerer kun med en RSA-baseret nøgleudveksling, så beskyttelsen mod tilbageførsel er meget begrænset der. Heldigvis har SSLv3 + en anden, meget kraftigere beskyttelse mod tilbagesendelser, det vil sige, at håndtryksmeddelelserne er hashet sammen, når Finished meddelelserne er bygget. Denne pro tects mod rollbacks, medmindre den “gamle version” ville være så grundigt svag, at angriberen helt kunne bryde hele krypteringen inden afslutningen af selve håndtrykket. Dette er ikke sket endnu (SSLv3 er stadig rimeligt robust).

Svage krypteringssuiter

Nogle af de almindelige chifferpakker er bevidst svage på en eller anden måde. Der er:

• nogle krypteringspakker uden kryptering overhovedet, kun kontrol af integritet, f.eks. TLS_RSA_WITH_NULL_SHA;
• nogle krypteringspakker med 40-bit kryptering, såsom TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (krypteringspakker beregnet til at overholde de strenge amerikanske eksportregler fra sidste århundrede – disse regler er for det meste blevet ophævet i slutningen af Bill Clinton-æraen;
• nogle krypteringspakker med 56-bit kryptering, såsom TLS_RSA_WITH_DES_CBC_SHA. 56-bit DES kan brydes med eksisterende teknologi , men det er stadig lidt svært for en amatør (endda en kedelig studerende med adgang til et par hundrede universitetsmaskiner ), så jeg har en tendens til at kvalificere 56-bit DES som “medium styrke”.

Dette åbner vejen for en variant af tilbageføringsangreb, hvor angriberen tvinger klient og server til at blive enige på en svag cipher-suite, idet ideen er, at angriberen ændrer listen over chiffer-suiter, der er annonceret af klienten. Dette kan fungere for angriberen, hvis den valgte chiffer-suite er så svag, at han kan bryde den for at genberegne en tilsyneladende korrekt Finished besked. Faktisk er den MAC, der bruges i SSLv3 + (selv når den er baseret på MD5), robust nok til at forhindre det. Så ingen egentlig bekymring her. Også min mening er, at enhver reel svaghed her er, når en klient eller en server overhovedet accepterer at bruge en svag krypteringspakke.

Som standard tillader moderne webbrowsere ikke brugen af sådanne svage krypteringspakker.

Tyveri af privat nøgle

Hvis en SSL-forbindelse bruger RSA-nøgleudveksling, og en angriber opbevarer en kopi af optegnelserne, og derefter senere (muligvis måneder efter, muligvis ved at inspicere alle sikkerhedskopier på kasserede harddiske eller bånd) får en kopi af den private nøgle, så kan han fjerne håndtrykket og dekrypter dataene.

Perfect Forward Secrecy handler om at modvirke dette “senere”. Du får det ved at bruge DHE krypteringspakker. Med en DHE-chifferpakke er den egentlige private nøgle, der kunne bruges til at opklare håndtrykket, den kortvarige Diffie-Hellman-nøgle, ikke serverens RSA (eller DSS) private nøgle.Da den var kortvarig, eksisterede den kun i RAM og blev aldrig skrevet til harddisken; som sådan skal det være meget mere modstandsdygtigt over for bagudtyveri.

Så lektionen er: prøv som regel at bruge en DHE-krypteringssuite, hvis det er muligt. Du skal stadig være opmærksom på dine sikkerhedskopier og ikke lade din private nøgle lække, men i det mindste gør DHE-suiter sådan lækage lidt mindre af et problem, især hvis det sker efter afslutningen af nøglens levetid (dvs. det tilsvarende certifikat er ikke længere gyldig).

Certificate Woes

Hele certifikatvirksomheden er en ømt sted i SSL.

SSL er teknisk set ganske uafhængig af X.509. Certifikatkæderne udveksles som uigennemsigtige klatter. På et eller andet tidspunkt skal klienten bruge serverens offentlige nøgle, men klienten kan frit “kende” den nøgle på enhver måde, som den finder passende. I nogle specifikke scenarier, hvor SSL kan bruges, kender klienten allerede serveren “s offentlige nøgle (hårdkodet i koden) og ignorerer bare certifikatet sendt af serveren. Ikke desto mindre i det almindelige tilfælde af HTTPS klienten udfører validering af serverens certifikatkæde som beskrevet i X.509 ( læse det på bekostning af din tilregnelighed; du er blevet advaret).

Dette giver et antal angrebsvektorer, for eksempel:

• Validering indebærer kontrol af, at certifikaterne er stadig gyldige på den aktuelle dato. Hvordan kender klientmaskinen den aktuelle dato? Med sit interne ur og muligvis ved at tale med NTP-servere (i en ganske ubeskyttet måde!). Klienten kunne være slukket med flere minutter, timer, dage, endda år (jeg har set det), og til en vis grad kunne en stærk angriber tvinge det ved at rode med NTP-beskeder. Dette ville tillade angriberen til at bruge forældede certifikater, der er blevet tilbagekaldt for mange år siden. Bemærk en sjov kendsgerning: SSL “tilfældig klient” og “tilfældig server” skal indeholde 28 tilfældige byte og den lokale dato og tid (over 4 Denne inkludering tid var beregnet til at være en del af en løsning mod tidsbaserede angreb. Jeg er ikke opmærksom på nogen implementering, der virkelig kontrollerer den.

• Op til omkring 2003 behandlede implementeringen af certifikatvalidering i Internet Explorer / Windows ikke udvidelsen “Grundlæggende begrænsninger” korrekt. Nettovirkningen var, at nogen med et certifikat på 100 € kunne fungere som CA og udstede “certifikater” med vilkårligt valgt navn og nøgler.

• X .509 inkluderer en funktion til inddæmning af skader kaldet tilbagekaldelse : dette handler om at offentliggøre en liste over forviste certifikater, der ser godt ud, kryptografisk set, men ikke skal have tillid til (f.eks. Blev deres private nøgle stjålet, eller de indeholder et fejlagtigt navn). Tilbagekaldelse fungerer kun så vidt de involverede parter (dvs. browsere) accepterer at downloade mammut-tilbagekaldelseslister (som kan være flere megabyte lange!) Eller kontakte OCSP-servere . Moderne browsere gør det nu, men lidt modvilligt, og mange accepterer alligevel at oprette forbindelse, hvis de ikke kunne få tilbagekaldelsesstatusoplysninger rettidigt (fordi den menneskelige bruger ikke er tålmodig). Den overordnede situation forbedres gennem årene, men ganske langsomt.

• Nogle root-CA begik nogle fejl i fortiden (f.eks. Comodo og DigiNotar). Dette resulterede i udstedelse af falske certifikater (navnet er www.microsoft.com, men den private nøgle er slet ikke i Microsofts hånd …). Disse fejl blev opdaget, og certifikaterne blev tilbagekaldt, men det rejser stadig nogle ubehagelige spørgsmål (er der f.eks. En anden CA, der havde sådanne problemer, men ikke afslørede dem, eller endnu værre, aldrig har bemærket dem?).

X.509 er en meget kompleks samling af algoritmer, teknologier, specifikationer og komitéer, og det er meget svært at få det rigtigt. Forsøg på at afkode X.509-certifikater “manuelt” på et ubeskyttet programmeringssprog som C er en nem måde at opnå bufferoverløb på.

Bleichenbacher-angreb

Daniel Bleichenbacher fandt i 1998 et godt angreb mod RSA. Når du krypterer et stykke data med RSA (som forekommer for ClientKeyExchange beskeden i SSL), skal de data, der skal krypteres, være polstret i rækkefølge at fremstille en bytesekvens af samme længde som RSA-modulet. Polstringen består for det meste af tilfældige byte, men der er en smule struktur (især de to første byte efter polstring skal være 0x00 0x02).

Efter dekryptering (på serveren, så), skal polstringen blive fundet og fjernet. Det sker således, at på det tidspunkt, da serveren dekrypterede, men opnåede en ugyldig polstring (0x00 0x02-byte ikke var der), rapporterede den det med en advarselsmeddelelse (i henhold til SSL-specifikationen), mens en gyldig polstring resulterede i serveren ved hjælp af den tilsyneladende dekrypterede værdi og fortsætter med håndtrykket.

Denne slags ting er kendt som et polstringsorakel . Det giver en hacker mulighed for at sende en vilkårlig sekvens af bytes, som om det var en krypteret præ-masterhemmelighed, og vide, om dekryptering af denne sekvens ville give en gyldig polstring eller ej. Det “er kun 1-bit information, men det er tilstrækkeligt at gendanne den private nøgle med et par millioner anmodninger (med listigt udformede” krypterede “strenge).

Løsning: når dekrypteringen resulterer i en ugyldig polstring, serveren fortsætter med at bruge en tilfældig præ-masterhemmelighed. Håndtrykket mislykkes derefter senere med meddelelserne Finished. Alle aktuelle implementeringer af SSL gør det.

Padding Oracle slår tilbage

Et andet område, hvor der blev fundet et polstringsorakel, er i registrerer sig selv. Overvej CBC-kryptering og HMAC. Dataene, der skal krypteres, MACes først, derefter krypteres resultatet. Med CBC-kryptering skal de data, der skal krypteres, have en længde, der er et multiplum af blokstørrelsen (8 byte for 3DES, 16 bytes for AES). Så der anvendes en vis polstring med en vis struktur.

På det tidspunkt (angrebet blev fundet ud af Vaudenay i 2002), da en SSL-implementering behandlede en modtagelse d-post returnerede den distinkte advarselsmeddelelser for disse to betingelser:

• Ved dekryptering blev der ikke fundet nogen gyldig polstringsstruktur.
• Ved dekryptering, der blev fundet en gyldig polstring, men derefter blev MAC verificeret, og den matchede ikke.

Dette er et polstringsorakel, og det kan bruges til at gendanne nogle krypterede data. Det kræver en aktiv angriber, men det er ikke så svært. Vaudenay implementerede det, og det blev udvidet til det tilfælde, hvor en modificeret SSL-implementering returnerede den samme advarselsmeddelelse i begge tilfælde, men det tog længere tid at vende tilbage i det andet tilfælde, på grund af tiden det tager at beregne MACen igen (en god demonstration af et tidsangreb ).

Fordi folk aldrig lærer, var Microsoft-implementeringen af SSL, der blev brugt i ASP.NET, stadig ikke opdateret fra 2010 (otte år senere!), da Rizzo og Duong genimplementerede Vaudenay-angrebet og byggede en demonstration, der gendannede HTTP-cookies.

Se denne side til nogle henvisninger. Man skal bemærke, at hvis SSL havde brugt krypterings-derefter-MAC , ville sådanne problemer være undgået (de defekte poster ville være blevet afvist på MAC-niveau, før selv overvejer dekryptering).

BEAST

BEAST-angrebet er igen fra Duong og Rizzo, og igen er det en genindspilning af et ældre angreb (fra Philip Rogaway i 2002). For at få ideen skal du overveje CBC . I denne driftsform XORes hver blok af data først med resultatet af krypteringen af den forrige blok; og at “det er resultatet af XOR, der er krypteret. Dette gøres for at” randomisere “blokkene og for at undgå lækager, der findes i ECB-tilstand. Da den første blok ikke har en “forrige” blok, der skal være en Initialiseringsvektor (IV), der spiller rollen som den forrige blok for den første blok.

Det viser sig, at hvis en angriber kan kontrollere en del af de data, der skal krypteres, og også kan forudsige den IV, der vil blive brugt, så kan han gøre krypteringsmaskinen til endnu en dekryptering oracle og brug den til at gendanne nogle andre krypterede data (som angriberen ikke vælger). I SSLv3 og TLS 1.0 kan angriberen dog forudsige IV for en post: det er den sidste blok af den foregående post! Så angriberen skal være i stand til at sende nogle data i strømmen for at “skubbe” måldataene på et punkt, hvor implementeringen byggede og sendte den tidligere post (typisk når 16 kB værd af data er blevet akkumuleret), men begyndte ikke at opbygge den næste.

TLS 1.1+ er beskyttet mod det, fordi der i TLS 1.1 (og efterfølgende versioner) bruges en tilfældig IV pr. record. For SSLv3 og TLS 1.0 er en løsning at sende poster med nul længde: det vil sige poster med en nyttelast på længden nul – men med en MAC og polstring og kryptering, og MAC beregnes fra en hemmelig nøgle og over sekvensen nummer, så dette spiller rollen som en tilfældig talgenerator. Desværre kvæler IE 6.0 på nul-længde poster. Andre strategier involverer en 1 / n-1 split (en n bytes-post sendes som to poster, den ene med en enkelt byte af nyttelast, den anden med den resterende n-1 ).

En anden løsning er at tvinge brugen af en ikke-CBC-krypteringspakke, når det er muligt – serveren vælger en RC4-baseret krypteringspakke, hvis der er en på listen over krypteringspakker sendt af klient, selvom klienten ville have foretrukket en CBC-baseret chifferpakke. Dette værktøj kan fortælle dig, om en given server tilsyneladende fungerer sådan.(Bemærk: BEAST er et angreb på klienten , men ved at vælge en RC4-chifferpakke kan serveren beskytte en skødesløs klient.)

Se denne side for nogle markører. Mens TLS 1.1 er fra 2006, kan BEAST-angrebet muligvis tvinge browserudbydere til endelig at opgradere.

CRIME

Som for enhver Hollywood-franchise offentliggjorde Duong og Rizzo i 2012 efterfølgeren til efterfølgeren. CRIME udnytter en lækage, som blev teoretiseret for mange år siden, men kun blev demonstreret levende i den demonstration, de for nylig offentliggjorde. CRIME udnytter komprimering i samme opsætning som BEAST-angrebet (angriberen kan sende nogle af sine egne data i en SSL-forbindelse, hvor interessante måldata som f.eks. En cookie også sendes). Groft sagt lægger angriberen i sine data en potentiel værdi for målstrengen, og hvis den matcher, gør komprimering de resulterende poster kortere. Se dette spørgsmål for en (præ-kognitiv) analyse.

CRIME undgås ved slet ikke at bruge TLS-niveau komprimering, hvilket er hvad browsere nu gør. Internet Explorer og IIS implementerede aldrig TLS-niveau komprimering i første omgang (for en gangs skyld reddet sløvhed dagen); Firefox og Chrome implementerede det og deaktiverede denne sommer (de blev advaret af Duong og Rizzo, som er ret ansvarlige i deres aktivitet).

FORBRYDELSE viser, hvorfor jeg skrev, nær begyndelsen af min SSL-forklaringer :

SSL opfylder disse mål i stort (men ikke absolut) omfang.

Faktisk lækker kryptering længden af de krypterede data. Der er ingen kendt god løsning imod det. Og længde alene kan afsløre mange ting. For eksempel, når vi observerer med en netværksmonitor en SSL-forbindelse, kan vi få øje på de “ekstra håndtryk” i strømmen (fordi den første byte i hver post identificerer typen af data i posten, og den ikke er krypteret); med længderne af posterne er det ret nemt at se, om klienten leverede et certifikat eller ej.

Puddel

( redigering: dette afsnit er tilføjet den 2014-10-15)

“Puddel” -angrebet udnytter en fejl, der er specifik for SSL 3.0 med CBC-baserede krypteringspakker. Det er afhængig af en ofte overset funktion i SSL 3.0: de fleste polstringsbyte ignoreres. I TLS 1.0 er polstringen (bytes tilføjet i en post for at gøre længden kompatibel med CBC-kryptering, som kun behandler fulde blokke) fuldstændigt specificeret; alle bytes skal have en bestemt værdi, og modtageren kontrollerer det. I SSL 3.0 ignoreres polstringsbyteindhold, hvilket gør det muligt for en hacker at udføre ændringer, der for det meste går ubemærket hen. Ændringen påvirker kun ikke-applikative data, men kan bruges som et dekrypteringsorakel på en måde, der svagt ligner BEAST.

Flere detaljer kan læses i dette svar .

Fremtiden

Mennesker lærer aldrig. Der er et stort pres for at tilføje smarte udvidelser til SSL af mange årsager, der altid ser godt ud i starten, men kan medføre ekstra problemer.

Overvej f.eks. SSL FalseStart . Dette handler primært om, at klienten sender sine applikationsdata lige efter at have sendt sin Finished besked (i et fuldt håndtryk), uden at vente på Finished besked fra serveren. Dette reducerer ventetid, hvilket er godt og velmenende. Det ændrer dog sikkerhedssituationen: Før modtagelsen af Finished -meddelelsen fra serveren er sidstnævnte kun implicit godkendt (klienten har endnu ikke noget bevis for, at den tilsigtede server virkelig var involveret i alt; det ved bare, at uanset hvad det sender kun kan læses af den tilsigtede server). Dette kan have indvirkning; for eksempel kunne en hacker emulere serveren op til dette punkt og tvinge f.eks. klienten til at bruge en CBC-baseret chifferpakke eller TLS-komprimering. Derfor, hvis en klient implementerer FalseStart, nedsætter den effektiviteten af beskyttelsesforanstaltninger mod BEAST og CRIME, som ellers kunne håndhæves af serveren.

(Google deaktiverede FalseStart i foråret, tilsyneladende på grund af kompatibilitetsproblemer med nogle servere. Under alle omstændigheder så “30% latensreduktion” underligt ud, fordi FalseStart kun ville have indflydelse på fulde håndtryk, ikke forkortede håndtryk, så det gør jeg ikke t tro på disse påståede fordele; i det mindste ikke i den størrelsesorden.)

Kommentarer

• Den mængde indsats, du lægger i at give god information gennem dette sted er virkelig vanvittigt og ekstremt beundringsværdigt. Meget værdsat.
• Se også tools.ietf.org / html / rfc7457