Algemeen

SSL (en zijn opvolger, TLS ) is een protocol dat werkt direct bovenop TCP (hoewel er ook implementaties zijn voor op datagram gebaseerde protocollen zoals UDP). Op deze manier kunnen protocollen op hogere lagen (zoals HTTP) ongewijzigd blijven terwijl s tot het zorgen voor een veilige verbinding. Onder de SSL-laag is HTTP identiek aan HTTPS.

Bij correct gebruik van SSL / TLS kan een aanvaller alleen op de kabel zien met welk IP-adres en welke poort je bent verbonden, hoeveel gegevens je ongeveer verstuurt , en welke codering en compressie worden gebruikt. Hij kan ook de verbinding verbreken, maar beide partijen zullen weten dat de verbinding is onderbroken door een derde partij.

Bij normaal gebruik kan de aanvaller ook achterhalen met welke hostnaam u verbinding maakt. (maar niet de rest van de URL): hoewel HTTPS zelf de hostnaam niet vrijgeeft, zal uw browser meestal eerst een DNS-verzoek moeten doen om erachter te komen naar welk IP-adres het verzoek moet worden verzonden.

Hoog -niveaubeschrijving van het protocol

Na het opbouwen van een TCP-verbinding, wordt de SSL-handshake gestart door de client. De client (die zowel een browser kan zijn als elk ander programma zoals Windows Update of PuTTY) verstuurt een aantal specificaties:

• welke versie van SSL / TLS het draait,
• wat ciphersuites het wil gebruiken, en
• wat compressiemethoden die het wil gebruiken.

De server identificeert de hoogste SSL / TLS-versie die zowel door hem als door de client wordt ondersteund, kiest een ciphersuite uit een van de opties van de client (als deze er een ondersteunt) en kiest optioneel een compressiemethode.

Hierna is de basis setup gedaan, de server stuurt zijn certificaat. Dit certificaat moet worden vertrouwd door de klant zelf of door een partij die de klant vertrouwt. Als de klant bijvoorbeeld GeoTrust vertrouwt, kan de klant het certificaat van Google.com vertrouwen omdat GeoTrust cryptografisch ondertekend Google-certificaat.

Nadat het certificaat is geverifieerd en er zeker van is dat deze server echt is wie hij beweert te zijn (en niet een man in het midden), wordt een sleutel uitgewisseld. Dit kan een openbare sleutel zijn, een ” PreMasterSecret ” of gewoon niets, afhankelijk van de gekozen ciphersuite. Zowel de server als de client kunnen nu de sleutel berekenen voor de symmetrische codering ^{whynot PKE?} . De client vertelt de server dat vanaf nu alle communicatie wordt gecodeerd, en stuurt een gecodeerd en geauthenticeerd bericht naar de server.

De server controleert of de MAC (gebruikt voor authenticatie) correct is en dat het bericht correct kan worden gedecodeerd. Vervolgens wordt een bericht geretourneerd dat de client verifieert zoals Nou.

De handshake is nu voltooid en de twee hosts kunnen veilig communiceren. Zie technet.microsoft.com/en-us/library/cc785811 en en.wikipedia voor meer informatie .org / wiki / Secure_Sockets_Layer .

Om de verbinding te sluiten, wordt een close_notify “alert” gebruikt. Als een aanvaller de verbinding probeert te verbreken door de TCP-verbinding te beëindigen (een FIN-pakket te injecteren), zullen beide kanten weten dat de verbinding niet correct is beëindigd. De verbinding kan hierdoor echter niet worden aangetast, alleen onderbroken.

Wat meer details

Waarom kun je Google.com vertrouwen door GeoTrust te vertrouwen?

Een website wil veilig met u communiceren. Om zijn identiteit te bewijzen en er zeker van te zijn dat het geen aanvaller is, moet u de server “s openbare sleutel hebben. U kunt echter nauwelijks alle sleutels opslaan van alle websites op aarde zou de database enorm zijn en zouden updates elk uur moeten worden uitgevoerd!

De oplossing hiervoor zijn Certificate Authorities, of CA in het kort.Toen u uw besturingssysteem of browser installeerde, werd er waarschijnlijk een lijst met vertrouwde CAs meegeleverd. Deze lijst kan naar believen worden gewijzigd; u kunt verwijderen wie u niet vertrouwt, anderen toevoegen of zelfs uw eigen CA maken (hoewel u de enige bent die deze CA vertrouwt, dus het heeft niet veel nut voor een openbare website). In deze CA-lijst wordt ook de openbare sleutel van de CA opgeslagen.

Wanneer de server van Google u zijn certificaat stuurt, vermeldt hij ook dat deze is ondertekend door GeoTrust. Als u GeoTrust vertrouwt, kunt u verifiëren (met behulp van de openbare sleutel van GeoTrust) dat GeoTrust echt het servercertificaat heeft ondertekend. Om zelf een certificaat te ondertekenen heeft u de private key nodig, deze is alleen bekend bij GeoTrust. Op deze manier kan een aanvaller niet zelf een certificaat ondertekenen en ten onrechte claimen Google.com te zijn. Als het certificaat zelfs maar met één bit is gewijzigd, is het teken onjuist en zal de client het weigeren.

Dus als ik de openbare sleutel weet, kan de server zijn identiteit bewijzen?

Ja. Typisch wordt de openbare sleutel versleuteld en de privé sleutel ontsleuteld. Versleutel een bericht met de openbare sleutel van de server, verzend het, en als de server het oorspronkelijke bericht kan herhalen, heeft het gewoon bewezen dat het de privésleutel heeft zonder de sleutel te onthullen.

Dit is waarom het is zo belangrijk om de openbare sleutel te kunnen vertrouwen: iedereen kan een privé / openbaar sleutelpaar genereren, ook een aanvaller. Je wilt niet de openbare sleutel van een aanvaller gebruiken!

Als een van de CAs die u vertrouwt is gecompromitteerd, kan een aanvaller de gestolen privésleutel gebruiken om een certificaat te ondertekenen voor elke gewenste website. Wanneer de aanvaller een vervalst certificaat naar uw cliënt kan sturen, ondertekend door hemzelf met de privésleutel van een CA die u vertrouwt, weet uw cliënt niet dat de openbare sleutel vervalst is, ondertekend met een gestolen privésleutel.

Maar een CA kan me elke server laten vertrouwen die ze willen!

Ja, en dat is waar het vertrouwen vandaan komt in. U moet erop vertrouwen dat de CA geen certificaten maakt zoals ze willen. Wanneer organisaties zoals Microsoft, Apple en Mozilla een CA vertrouwen, moet de CA audits hebben; een andere organisatie controleert deze periodiek om er zeker van te zijn dat alles nog steeds volgens aan de regels.

Het uitgeven van een certificaat wordt gedaan als, en alleen als, de registrant kan bewijzen dat hij eigenaar is van het domein waarvoor het certificaat is uitgegeven.

Wat is deze MAC voor berichtauthenticatie?

Elk bericht is ondertekend met een zogenaamde Message Authentication Code , of MAC in het kort. Als we het eens zijn over een sleutel en een hash-cijfer, kunt u verifiëren dat mijn bericht van mij komt, en ik kan verifiëren dat uw bericht van u komt.

Bijvoorbeeld met de sleutel ” correct paardenaccu nietje ” en het bericht ” voorbeeld “, Ik kan de MAC ” 58393 ” berekenen. Wanneer ik dit bericht met de MAC naar u verzend (u kent de sleutel al), kunt u dezelfde berekening uitvoeren en de berekende MAC koppelen aan de MAC die ik heb verzonden.

Een aanvaller kan het bericht wijzigen maar kent de sleutel niet. Hij kan de juiste MAC niet berekenen en u zult weten dat het bericht niet authentiek is.

Door een volgnummer op te nemen bij het berekenen van de MAC, kunt u replay elimineren. aanvallen . SSL doet dit.

U zei dat de client een sleutel stuurt, die vervolgens wordt gebruikt om symmetrische versleuteling. Wat weerhoudt een aanvaller ervan deze te gebruiken?

De openbare sleutel van de server doet dat. Aangezien we hebben geverifieerd dat de openbare sleutel echt bij de server hoort en niemand anders, kan de sleutel versleutelen met de openbare sleutel. Wanneer de server deze ontvangt, kan hij deze ontsleutelen met de privésleutel. Als iemand anders deze ontvangt, kunnen ze deze niet ontsleutelen.

Dit is ook de reden waarom de sleutelgrootte van belang is: Hoe groter de publieke en private sleutel, hoe moeilijker het is om de sleutel te kraken die de client naar de server stuurt.

Hoe SSL te kraken

Samenvattend :

• Probeer of de gebruiker certificaatwaarschuwingen negeert;
• De toepassing laadt mogelijk gegevens van een niet-versleuteld kanaal (bijv. HTTP), waarmee geknoeid kan worden;
• Een onbeschermde aanmeldingspagina die naar HTTPS wordt verzonden, kan worden gewijzigd zodat deze naar HTTP wordt verzonden;
• Toepassingen die niet zijn gepatcht, kwetsbaar voor exploits zoals BEAST en CRIME;
• toevlucht nemen tot andere methoden suc h als een fysieke aanval;
• Exploiteer zijkanalen zoals berichtlengte en de tijd genomen om het bericht te vormen;
• Wacht op kwantumaanvallen .

Zie ook: Een schema met veel aanvalsvectoren tegen SSL door Ivan Ristic ^(png)

In detail:

Er is geen eenvoudige en ongecompliceerde manier; SSL is veilig als het correct wordt gedaan. Een aanvaller kan het echter proberen als de gebruiker certificaatwaarschuwingen negeert, wat de beveiliging onmiddellijk zou verbreken. Wanneer een gebruiker dit doet, heeft de aanvaller geen privésleutel van een CA nodig om een certificaat te vervalsen, hij hoeft alleen een eigen certificaat te sturen.

Een andere manier zou zijn door een fout in de applicatie (server- of client-side). Een eenvoudig voorbeeld is in websites: als een van de bronnen die door de website worden gebruikt (zoals een afbeelding of een script) via HTTP wordt geladen, kan de vertrouwelijkheid niet meer worden gegarandeerd. stuur de HTTP-verwijzingsheader niet wanneer u niet-beveiligde bronnen aanvraagt vanaf een beveiligde pagina ( source ), het is nog steeds mogelijk dat iemand die het verkeer afluistert, raadt waar u bent “op bezoek van; Als ze bijvoorbeeld weten dat afbeeldingen X, Y en Z op één pagina worden gebruikt, kunnen ze raden dat u die pagina bezoekt wanneer ze zien dat uw browser die drie afbeeldingen tegelijk opvraagt. Bovendien kan bij het laden van Javascript de hele pagina in gevaar komen. Een aanvaller kan elk script op de pagina uitvoeren, door bijvoorbeeld aan te passen naar wie de banktransactie zal gaan.

Wanneer dit gebeurt (een bron wordt geladen via HTTP), geeft de browser een waarschuwing met gemengde inhoud: Chrome , Firefox , Internet Explorer 9

Een andere truc voor HTTP is wanneer de inlogpagina niet is beveiligd en deze zich aanmeldt bij een https-pagina. ” Geweldig, ” dacht de ontwikkelaar waarschijnlijk, ” nu bespaar ik de serverbelasting en de wachtwoord wordt nog steeds versleuteld verzonden! ” Het probleem is sslstrip , een tool die de onveilige inlogpagina aanpast zodat deze verzendt ergens zodat de aanvaller het kan lezen.

Er zijn de afgelopen jaren ook verschillende aanvallen geweest, zoals de TLS heronderhandeling kwetsbaarheid , sslsniff , BEAST en zeer recent CRIMINALITEIT . Alle gangbare browsers zijn echter beschermd tegen al deze aanvallen, dus deze kwetsbaarheden vormen geen risico als u een up-to-date browser gebruikt.

Last but not least kunt u andere methoden gebruiken om de informatie die SSL u weigert te verkrijgen. Als je de verbinding van de gebruiker al kunt zien en ermee kunt knoeien, is het misschien niet zo moeilijk om een van zijn / haar .exe-downloads te vervangen door een keylogger, of om die persoon gewoon fysiek aan te vallen. Cryptografie is misschien vrij veilig, maar mensen en menselijke fouten zijn nog steeds een zwakke factor. Volgens dit artikel van Verizon , betrof 10% van de datalekken fysieke aanvallen (zie pagina 3), dus ” is zeker iets om in gedachten te houden.

Reacties

• Ik zou graag wat meer uitleg willen voor ” een sleutel wordt ingeruild ” voor de symmetrische sleutel. Hoe kan dit gebeuren dat iemand met een packet sniffer geen toegang heeft.
• @Yehosef Goede vraag! Ik vergat dat uit te leggen in mijn antwoord. Als je rondkijkt, blijkt dat er eigenlijk een vraag aan is gewijd: security.stackexchange.com/q/6290/10863
• @ Iwazaru Alle CAs doen dit sinds de eerste dag. Het doel van een certificaat is om de openbare sleutel voor een bepaald domein te leveren, en het punt om het te ondertekenen om te bewijzen dat het echt de juiste sleutel voor het domein is. Laat ‘ s Encrypt doet precies wat het zou moeten doen: verifiëren dat u de eigenaar bent van het domein en uw certificaat ondertekenen (met uw sleutel) als u het kunt bewijzen. Nu zal iedereen die Let ‘ s Encrypt vertrouwt, wat praktisch elke browser is, dat certificaat vertrouwen.
• Eh, nee. TLS is inderdaad gewoon bovenop TCP geïmplementeerd.
• Ik vond dit grafische SSL-handshake-proces heel duidelijk.

Aangezien het algemene concept van SSL al is behandeld in enkele andere vragen (bijv. deze en die ), deze keer ga ik voor details. Details zijn belangrijk. Dit antwoord zal enigszins uitgebreid zijn.

Geschiedenis

SSL is een protocol met een lange geschiedenis en verschillende versies.De eerste prototypes kwamen van Netscape toen ze de eerste versies van hun vlaggenschipbrowser ontwikkelden, Netscape Navigator (deze browser heeft Mosaic in de vroege tijden van de Browser Wars, die nog steeds woedt, zij het met nieuwe concurrenten). Versie 1 is nooit openbaar gemaakt, dus we weten niet hoe het eruit zag. SSL-versie 2 wordt beschreven in een concept dat daar kan worden gelezen; het heeft een aantal zwakke punten, waarvan sommige nogal ernstig zijn, dus het is verouderd en nieuwere SSL / TLS-implementaties ondersteunen het niet (terwijl oudere standaard gedeactiveerd). Ik zal niet verder spreken over SSL-versie 2, behalve als een incidentele referentie.

SSL-versie 3 (die ik “SSLv3” zal noemen) was een verbeterd protocol dat nog steeds werkt en breed wordt ondersteund. Hoewel het nog steeds eigendom is van Netscape Communications (of degene die dat tegenwoordig bezit), is het protocol gepubliceerd als een “historische RFC” ( RFC 6101 ). Ondertussen is het protocol gestandaardiseerd, met een nieuwe naam om juridische problemen te vermijden; de nieuwe naam is TLS .

Er zijn tot nu toe drie versies van TLS geproduceerd, elk met zijn speciale RFC: TLS 1.0 , TLS 1.1 en TLS 1.2 . Ze lijken intern erg op elkaar en met SSLv3, tot het punt dat een implementatie SSLv3 en alle drie de TLS-versies gemakkelijk kan ondersteunen, waarbij ten minste 95% van de code gemeenschappelijk is. Toch worden alle versies intern aangeduid met een versienummer met het major.minor formaat; SSLv3 is dan 3.0, terwijl de TLS-versies respectievelijk 3.1, 3.2 en 3.3 zijn. Het is dus geen wonder dat TLS 1.0 soms SSL 3.1 wordt genoemd (en het is ook niet onjuist). SSL 3.0 en TLS 1.0 verschillen slechts enkele minuten van details. TLS 1.1 en 1.2 worden nog niet breed ondersteund, al is daar wel een aanzet voor vanwege mogelijke zwakheden (zie hieronder voor de “BEAST-aanval”). SSLv3 en TLS 1.0 worden “overal” ondersteund (zelfs IE 6.0 kent ze).

Context

SSL is bedoeld om een veilige bidirectionele tunnel te bieden voor willekeurige gegevens. Overweeg TCP , het bekende protocol voor het verzenden van gegevens via internet. TCP werkt via de IP “pakketten” en biedt een bidirectionele tunnel voor bytes; het werkt voor elke byte-waarde en stuurt ze naar twee streams die tegelijkertijd kunnen werken. TCP zorgt voor het harde werk van het opsplitsen van de gegevens in pakketten, ze te erkennen, ze weer in de juiste volgorde te zetten, terwijl duplicaten worden verwijderd en verloren pakketten opnieuw worden verzonden. Vanuit het oogpunt van de toepassing die TCP gebruikt, zijn er slechts twee streams en zijn de pakketten onzichtbaar; in het bijzonder worden de streams niet opgesplitst in “berichten” (het is aan de toepassing om zijn eigen coderingsregels te nemen als het berichten wil hebben, en dat “is precies wat HTTP doet dit).

TCP is betrouwbaar in de aanwezigheid van “ongelukken”, dat wil zeggen transmissiefouten als gevolg van slechte hardware, netwerkcongestie, mensen met smartphones die buiten het bereik van een bepaald basisstation lopen en andere niet-kwaadwillige gebeurtenissen. Een persoon met slechte bedoelingen (de “aanvaller”) met enige toegang tot het transportmedium kan echter alle verzonden gegevens lezen en / of opzettelijk wijzigen, en TCP biedt daar geen bescherming tegen. SSL.

SSL gaat ervan uit dat het werkt via een TCP-achtig protocol, dat een betrouwbare stroom levert; SSL implementeert geen heruitgave van verloren pakketten en dergelijke. De aanvaller is dat wel verondersteld aan de macht te zijn om de communicatie volledig op een onvermijdelijke manier te verstoren (hij kan bijvoorbeeld de kabels doorknippen), dus het is de taak van SSL om:

• detecteren wijzigingen (de aanvaller mag de gegevens niet stil kunnen wijzigen);
• de vertrouwelijkheid van gegevens waarborgen (de aanvaller mag geen kennis verwerven over de uitgewisselde gegevens).

SSL vervult deze doelen in grote (maar niet absolute) mate.

Records

SSL is gelaagd en de onderste laag is het recordprotocol . Alle gegevens die in een SSL-tunnel worden verzonden, worden opgesplitst in records . Over de draad (de onderliggende TCP-socket of TCP-achtig medium) ziet een record er als volgt uit:

HH V1:V2 L1:L2 data

waar:

• HH is een enkele byte die het type gegevens in het record aangeeft.Er zijn vier typen gedefinieerd: change_cipher_spec (20), alert (21), handshake (22) en application_data ( 23).
• V1: V2 is de protocolversie, meer dan twee bytes. Voor alle momenteel gedefinieerde versies heeft V1 de waarde 0x03, terwijl V2 de waarde 0x00 heeft voor SSLv3, 0x01 voor TLS 1.0, 0x02 voor TLS 1.1 en 0x03 voor TLS 1.2.
• L1: L2 is de lengte van data, in bytes (big-endian-conventie is gebruikt: de lengte is 256 * L1 + L2). De totale lengte van data mag niet langer zijn dan 18432 bytes, maar in de praktijk kan het die waarde niet eens bereiken.

Dus een record heeft een vijf- byte header, gevolgd door maximaal 18 kB aan gegevens. De data is waar symmetrische codering en integriteitscontroles worden toegepast. Wanneer een record wordt verzonden, moeten zowel de verzender als de ontvanger het eens zijn over welke cryptografische algoritmen momenteel worden toegepast en met welke sleutels; deze overeenkomst wordt verkregen via het handshake-protocol, beschreven in de volgende sectie. Eventuele compressie wordt op dat punt ook toegepast.

In alle details werkt het bouwen van een record als volgt:

• Aanvankelijk zijn er enkele bytes om over te dragen ; dit zijn toepassingsgegevens of een ander soort bytes. Deze payload bestaat uit maximaal 16384 bytes, maar mogelijk minder (een payload met lengte 0 is legaal, maar het blijkt dat Internet Explorer 6.0 dat helemaal niet leuk vindt ) .
• De payload wordt vervolgens gecomprimeerd met het compressie-algoritme dat op dat moment is overeengekomen. Compressie is stateful en kan dus afhangen van de inhoud van eerdere records. In de praktijk is compressie ofwel “null” (helemaal geen compressie) of “Deflate” ( RFC 3749 ), waarbij de laatste momenteel hoffelijk maar duidelijk de uitgang wordt getoond door in de webcontext, vanwege de recente CRIME-aanval . Compressie is bedoeld om gegevens in te korten, maar het moet deze noodzakelijkerwijs enigszins uitbreiden in sommige ongunstige situaties (vanwege het postvakje-principe ). SSL maakt een uitbreiding van maximaal 1024 bytes mogelijk. Nulcompressie breidt natuurlijk nooit uit (maar wordt ook nooit verkort); Deflate wordt met maximaal 10 bytes uitgebreid als de implementatie goed is.
• De gecomprimeerde payload wordt dan beschermd tegen wijzigingen en gecodeerd. Als de huidige encryptie- en integriteitsalgoritmen “nul” zijn, dan is deze stap een niet-bewerking. Anders wordt een MAC toegevoegd, vervolgens wat opvulling (afhankelijk van het versleutelingsalgoritme), en het resultaat wordt versleuteld. Deze stappen leiden weer tot enige uitbreiding, die de SSL-standaard beperkt tot 1024 extra bytes (gecombineerd met de maximale uitbreiding van de compressiestap brengt dit ons bij de 18432 bytes, waaraan we de 5-byte header moeten toevoegen).

De MAC is meestal HMAC met een van de gebruikelijke hash-functies (meestal MD5, SHA-1 of SHA-256) (met SSLv3 is dit niet de “echte” HMAC maar iets vergelijkbaars en, naar ons beste weten, net zo veilig als HMAC). Versleuteling maakt gebruik van een blokcijfer in de CBC-modus of het RC4 stroomcijfer. Merk op dat in theorie andere soorten modi of algoritmen kunnen worden gebruikt, bijvoorbeeld een van deze handige modi die codering en integriteitscontroles combineren; er zijn zelfs wat RFC daarvoor . In de praktijk kennen geïmplementeerde implementaties deze echter nog niet, dus HMAC en CBC. Cruciaal is dat de MAC eerst wordt berekend en aan de gegevens wordt toegevoegd, en het resultaat wordt gecodeerd. Dit is MAC-dan-versleuteling en het is eigenlijk geen erg goed idee . De MAC wordt berekend via de aaneenschakeling van de (gecomprimeerde) payload en een volgnummer, zodat een ijverige aanvaller geen records mag ruilen.

Handshake

De handshake is een protocol dat wordt afgespeeld binnen het opnameprotocol. Het doel is om de algoritmen en sleutels vast te stellen die voor de records moeten worden gebruikt. Het bestaat uit berichten . Elk handshakebericht begint met een koptekst van vier bytes, één byte die het berichttype beschrijft, en vervolgens drie bytes voor de berichtlengte (big-endian-conventie). De opeenvolgende handshake-berichten worden vervolgens verzonden met records die zijn getagd met het type “handshake” (de eerste byte van de koptekst van elk record heeft waarde 22).

Let op de lagen: de handshake-berichten, compleet met vier- byte-header, worden vervolgens als records verzonden en elk record heeft ook zijn eigen header. Bovendien kunnen meerdere handshakeberichten binnen hetzelfde record worden verzonden en kan een bepaald handshakebericht over meerdere records worden verdeeld.Vanuit het oogpunt van de module die de handshakeberichten opbouwt, zijn de “records” slechts een stroom waarop bytes kunnen worden verzonden; het is zich niet bewust van de feitelijke opsplitsing van die stroom in records.

Volledige handdruk

Aanvankelijk zijn client en server “het eens over” nulcodering zonder MAC en nulcompressie. Dit betekent dat het record dat ze als eerste zullen verzenden, als cleartext en onbeschermd wordt verzonden.

Het eerste bericht van een handshake is een ClientHello. Het is het bericht waarmee de klant aangeeft dat hij van plan is om wat SSL te doen. Merk op dat “cliënt” een symbolische rol is; het betekent “de partij die als eerste spreekt”. Het gebeurt zo dat in de HTTPS-context, die HTTP-binnen-SSL-binnen-TCP is, alle drie de lagen een notie hebben van “client” en “server”, en ze zijn het er allemaal over eens (de TCP-client is ook de SSL-client en de HTTP-client), maar dat is nogal toeval.

Het ClientHello bericht bevat:

• het maximale protocol versie die de client wenst te ondersteunen;
• de “client random” (32 bytes, waarvan er 28 zouden moeten worden gegenereerd met een cryptografisch sterke nummergenerator);
• de ” sessie-ID “(in het geval dat de cliënt een sessie wil hervatten in een verkorte handdruk, zie hieronder);
• de lijst met” coderingssuites “waarvan de cliënt weet, gesorteerd op cliëntvoorkeur;
• de lijst met compressie-algoritmen die de klant kent, gerangschikt volgens de voorkeur van de klant;
• enkele optionele extensies.

A coderingssuite is een 16-bits symbolische identifier voor een set cryptografi c algoritmen. De TLS_RSA_WITH_AES_128_CBC_SHA coderingssuite heeft bijvoorbeeld de waarde 0x002F, en betekent dat “records HMAC / SHA-1 en AES-codering gebruiken met een 128-bits sleutel, en de sleuteluitwisseling gebeurt door codering een willekeurige sleutel met de openbare RSA-sleutel van de server.

De server reageert op de ClientHello met een ServerHello die bevat:

• de protocolversie die de client en server zullen gebruiken;
• de “server random” (32 bytes, met 28 willekeurige bytes);
• de sessie-ID voor deze verbinding;
• de coderingssuite die zal worden gebruikt;
• het compressie-algoritme dat zal worden gebruikt;
• optioneel, enkele extensies.

De volledige handshake ziet er als volgt uit:

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

(dit schema is schaamteloos gekopieerd van de RFC.)

We zien de ClientHello en ServerHello. Vervolgens verzendt de server een paar andere berichten, die afhankelijk zijn van de coderingssuite en een andere parameter rs:

• Certificaat: het servercertificaat, dat de publieke sleutel bevat. Meer daarover hieronder. Dit bericht wordt bijna altijd verzonden, behalve als de coderingssuite een handdruk zonder certificaat vereist.
• ServerKeyExchange: enkele extra waarden voor de sleuteluitwisseling, als wat in het certificaat staat niet voldoende is. In het bijzonder gebruiken de “DHE” -cijferreeksen een kortstondige Diffie-Hellman -sleuteluitwisseling, waarvoor dat bericht vereist is.
• CertificateRequest: een bericht waarin wordt gevraagd dat de client ook zichzelf identificeert met een eigen certificaat. Dit bericht bevat de lijst met namen van trust anchors (ook wel “rootcertificaten” genoemd) die de server zal gebruiken om het clientcertificaat te valideren.
• ServerHelloDone: een markeringsbericht (met een lengte van nul) dat zegt dat de server klaar is en dat de client nu moet praten.

De client moet dan reageren met:

• Certificaat: het clientcertificaat, if de server heeft er een aangevraagd. Er zijn subtiele variaties tussen versies (met SSLv3 moet de client dit bericht weglaten als het geen certificaat heeft; met TLS 1.0+, in dezelfde situatie, moet het een Certificate verzenden bericht met een lege lijst met certificaten).
• ClientKeyExchange: het clientgedeelte van de daadwerkelijke sleuteluitwisseling (bijv. een willekeurige waarde gecodeerd met de server RSA-sleutel).
• CertificateVerify: a digitale handtekening berekend door de cliënt over alle voorgaande handshakeberichten. Dit bericht wordt verzonden wanneer de server een clientcertificaat heeft aangevraagd en de client hieraan heeft voldaan. Dit is hoe de client aan de server bewijst dat hij echt de openbare sleutel “bezit” die is gecodeerd in het certificaat dat hij heeft verzonden.

Vervolgens stuurt de client een ChangeCipherSpec bericht, dat geen handshake-bericht is: het heeft zijn eigen recordtype, dus het wordt in een eigen record verzonden.De inhoud is puur symbolisch (een enkele byte met waarde 1). Dit bericht markeert het punt waarop de client overschakelt naar de nieuw onderhandelde coderingssuite en sleutels. De volgende records van de client worden vervolgens versleuteld.

Het Finished -bericht is een cryptografische checksum die is berekend over alle voorgaande handshake-berichten (van zowel de client als de server). Aangezien het wordt uitgezonden na de ChangeCipherSpec, valt het ook onder de integriteitscontrole en de versleuteling. Wanneer de server dat bericht ontvangt en de inhoud ervan verifieert, krijgt hij een bewijs dat hij inderdaad al die tijd met dezelfde cliënt heeft gesproken. Dit bericht beschermt de handshake tegen wijzigingen (de aanvaller kan de handshake-berichten niet wijzigen en krijgt toch het Finished -bericht goed).

De server reageert eindelijk met zijn eigen ChangeCipherSpec en vervolgens Finished. Op dat punt is de handshake voltooid en kunnen de client en server toepassingsgegevens uitwisselen (in gecodeerde records die als zodanig zijn gemarkeerd).

Om te onthouden: de client suggereert maar de server kiest . De coderingssuite is in handen van de server. Hoffelijke servers worden verondersteld de voorkeuren van de klant te volgen (indien mogelijk), maar ze kunnen anders en sommige doen dat ook (bijvoorbeeld als onderdeel van bescherming tegen BEAST).

Afgekorte handdruk

In de volledige handshake stuurt de server een “sessie-ID” (dwz een bundel van maximaal 32 bytes) naar de client. Later kan de cliënt terugkomen en dezelfde sessie-ID verzenden als onderdeel van zijn ClientHello. Dit betekent dat de client nog steeds de coderingssuite en sleutels van de vorige handshake onthoudt en deze parameters opnieuw wil gebruiken. Als de server ook de coderingssuite en sleutels onthoudt, kopieert hij die specifieke sessie-ID in zijn ServerHello, en volgt dan de afgekorte handshake :

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

De afgekorte handshake is korter: minder berichten, nee asymmetrische cryptografie, en, belangrijker nog, verminderde latentie . Webbrowsers en servers doen dat veel. Een typische webbrowser opent een SSL-verbinding met een volledige handshake en voert vervolgens afgekorte handshakes uit voor alle andere verbindingen met dezelfde server: de andere verbindingen die hij parallel opent, en ook de daaropvolgende verbindingen met dezelfde server. Inderdaad, typische webservers zullen verbindingen verbreken na 15 seconden inactiviteit, maar ze zullen sessies (de coderingssuite en sleutels) veel langer onthouden (mogelijk uren of zelfs dagen).

Sleuteluitwisseling

Er zijn verschillende sleuteluitwisselingsalgoritmen die SSL kan gebruiken. Dit wordt gespecificeerd door de cijferreeks; elk sleuteluitwisselingsalgoritme werkt met bepaalde soorten openbare serversleutel. De meest voorkomende algoritmen voor sleuteluitwisseling zijn:

• RSA: de sleutel van de server is van het type RSA. De client genereert een willekeurige waarde (de ” pre-master secret “van 48 bytes, waarvan 46 willekeurig) en versleutelt het met de openbare sleutel van de server. Er is geen ServerKeyExchange.
• DHE_RSA: de sleutel van de server is van het type RSA, maar wordt alleen gebruikt voor handtekening. De daadwerkelijke sleuteluitwisseling maakt gebruik van Diffie-Hellman. De server stuurt een ServerKeyExchange -bericht met de DH-parameters (modulus, generator) en een nieuw gegenereerde openbare DH-sleutel. Bovendien ondertekent dit bericht. De client zal reageren met een ClientKeyExchange bericht dat ook een nieuw gegenereerde openbare DH-sleutel bevat. De DH levert het “pre-mastergeheim “.
• DHE_DSS: zoals DHE_RSA, maar de server heeft een DSS-sleutel (” DSS “is ook bekend als “DSA” ). DSS is een algoritme voor alleen handtekeningen.

Minder vaak gebruikte algoritmen voor sleuteluitwisseling zijn:

• DH: de sleutel van de server is van het type Diffie-Hellman (we hebben het over een certificaat dat een DH-toets). Vroeger was dit op administratieve wijze “populair” (de federale regering van de VS heeft het gebruik ervan verplicht gesteld) toen het RSA-octrooi nog actief was (dit was in de vorige eeuw). Ondanks de bureaucratische druk, werd het nooit zo breed ingezet als RSA.
• DH_anon: zoals de DHE suites, maar zonder de handtekening van de server. Dit is een coderingssuite zonder certificaten. Door de constructie is het kwetsbaar voor Man-in-the-Middle-aanvallen , dus zeer zelden ingeschakeld.
• PSK: vooraf gedeelde sleutel coderingssuites. De symmetrische sleuteluitwisseling, voortbouwend op een vooraf vastgesteld gedeeld geheim.
• SRP: de toepassing van het SRP-protocol dat een Met wachtwoord geverifieerd sleuteluitwisselingsprotocol . Client en server authenticeren elkaar met betrekking tot een gedeeld geheim, wat een wachtwoord met lage entropie kan zijn (terwijl PSK een gedeeld geheim met hoge entropie vereist). Heel handig. Nog niet breed ondersteund.
• Een kortstondige RSA-sleutel: zoals DHE maar met een nieuw gegenereerd RSA-sleutelpaar. Aangezien het genereren van RSA-sleutels duur is, is dit geen populaire optie en werd deze alleen gespecificeerd als onderdeel van “export” -cijferreeksen die voldeden aan de Amerikaanse exportregels voor cryptografie van vóór 2000 (d.w.z. RSA-sleutels van maximaal 512 bits). Niemand doet dat tegenwoordig.
• Varianten van de DH* algoritmen met elliptische curven . Erg stijlvol. Moet in de toekomst gebruikelijk worden.

Certificaten en authenticatie

Digitale certificaten zijn schepen voor asymmetrische sleutels. Ze zijn bedoeld om sleuteldistributie op te lossen. De client wil namelijk de openbare sleutel van de server gebruiken. De aanvaller zal proberen de client de openbare sleutel van de aanvaller te laten gebruiken. De klant moet dus een manier hebben om ervoor te zorgen dat hij de juiste sleutel gebruikt.

SSL wordt verondersteld X.509 te gebruiken. Dit is een standaard voor certificaten. Elk certificaat is ondertekend door een certificeringsinstantie . Het idee is dat de client inherent de openbare sleutels van een handvol CA kent (dit zijn de “trust anchors” of “rootcertificaten”). Met deze sleutels kan de cliënt de handtekening verifiëren die door een CA is berekend over een certificaat dat aan de server is uitgegeven. Dit proces kan recursief worden uitgebreid: een CA kan een certificaat uitgeven voor een andere CA (d.w.z. ondertekenen de certificaatstructuur die de andere CA-naam en sleutel bevat). Een keten van certificaten die begint met een root-CA en eindigt met het servercertificaat, met tussenliggende CA-certificaten, waarbij elk certificaat wordt ondertekend ten opzichte van de openbare sleutel die in het vorige certificaat is gecodeerd, wordt, fantasieloos, a certificaatketen .

Dus de cliënt wordt verondersteld het volgende te doen:

• Haal een certificaatketen op die eindigt met het servercertificaat. Het Certificate bericht van de server wordt verondersteld precies zon ketting te bevatten.
• Valideer de ketting, dwz het verifiëren van alle handtekeningen en namen en de verschillende X.509-bits. De client moet ook de intrekkingsstatus van alle certificaten in de keten controleren, die complex en zwaar is (webbrowsers doen het nu min of meer, maar is een recente ontwikkeling).
• Controleer of de bedoelde servernaam inderdaad in het servercertificaat is geschreven. Omdat de client niet alleen een gevalideerde openbare sleutel wil gebruiken, het wil ook de openbare sleutel van een specifieke server gebruiken. Zie RFC 2818 voor details over hoe dit wordt gedaan in een HTTPS-context .

Het certificeringsmodel met X.509-certificaten is vaak bekritiseerd, niet echt om technische redenen, maar eerder om politiek-economische redenen. Het concentreert de validatiekracht in de handen van een paar spelers , die niet per se goed bedoeld zijn, of in ieder geval niet altijd competent . Af en toe worden voorstellen voor andere systemen gepubliceerd (bijv. Convergentie of

Na de lange presentatie van SSL in het vorige antwoord , laten we gaan met de leuke dingen, namelijk:

Aanvallen op SSL

Er zijn veel aanvallen op SSL, sommige voortbouwend op implementatiefouten, andere op echte protocolzwakheden.

Men moet niet vergeten dat hoewel SSL een van de meest aangevallen protocollen is (aangezien het een zeer hoog profiel heeft: een succesvolle toepassing voor SSL ziet er erg mooi uit in de samenvatting van een onderzoeksartikel), SSL is ook een van de meest gerepareerde protocollen.Het moet als robuust worden beschouwd, juist omdat alle bekende manieren om transportprotocollen aan te vallen zijn geprobeerd op SSL, en SSL is waar nodig gepatcht.

Versie terugdraaien

In de begintijd van SSLv3 werd SSLv2 nog steeds veel gebruikt, en daarom stuurden klanten vaak SSLv2-compatibele ClientHello berichten, die alleen aangaven dat SSLv3 ook werd ondersteund; de server zou dan de hint nemen en reageren in SSLv3 + dialect (zie Appendix E van RFC 2246 voor details). Omdat SSLv2 zwakke punten vertoonde, was het in het belang van de aanvaller om een client en server, die allebei SSLv3 kennen, toch met elkaar te laten praten via SSLv2. Dit wordt een versie-rollback-aanval genoemd. Het concept strekt zich formeel ook uit naar latere versies.

Kludges zijn toegevoegd om pogingen tot terugdraaien te detecteren. Voor de back-to-SSLv2-rollbacks moet een client die SSLv3 + kent, een speciale padding gebruiken voor de RSA-versleutelingsstap (SSLv2 ondersteunt alleen RSA-gebaseerde sleuteluitwisseling): in PKCS # 1 , wordt verondersteld dat de gegevens die moeten worden versleuteld, worden opgevuld met een aantal willekeurige bytes; een SSLv3-bewuste client wordt dan verondersteld elk van de laatste acht paddingbytes in te stellen op de vaste waarde 0x03. De server controleert vervolgens deze bytes; als de acht 0x03 worden gevonden, wordt hoogstwaarschijnlijk geprobeerd een terugdraaiing uit te voeren en weigert de server de poging (een SSLv2-client heeft waarschijnlijk slechts 255 ^-8 om dergelijke opvulbytes te gebruiken bij gebrek aan geluk, dus valse positieven komen met een verwaarloosbare snelheid voor).

Voor rollbacks naar een oude versie van SSL / TLS, maar niet ouder dan SSLv3, werd een andere kludge toegevoegd: in het pre-mastergeheim van 48 bytes die de client versleutelt met de RSA-sleutel van de server, de eerste twee bytes zijn niet willekeurig, maar moeten gelijk zijn aan de “maximaal ondersteunde protocolversie” die de client als eerste schreef in zijn ClientHello bericht. Helaas hebben sommige klanten het bij het verkeerde eind, en deze kludge werkt alleen met een op RSA gebaseerde sleuteluitwisseling, dus de bescherming tegen rollback is daar zeer beperkt. Gelukkig heeft SSLv3 + een andere, veel krachtigere bescherming tegen rollbacks, wat betekent dat de handshake-berichten aan elkaar worden gehasht wanneer de Finished -berichten worden gebouwd. Deze professional beschermt tegen rollbacks, tenzij de “oude versie” zo door en door zwak zou zijn dat de aanvaller de hele codering volledig zou kunnen verbreken voordat de handshake zelf is afgelopen. Dit is nog niet gebeurd (SSLv3 is nog redelijk robuust).

Zwakke coderingssuites

Sommige van de standaard coderingssuites zijn op de een of andere manier opzettelijk zwak. Er zijn:

• sommige coderingssuites zonder enige codering, alleen integriteitscontrole, bijv. TLS_RSA_WITH_NULL_SHA;
• sommige coderingssuites met 40-bits codering, zoals TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (coderingssuites bedoeld om te voldoen aan de strenge Amerikaanse exportregels van de vorige eeuw – deze regels zijn grotendeels opgeheven aan het einde van het Bill Clinton-tijdperk);
• sommige coderingssuites met 56-bits codering, zoals TLS_RSA_WITH_DES_CBC_SHA. 56-bits DES kan worden verbroken met bestaande technologie , maar dat is nog steeds een beetje moeilijk voor een amateur (zelfs een verveelde student met toegang tot een paar honderd universiteitsmachines ), dus ik heb de neiging om 56-bits DES te kwalificeren als “gemiddelde sterkte”.

Dit opent de weg naar een variant van versie-rollback-aanvallen, waarbij de aanvaller client en server dwingt tot overeenstemming op een zwakke coderingssuite, het idee is dat de aanvaller de lijst met coderingssuites wijzigt die door de client zijn aangekondigd. Dit is werkbaar voor de aanvaller als de geselecteerde coderingssuite zo zwak is dat hij deze kan breken om een ogenschijnlijk correcte Finished message. Eigenlijk is de MAC die wordt gebruikt in SSLv3 + (zelfs wanneer gebaseerd op MD5) robuust genoeg om dat te voorkomen. Dus maak je hier geen zorgen. Ook ben ik van mening dat hier een echte zwakte is wanneer een client of een server überhaupt accepteert om een zwakke coderingssuite te gebruiken.

Standaard staan moderne webbrowsers het gebruik van dergelijke zwakke coderingssuites niet toe.

Diefstal van privésleutel

Als een SSL-verbinding gebruikmaakt van RSA-sleuteluitwisseling, en een aanvaller houdt een kopie van de gegevens bij, en later (mogelijk maanden daarna, mogelijk door alle back-ups op weggegooide harde schijven of banden te inspecteren) krijgt een kopie van de privésleutel, waarna hij kan ontrafelen de handdruk en het decoderen van de gegevens.

Perfect Forward Secrecy gaat over het “later” tegengaan. U krijgt het door de DHE coderingssuites te gebruiken. Met een DHE-coderingssuite is de eigenlijke privésleutel die zou kunnen worden gebruikt om de handdruk te ontrafelen de kortstondige Diffie-Hellman-sleutel, niet de RSA (of DSS) privésleutel van de server.Omdat het kortstondig was, bestond het alleen in RAM en werd het nooit naar de harde schijf geschreven; als zodanig zou het veel veerkrachtiger moeten zijn tegen diefstal.

Dus de les is: probeer in de regel indien mogelijk een DHE-coderingssuite te gebruiken. U moet nog steeds op uw back-ups letten en uw privésleutel niet laten lekken, maar de DHE-suites maken dergelijke lekkage in ieder geval een beetje minder een probleem, vooral als het gebeurt na het einde van de levensduur van de sleutel (dwz het bijbehorende certificaat is geen probleem). langer geldig).

Certificate Woes

De hele certificaatbusiness is een zere plek in SSL.

Technisch gezien is SSL vrij onafhankelijk van X.509. De certificaatketens worden uitgewisseld als ondoorzichtige blobs. Op een gegeven moment moet de client de openbare sleutel van de server gebruiken, maar het staat de client vrij om die sleutel te kennen op een manier die hij nodig acht. In sommige specifieke scenarios waarin SSL kan worden gebruikt, kent de client de server al “s openbare sleutel (hard gecodeerd in de code) en negeert gewoon het certificaat verzonden door de server. Niettemin, in het gebruikelijke geval van HTTPS, doet de client validatie van de certificaatketen van de server zoals beschreven in X.509 ( lees het ten koste van je gezond verstand; je bent gewaarschuwd).

Dit levert een aantal aanvalsvectoren op, bijvoorbeeld:

• Validatie houdt in dat je moet verifiëren dat de certificaten zijn nog steeds geldig op de huidige datum. Hoe weet de clientcomputer de huidige datum? Met zijn interne klok en mogelijk door te praten met NTP-servers (in een vrij onbeschermde manier!). De client kan enkele minuten, uren, dagen of zelfs jaren afwezig zijn (ik heb het gezien), en tot op zekere hoogte zou een krachtige aanvaller het kunnen forceren door met NTP-berichten te spelen. de aanvaller om verouderde certificaten te gebruiken die jaren geleden zijn ingetrokken. Let op een leuk feit: de SSL “client random” en “server random” moeten 28 willekeurige bytes bevatten en de lokale datum en tijd (meer dan 4 bytes) Deze opname van tijd was bedoeld als onderdeel van een oplossing tegen op tijd gebaseerde aanvallen. Ik ben niet op de hoogte van enige implementatie die dit echt controleert.

• Tot ongeveer 2003 werd bij de implementatie van certificaatvalidatie in Internet Explorer / Windows de extensie “Basic Constraints” niet verwerkt. naar behoren. Het netto-effect was dat iedereen met een certificaat van € 100, – als CA kon optreden en “certificaten” kon uitgeven met willekeurig gekozen naam en sleutels.

• X .509 bevat een schadebeperkingsfunctie genaamd intrekking : dit gaat over het publiceren van een lijst met verbannen certificaten, die er cryptografisch goed uitzien, maar niet vertrouwd mogen worden (bijv. Hun privésleutel is gestolen of ze bevatten een foutieve naam). Intrekking werkt alleen voor zover de betrokken partijen (d.w.z. browsers) accepteren om gigantische intrekkingslijsten te downloaden (die meerdere megabytes lang kunnen zijn!) Of om contact op te nemen met OCSP-servers . Moderne browsers doen het nu, maar een beetje met tegenzin, en velen zullen toch accepteren om verbinding te maken als ze niet tijdig informatie over de intrekkingsstatus kunnen verkrijgen (omdat de menselijke gebruiker geen geduld heeft). De algemene situatie verbetert met de jaren, maar vrij langzaam.

• Sommige root-CA heeft in het verleden wat blunders begaan (bijv. Comodo en DigiNotar). Dit resulteerde in de uitgifte van valse certificaten (de naam is www.microsoft.com maar de privésleutel is helemaal niet in handen van Microsoft …). Deze blunders werden ontdekt en de certificaten werden ingetrokken, maar het roept nog steeds een aantal ongemakkelijke vragen op (bijv. Zijn er andere CA die dergelijke problemen hadden maar deze niet onthulden, of, erger nog, ze nooit hebben opgemerkt?).

X.509 is een zeer complexe verzameling algoritmen, technologieën, specificaties en commissies, en het is erg moeilijk om het goed te krijgen. Proberen X.509-certificaten “met de hand” te decoderen in een onbeschermde programmeertaal zoals C is een gemakkelijke manier om bufferoverflows te verkrijgen.

Bleichenbacher-aanvallen

Daniel Bleichenbacher vond in 1998 een mooie aanval tegen RSA. Wanneer u een gegevensbestand met RSA versleutelt (zoals gebeurt voor het ClientKeyExchange -bericht in SSL), moeten de gegevens die moeten worden versleuteld, worden opgevuld om om een byte-reeks te maken met dezelfde lengte als de RSA-modulus. De opvulling bestaat voornamelijk uit willekeurige bytes, maar er is een beetje structuur (met name de eerste twee bytes na opvulling moeten 0x00 0x02 zijn).

Bij het ontsleutelen (op de server dan), moet de opvulling worden gevonden en verwijderd. Het gebeurt zo dat, op dat moment, toen de server decodeerde maar een ongeldige opvulling kreeg (de 0x00 0x02 bytes waren er niet), hij dit rapporteerde met een waarschuwingsbericht (volgens de SSL-specificatie), terwijl een geldige opvulling resulteerde in de server die de schijnbaar gedecodeerde waarde gebruikt en doorgaat met de handshake.

Dit soort dingen staat bekend als een padding-orakel . Het stelt een aanvaller in staat om een willekeurige reeks bytes te verzenden alsof het een gecodeerd pre-mastergeheim is, en te weten of de decodering van die reeks een geldige opvulling zou opleveren of niet. Dat is slechts 1-bit informatie, maar het is voldoende om de privésleutel te herstellen met een paar miljoenen verzoeken (met listig vervaardigde “gecodeerde” strings).

Tijdelijke oplossing: wanneer de decodering resulteert in een ongeldige padding, blijft de server een willekeurig pre-mastergeheim gebruiken. De handshake zal dan later mislukken, met de Finished berichten. Alle huidige implementaties van SSL doen dat.

The Padding Oracle Strikes Back

Een ander gebied waar een padding-orakel werd gevonden, is in de records zelf. Overweeg CBC-versleuteling en HMAC. De gegevens die moeten worden versleuteld, worden eerst MAC-bewerkt en vervolgens wordt het resultaat versleuteld. Bij CBC-versleuteling moeten de te versleutelen gegevens een lengte hebben die een veelvoud is van de blokgrootte (8 bytes voor 3DES, 16 bytes voor AES). Er wordt dus wat opvulling toegepast, met enige structuur.

Op dat moment (de aanval werd ontdekt door Vaudenay in 2002), toen een SSL-implementatie een d record, retourneerde het verschillende waarschuwingsberichten voor deze twee voorwaarden:

• Bij het ontsleutelen werd geen geldige opvulstructuur gevonden.
• Bij het ontsleutelen, er is een geldige padding gevonden, maar de MAC is geverifieerd en deze kwam niet overeen.

Dit is een padding-orakel en dat kan worden gebruikt om bepaalde versleutelde gegevens te herstellen. Het vereist een actieve aanvaller, maar het is niet zo moeilijk. Vaudenay implementeerde het, en het werd uitgebreid naar het geval waarin een gewijzigde SSL-implementatie in beide gevallen hetzelfde waarschuwingsbericht terugstuurde, maar het langer duurde om terug te keren in het tweede geval, omdat het tijd kost om de MAC opnieuw te berekenen (een mooie demonstratie van a timingaanval ).

Omdat mensen nooit leren, was de Microsoft-implementatie van SSL die in ASP.NET werd gebruikt nog steeds niet gepatcht vanaf 2010 (acht jaar later!) toen Rizzo en Duong de Vaudenay-aanval opnieuw implementeerden en een demonstratie bouwden die HTTP-cookies herstelde.

Zie deze pagina voor enkele aanwijzingen. Houd er rekening mee dat als SSL encrypt-then-MAC had gebruikt, dergelijke problemen zouden zijn vermeden (de defecte records zouden zijn geweigerd op MAC-niveau, voordat zelfs overweegt decodering).

BEAST

De BEAST-aanval is opnieuw van Duong en Rizzo, en nogmaals, het is een remake van een oudere aanval (van Philip Rogaway in 2002). Overweeg CBC om een idee te krijgen. In deze werkingsmodus wordt elk gegevensblok eerst XORed met het resultaat van de versleuteling van het vorige blok; en dat is het resultaat van de XOR die is versleuteld. Dit wordt gedaan om de blokken te “randomiseren” en om de lekken te vermijden die worden gevonden met de ECB-modus. Aangezien het eerste blok geen een “vorig” blok, er moet een Initialisatie Vector (IV) zijn, die de rol speelt van het vorige blok voor het eerste blok.

Het blijkt dat als een aanvaller een deel van de te versleutelen gegevens kan controleren, en ook kan voorspellen welke IV zal worden gebruikt, hij de versleutelingsmachine kan veranderen in weer een andere ontsleuteling oracle en gebruik deze om andere versleutelde gegevens te herstellen (die de aanvaller niet kiest). In SSLv3 en TLS 1.0 kan de aanvaller echter kan de IV voor een record voorspellen: het is het laatste blok van het vorige record! De aanvaller moet dus wat gegevens in de stream kunnen verzenden om de doelgegevens te pushen, op een punt waar de implementatie het vorige record heeft gebouwd en verzonden (meestal wanneer 16 kB gegevens zijn verzameld), maar begon niet met het bouwen van de volgende.

TLS 1.1+ is daartegen beschermd omdat in TLS 1.1 (en volgende versies) een willekeurige IV per record wordt gebruikt. Voor SSLv3 en TLS 1.0 is een tijdelijke oplossing het verzenden van records met lengte nul: dat wil zeggen records met een payload van lengte nul – maar met een MAC en opvulling en codering, en de MAC wordt berekend op basis van een geheime sleutel en over de reeks nummer, dus dit speelt de rol van een generator voor willekeurige getallen. Helaas verslikt IE 6.0 zich in records met lengte nul. Andere strategieën hebben betrekking op een 1 / n-1-splitsing (een record van n bytes wordt verzonden als twee records, één met een enkele byte aan payload, de andere met de resterende n-1 ).

Een andere oplossing is om het gebruik van een niet-CBC coderingssuite af te dwingen, indien mogelijk – de server selecteert een op RC4 gebaseerde coderingssuite als er een is in de lijst met coderingssuites die door de klant, zelfs als de klant de voorkeur zou hebben gegeven aan een op CBC gebaseerde coderingssuite. Deze tool kan u vertellen of een bepaalde server zich blijkbaar zo gedraagt.(Opmerking: BEAST is een aanval op de client , maar door een RC4-coderingssuite te selecteren, kan de server een onzorgvuldige client beschermen.)

Zie deze pagina voor enkele aanwijzingen. Hoewel TLS 1.1 uit 2006 stamt, kan de BEAST-aanval de browserverkopers dwingen eindelijk te upgraden.

CRIME

Zoals voor elke Hollywood-franchise, publiceerden Duong en Rizzo in 2012 het vervolg van het vervolg. CRIME maakt gebruik van een lekkage die jaren geleden werd getheoretiseerd, maar die pas levendig werd aangetoond in de demonstratie die ze onlangs publiceerden. CRIME maakt gebruik van compressie, in dezelfde opzet als de BEAST-aanval (aanvaller kan zelf enkele gegevens verzenden in een SSL-verbinding, waar ook interessante doelgegevens zoals een cookie worden verzonden). De aanvaller plaatst globaal gesproken een potentiële waarde voor de doelreeks in zijn gegevens, en als deze overeenkomt, maakt compressie de resulterende records korter. Zie deze vraag voor een (pre-cognitieve) analyse.

CRIME wordt vermeden door helemaal geen compressie op TLS-niveau te gebruiken, wat wel wat browsers nu doen. Internet Explorer en IIS hebben in de eerste plaats nooit compressie op TLS-niveau geïmplementeerd (voor één keer redde slordigheid de dag); Firefox en Chrome hebben het deze zomer geïmplementeerd en gedeactiveerd (ze werden gewaarschuwd door Duong en Rizzo, die behoorlijk verantwoordelijk zijn in hun activiteit).

CRIME laat zien waarom ik schreef, aan het begin van mijn SSL-uitleg :

SSL vervult deze doelen in grote (maar niet absolute) mate.

Inderdaad, versleuteling lekt de lengte van de versleutelde gegevens. Daar is geen goede oplossing voor bekend. En alleen lengte kan veel dingen onthullen. Wanneer we bijvoorbeeld met een netwerkmonitor een SSL-verbinding observeren, kunnen we de “extra handshakes” in de stream zien (omdat de eerste byte van elk record het type gegevens in het record identificeert, en het is niet versleuteld); met de lengte van de records, is het vrij eenvoudig om te zien of de klant een certificaat heeft verstrekt of niet.

Poedel

( bewerken: deze sectie is toegevoegd op 2014-10-15)

De “Poedel” -aanval maakt gebruik van een fout die specifiek is voor SSL 3.0 met CBC-gebaseerde coderingssuites. Het is gebaseerd op een vaak over het hoofd gezien kenmerk van SSL 3.0: de meeste opvulbytes worden genegeerd. In TLS 1.0 is de opvulling (bytes toegevoegd in een record om de lengte compatibel te maken met CBC-codering, die alleen volledige blokken verwerkt) volledig gespecificeerd; alle bytes moeten een specifieke waarde hebben en de ontvanger controleert dat. In SSL 3.0 wordt de inhoud van opvullingsbytes genegeerd, waardoor een aanvaller wijzigingen kan aanbrengen die meestal onopgemerkt blijven. De wijziging heeft alleen invloed op gegevens die niet van toepassing zijn, maar kan worden gebruikt als een decoderingsorakel op een manier die vaag lijkt op BEAST.

Meer details kunnen worden gelezen in dit antwoord .

De toekomst

Mensen leren nooit. Er is veel druk om handige extensies aan SSL toe te voegen om veel redenen die er in het begin altijd goed uitzien, maar extra problemen kunnen veroorzaken.

Denk bijvoorbeeld aan SSL FalseStart . Dit gaat voornamelijk over de client die zijn toepassingsgegevens verzendt direct nadat hij zijn Finished -bericht heeft verzonden (in een volledige handdruk), zonder te wachten op de Finished bericht van de server. Dit vermindert de latentie, wat goed en goed bedoeld is. Het verandert echter de veiligheidssituatie: voordat het Finished -bericht van de server is ontvangen, wordt dit laatste alleen impliciet geauthenticeerd (de klant heeft nog geen bewijs dat de bedoelde server echt betrokken was bij allemaal; het weet gewoon dat wat het ook verzendt, alleen leesbaar zal zijn door de bedoelde server). Dit kan gevolgen hebben; een aanvaller kan bijvoorbeeld de server tot op dat moment emuleren en bijvoorbeeld de client dwingen een op CBC gebaseerde coderingssuite of TLS-compressie te gebruiken. Daarom, als een client FalseStart implementeert, vermindert dit de effectiviteit van beschermingsmaatregelen tegen BEAST en CRIME, zoals anders zou kunnen worden afgedwongen door de server.

(Google heeft FalseStart dit voorjaar, blijkbaar vanwege compatibiliteitsproblemen met sommige servers. Hoe dan ook, de “30% latentiereductie” zag er raar uit, omdat FalseStart alleen enige invloed zou hebben op volledige handshakes, niet op afgekorte handshakes, dus dat doe ik niet ” Ik geloof niet in deze vermeende voordelen, althans niet in die mate.)

Opmerkingen

• De hoeveelheid moeite die je hebt gestoken in het verstrekken van goede informatie via deze site is echt gek en buitengewoon bewonderenswaardig. Zeer gewaardeerd.
• Zie ook tools.ietf.org / html / rfc7457