image

Google verbetert HTTPS-encryptie met forward secrecy

woensdag 23 november 2011, 10:02 door Redactie, 9 reacties

Google heeft een beveiligingsmaatregel aan Gmail, de zoekmachine en andere webapplicaties toegevoegd, die de aanwezige encryptie moet versterken. Sinds vorig jaar ondersteunen Gmail en de zoekmachine HTTPS, die nu met forward secrecy is versterkt. Websites die HTTPS zonder forward secrecy aanbieden, lopen namelijk het risico dat de encryptie in de toekomst wordt gekraakt. Een aanvaller die versleutelde berichten en zoekopdrachten nu onderschept, maar niet kan kraken, kan dit mogelijk wel over tien jaar als computers veel sneller zijn geworden.

Bij forward secrecy worden de privésleutels van een verbinding niet permanent bewaard. Een aanvaller die een enkele sleutel kraakt, kan daarmee niet maanden aan andere verbindingen kraken. Zelfs de beheerder van de server kan niet "retroactief" de HTTPS-sessie ontsleutelen.

Forward secrecy is nu ingeschakeld voor Gmail, SSL Search, Docs en Google+. De zoekgigant heeft daarnaast ook de aanpassingen aan de open source OpenSSL library die dit mogelijk maken vrijgegeven.

Internet Explorer
Chrome, Firefox en Internet Explorer op Windows Vista of nieuwer ondersteunen forward secrecy. In eerste instantie zullen alleen Chrome en Firefox het standaard voor Google diensten gebruiken, omdat IE niet de combinatie van ECDHE en RC4 ondersteunt. De zoekgigant hoopt Microsoft's browser in de toekomst te kunnen ondersteunen.

"We zien graag dat forward secrecy de norm wordt en hopen dat onze uitrol de haalbaarheid van deze visie demonstreert", zegt Adam Langley van het Google Security Team. In Chrome is forward secrecy te herkennen door op het groene slot te klikken. Daar zal vervolgens ECDHE_RSA als sleutelmechanisme worden vermeld.

Reacties (9)
23-11-2011, 15:38 door Rene V
Een aanvaller die versleutelde berichten en zoekopdrachten nu onderschept, maar niet kan kraken, kan dit mogelijk wel over tien jaar als computers veel sneller zijn geworden.

Ja, want dan is het nog steeds relevant. 10 jaar in ICT is nogal wat. ^^
23-11-2011, 15:39 door SirDice
Bij forward secrecy worden de privésleutels van een verbinding niet permanent bewaard. Een aanvaller die een enkele sleutel kraakt, kan daarmee niet maanden aan andere verbindingen kraken. Zelfs de beheerder van de server kan niet "retroactief" de HTTPS-sessie ontsleutelen.
Volgens mij heeft dit niet zo veel zin. Ik heb altijd begrepen van SSL (en dus ook HTTPS) dat er een sessie-sleutel wordt gegenereerd. Deze sessie-sleutel wordt dmv asymetrische encryptie tussen client en server afgesproken/uitgewisseld en is per sessie anders (vandaar ook sessie-sleutel). Met deze sessie-sleutel wordt de rest van het verkeer middels een symetrische encryptie gecodeerd. Ook al heb je die initiele asymetrische sleutels niet, je kunt altijd nog de symetrische sessie-sleutel kraken (desnoods met brute-force). Dit wordt enigszins makkelijker gemaakt omdat een deel van het HTTPS verkeer voorspelbaar is.
23-11-2011, 16:06 door wizzkizz
Door SirDice:
Volgens mij heeft dit niet zo veel zin. Ik heb altijd begrepen van SSL (en dus ook HTTPS) dat er een sessie-sleutel wordt gegenereerd. Deze sessie-sleutel wordt dmv asymetrische encryptie tussen client en server afgesproken/uitgewisseld en is per sessie anders (vandaar ook sessie-sleutel). Met deze sessie-sleutel wordt de rest van het verkeer middels een symetrische encryptie gecodeerd. Ook al heb je die initiele asymetrische sleutels niet, je kunt altijd nog de symetrische sessie-sleutel kraken (desnoods met brute-force). Dit wordt enigszins makkelijker gemaakt omdat een deel van het HTTPS verkeer voorspelbaar is.
Als je het Wikipedia lemma van Perfect Forward Secrecy erbij pakt (https://nl.wikipedia.org/wiki/Perfect_forward_secrecy) dan zie je een hele andere uitleg van dat begrip. Omdat ik lui ben, quote ik een reactie op Tnet waarin het ook in een paar zinnen uitgelegd wordt:
Door djexplo (https://tweakers.net/reacties.dsp?Action=Posting&ParentID=5133927):
Forward secrery, betekend dat je een bepaald sleutel(1) hebt, waarmee je het eerste bericht encrypted, het volgende bericht versleutel je met sleutel(2)=hash(sleutel(1)), het derde bericht met sleutel(3)=hash(hash(sleutel(1))).

Het idee is dan zorgt dat je de hashing formule niet te inverteren valt dus sleutel(1)=inverse_hash(sleutel2) niet mogelijk is, en de functie niet herhalend/periodiek is.
Op het moment dat de aanvaller dan een sleutel te pakken krijgt kan hij alle berichten ontcijferen na deze sleutel maar geen van de berichten daarvoor, vandaar "Forward secrecy"
23-11-2011, 16:31 door SirDice
Door wizzkizz: Als je het Wikipedia lemma van Perfect Forward Secrecy erbij pakt (https://nl.wikipedia.org/wiki/Perfect_forward_secrecy) dan zie je een hele andere uitleg van dat begrip.
Dat geeft iets meer duidelijkheid maar

Alice en Bob zijn met elkaar de session key k overeengekomen. Nu willen ze graag forward secrecy over de door hun verstuurde berichten. Ze kiezen er voor om voor het eerste bericht sleutel k te gebruiken, voor het 2e bericht h(k), voor het ne bericht hn(k). h is een hash functie die aan de volgende eisen voldoet:

Als ik die eerste sessie-sleutel kraak, kan ik, omdat het hashing algoritme bekend is, de tweede, derde en alle volgende zelf uitrekenen. Als ik de tweede sessie-sleutel kraak kan ik de derde uitrekenen etc. Wat ook op tweakers staat:
Op het moment dat de aanvaller dan een sleutel te pakken krijgt kan hij alle berichten ontcijferen na deze sleutel maar geen van de berichten daarvoor, vandaar "Forward secrecy"

Bovendien kan ik nog steeds elke sessie-sleutel afzonderlijk kraken, wat net zo veel moeite kost voor de tweede of derde als voor de eerste. Het enige verschil lijkt dat de sessie-sleutels vaker wisselen maar dat juist dit wisselen voorspelbaar is.
23-11-2011, 17:16 door wizzkizz
Door SirDice:
Bovendien kan ik nog steeds elke sessie-sleutel afzonderlijk kraken, wat net zo veel moeite kost voor de tweede of derde als voor de eerste. Het enige verschil lijkt dat de sessie-sleutels vaker wisselen maar dat juist dit wisselen voorspelbaar is.
Als je 1 sleutel kraakt, kun je inderdaad de daaropvolgende sleutels berekenen. Maar je kunt de berichten die eerder verstuurd zijn niet berekenen, die moet je nog weer afzonderlijk gaan kraken of brute-forcen. In de meest gebruikte situatie hoef je slechts 1 sleutel te kraken/brute-forcen om alle communicatie te ontcijferen. Dus daarin biedt het een voordeel. Maar ik zie ook niet in waarom je niet je effort zou steken in het kraken van de eerste sleutel, dan kun je immers alle opvolgende sleutels ook berekenen en dus ook alle berichten ontcijferen. Ik ben ook zeker geen crypto specialist, maar mogelijk maakt het gebruik van de Elliptic Curve DHE dat ook moeilijker vergeleken met de "standaard" situatie.
23-11-2011, 18:03 door SirDice
Door wizzkizz:
Door SirDice:
Bovendien kan ik nog steeds elke sessie-sleutel afzonderlijk kraken, wat net zo veel moeite kost voor de tweede of derde als voor de eerste. Het enige verschil lijkt dat de sessie-sleutels vaker wisselen maar dat juist dit wisselen voorspelbaar is.
Als je 1 sleutel kraakt, kun je inderdaad de daaropvolgende sleutels berekenen. Maar je kunt de berichten die eerder verstuurd zijn niet berekenen, die moet je nog weer afzonderlijk gaan kraken of brute-forcen. In de meest gebruikte situatie hoef je slechts 1 sleutel te kraken/brute-forcen om alle communicatie te ontcijferen. Dus daarin biedt het een voordeel. Maar ik zie ook niet in waarom je niet je effort zou steken in het kraken van de eerste sleutel, dan kun je immers alle opvolgende sleutels ook berekenen en dus ook alle berichten ontcijferen.
Ja, precies. Dat is exact waar ik ook aan dacht.

Ik ben ook zeker geen crypto specialist, maar mogelijk maakt het gebruik van de Elliptic Curve DHE dat ook moeilijker vergeleken met de "standaard" situatie.
Nu ben ik ook geen crypto guru maar die ECDHE_RSA is volgens mij alleen maar om de asymetrische sleutels van de client en server uit te wisselen. Nadat dat gedaan is wordt er een symetrische sessie-sleutel afgesproken. Wat er vervolgens met de server of client private key gebeurd maakt feitelijk geen bal uit. Het gaat om die sessie-sleutel, als je die kraakt kun je het bericht lezen.
24-11-2011, 04:59 door Dev_Null
Google en encryptie-verbetering....Voelt een beetje aan als een tegenstelling ;-}
24-11-2011, 06:32 door Anoniem
Ongeacht:

Wat dan ook, heb je je best gedaan voor een open & vrij Internet, word het op slot gezet!...

IP bekend bij Redactie.
24-11-2011, 17:23 door Anoniem
Voor de niet-cryptografen, door een wel-cryptograaf:

Bij normaal gebruik wordt een sessie-sleutel afgesproken aan de hand van een key-exchange protocol. Daarin wordt bijvoorbeeld het SSL-certificaat van de server gebruikt, en die server moet daar de bijbehorende geheime sleutel van kennen.

Stel nu dat die geheime sleutel uitlekt (of gekraakt wordt). Niet alleen kan dan iemand zich voordoen als de als die server, maar hij is ook in staat om daarmee alle sessie-sleutels opnieuw te berekenen en daarmee dus oude ssl-verbindingen alsnog in te zien.

Forward secrecy zegt eigenlijk maar één ding: dat wanneer die geheime sleutel uitlekt, dat dan alle oude sessie-sleutels niet meer te berekenen zijn en dat dus alle oude communicatie nog steeds veilig is.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.