Google verbetert beveiligde verbindingen met 'forward secrecy'

Google gaat de versleutelde verbinding van diensten als Gmail, Docs en Google+ standaard voorzien van 'forward secrecy'. Daardoor moet het voor hackers lastiger worden om berichten die zij nu onderscheppen in de toekomst te ontcijferen.

Websites die een https-sessie zonder forward secrecy aanbieden, laten volgens Google de mogelijkheid open dat hackers versleutelde data die ze onderschept hebben, in de toekomst alsnog kraken. Computers zijn dan namelijk veel sneller dan nu, aldus Google. Forward secrecy zou een eventuele kraak moeten voorkomen. Met de techniek heeft het kraken van een enkele privésleutel alleen gevolgen voor het decrypten van de gegevens die met de desbetreffende key versleuteld zijn. Het is onmogelijk om ook eerdere sleutels af te leiden uit de kraak en andere onderschepte data te ontcijferen. Voor forward secrecy is onder andere nodig dat de keys tijdelijk opgeslagen worden en Google gebruikt bij de uitwisseling elliptic curve Diffie-Hellman-RSA. Momenteel ondersteunen Firefox, Internet Explorer en Googles eigen browser Chrome deze laatste functionaliteit, hoewel IE nog niet de combinatie van elliptic curve Diffie-Hellman en RC4 ondersteunt.

Diensten als Gmail, Docs, Google+ en Google Search maken nu standaard gebruik van forward secrecy. De aanpassing volgt na een reeks eerdere beveiligingsmaatregelen van Google. Sinds oktober kunnen onder meer ingelogde gebruikers standaard zoeken op het internet via een versleutelde verbinding. Daarmee moeten man-in-the-middle-aanvallen worden voorkomen, zodat derden geen zoekopdrachten kunnen onderscheppen. Ook werden eerder diensten als Gmail en Docs van standaard-ssl-ondersteuning voorzien.

Reacties (30)

[tweaker2010]

Goede maatregel dit. Maar als ik het goed begrijp wordt het lastiger maar niet onmogelijk?
Vandaar dat er dus geen sprake is van Perfect forward secrecy.

[djexplo]

Het tweakers artikel klopt niet

Forward secrecy zou een eventuele kraak moeten voorkomen. Met de techniek heeft het kraken van een enkele privésleutel alleen gevolgen voor het decrypten van de gegevens die met de desbetreffende key versleuteld zijn.

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"

Een functie maken die niet te inverteren valt is erg simpel. Stel mijn hash functie is
sleutel(2)=mod(sleutel(1),10) , waarbij sleutel(1)=51, deze sleutel kan 5 hele keren gedeeld worden door 10 waarbij je 1 over houd, dus sleutel(2)=1.
Als nu weet sleutel(2)==1 dan kan sleutel(1), 11 maar ook 21 of 1001 zijn geweest, dus er is geen uniek antwoord.

[Reactie gewijzigd door djexplo op 25 juli 2024 21:59]

[roy-t]

Zoals jij het bescrhijft is het absoluut geen forward secrecy. Immers hoef je zo helemaal niets te kraken. Je onderschept hash(sleutel_x) en dan weet je dat de volgende key hash(hash(sleutel_x)) is.

Bij forward secrecy draait het erom dat het even duurt om een sleutel te achterhalen. Stel het duurt met een super computer 30 minuten om een sleutel te kraken dan zou je na 30 minuten mee kunnen gaan luisteren. Echter als de sleutel die overeengekomen is daarna gebruikt is om via Diffie-Hellman weer een nieuwe sleutel te bedenken kun je zo nooit real-time het gesprek afluisteren/verstoren alleen achteraf kun je pakketen decoderen.

Nog even om verwarring te voorkomen: door de sleutel te kraken kun je niet gewoon in een pakketje lezen wat de volgende afgesproken sleutel is enzovoorts. Diffie-Hellman werkt zo dat partij A en B beide een eigen geheim hebben, ze communicatie dat eigen geheim nooit, ze versturen alleen informatie over het geheim. Met de informatie over het geheim van A en B kun je samen niets maar met je eigen geheim en met de informatie over de ander zijn geheim kun je samen dezelfde key berekenen en die gebruiken.

[robvanwijk]

Een niet-inverteerbare functie die bruikbaar is binnen de cryptografie is juist wel erg lastig.
In in specifieke geval (waarbij de uitvoer van de ene iteratie de invoer van de volgende is, een veel voorkomende situatie in de cryptografie trouwens) van jouw mod-10 voorbeeld was sleutel(1) namelijk altijd 1; het was immers zelf ook de uitkomst van een mod-10 berekening (je voorbeeld met sleutel(1) = 51 kan daarom ook niet).

Overigens, hoewel je een (mijns inziens) belangrijk detail over het hoofd ziet is je uitleg voor de rest prima.

[Thralas]

Echter is het in het gegeven voorbeeld zo dat een compromise van een van de sleutels een passieve(!) attacker ook alle toekomstige keys kan berekenen.

In SSL wordt de forward secrecy-property bewerkstelligt door middel van ephemeral Diffie-Hellman keys. Dit kent niet bovengenoemde zwakheid.

Het aanbieden van forward secrecy ansich is niet nieuw (dmv. DHE als key exchange algorithm), waar Google innoveert is het toepassen van de elliptic curve-variant, ECDHE - traditioneel DHE was wegens de (relatief) slechtere performance blijkbaar niet bruikbaar.

Bovenstaande kun je (oa. met OpenSSL) verifieren. Het viel mij op dat het gebruik van DH erg wisselt. Tweakers biedt het bijvoorbeeld wel aan (Cipher is DHE-RSA-AES256-SHA), maar ING weer niet. Ongetwijfeld vanwege dezelfde redenen als Google - mogelijk kunnen ze in de toekomst wel uit te voeten met ECDHE...

[delirium]

Bedankt voor de goede uitleg, dit zouden ze wat mij betreft in het artikel moeten opnemen!

[dispie]

Het is echt tijd dat de VS de federale wetten her zien en encryptie boven de 128 bit gaat toe staan want het blijft 128 bit encryptie dus niet erg veilig.

We moeten het hele internet maar eens naar 256 bit encryptie opwaarderen uit securitie oogpunt zeker met de hoeveelheid financiele transacties die er tegenwoordig over plaats vinden is dat geen overbodige luxen.

[CyBeR]

Door kennis van zaken noch kunde in de Nederlandse taal gehinderd schreef dispie:

Het is echt tijd dat de VS de federale wetten her zien en encryptie boven de 128 bit gaat toe staan want het blijft 128 bit encryptie dus niet erg veilig.

We moeten het hele internet maar eens naar 256 bit encryptie opwaarderen uit securitie oogpunt zeker met de hoeveelheid financiele transacties die er tegenwoordig over plaats vinden is dat geen overbodige luxen.

Ten eerste limiteert de VS al jaren niet meer de keylengte van geëxporteerde crypto, met uitzondering van export naar "schurkenstaten" en terroristische organisaties. The usual zeg maar. Er zijn dus nog wel wat regeltjes aan verbonden, maar in principe wordt export niet meer in de weg gezeten.

Vervolgens, 128-bit AES is vandaag nog net zo veilig als een paar jaar geleden. Over 20 jaar mischien niet meer, maar vandaag nog wel. En zelfs al was dat niet zo, het complete internet gebruikt al een tijdje AES-256 voor z'n TLS-benodigdheden. Kijk maar 's welke crypto je gebruikt als je met https naar t.net surft.

[Anoniem: 126717]

Zouden ze dit ook nog gaan aanpassen?

Website: mail.google.com
Owner: This web site does not supply ownership information.

Daar heb ik al eens vragen over gekregen nadat ik mensen op het slotje / icoon had gewezen.

[roy-t]

Ik heb het even getest en dat is erg raar inderdaad. Bij https://twitter.com krijg ik (in Opera) netjes een groene sleutel en zie ik de owner alsook andere informatie. Terwijl ik bij https://mail.google.com een gele sleutel zie zonder owner informatie . Hoe kan een bedrijf zo groot als google nu een 'minder goed' certificaat hebben?

[freaky]

En hier is de aloude ellende. Kun je me uitleggen wat er minder goed is (het staat hier boven al... maar veel gebruikers hebben zoiets van groen is beter dan geel zonder te weten waarom)?

Voor de encryptie zelf maakt het geen bal uit nl. Sterker nog, een self-signed certificate is puur naar encryptie gekeken net zo goed als EV. Het is alleen moeilijker te valideren of het het correcte certificaat is en niet eentje van iemand die een MITM aanval doet of DNS poisoning naar z'n eigen server bijv.

[CyBeR]

Hoe kan een bedrijf zo groot als google nu een 'minder goed' certificaat hebben?

Om te beginnen: niet.

EV-certificaten zijn exact even goed als normale certificaten, alleen staat er een extra veldje in: "ik ben een EV-certificaat".

Technisch verder identiek.

[Anoniem: 319420]

Bij mij verschijnt wel een soortgelijk venster als de screenshot hierboven?

[Moartn]

Daar staat toch ook niet bij wie de eigenaar van de site is? Met een wat duurder certificaat komt daar "Google, Inc." bij te staan.

[edit]
Voor de encryptie opzich maakt dat niets uit natuurlijk. Het is puur een extra brokje informatie waarmee je net weer wat extra zekerheid kunt bieden.

[Reactie gewijzigd door Moartn op 25 juli 2024 21:59]

[Goderic]

Als je op "certificate information" drukt komt er wel degelijk "Google Inc" te staan.

[Woy]

Google gebruikt echter geen extended validation certificaat. Op zich zegt dat ook niet zo heel veel, behalve dat de gegevens van het bedrijf een keer extra bekeken zijn ( Volgens de uitgevende partij in ieder geval ) voordat het certificaat uitgegeven is.

[Anoniem: 29149]

Het versleutelen van een EV certificaat kost en paar procent meer processorkracht, want de sleutel is langer. Bij een bedrijf met de omvang van Google heb je het dan over vele miljoen die je bespaart door niet EV te gebruiken.

[Moartn]

Klopt, maar het staat er niet direct. Vergelijk het eens met de informatie die je direct ziet als je naar https://twitter.com/ gaat, en je ziet het verschil.

Nogmaals: voor de encryptie zelf maakt het niet uit. Het geeft de gebruiker alleen extra zekerheid dat je echt met een site Google te maken hebt. Nu staat er alleen dat de verbinding beveiligd is, maar niet met wie je die beveiligde verbinding hebt opgebouwd.

[freaky]

Nou dat valt ook nog te bezien. EV certificaten mogen alleen uitgedeeld worden door een aantal authorities (andere kunnen ze uiteraard wel aanmaken, maar je browser accepteert dat simpelweg niet) en ze moeten inderdaad controleren of de gegevens kloppen (o.a. KvK, adres e.d.).

Echter is er de laatste tijd wel de nodige ellende geweest met CA's en als ik kijk hoeveel er in m'n browser standaard zitten wordt je daar absoluut niet gelukkig van. De gehele betrouwbaarheid van CA's staat op losse schroeven IMHO en ik zie dan ook meer in DNSSec. Zie bijv. hier: http://ha.ckers.org/blog/...-ssls-transport-security/

Ter verduidelijking, je kunt je certificaat dus gewoon publiceren (het publieke deel uiteraard) in DNSSec, waarbij je dus ook meteen zeker bent dat het bij het domein hoort. Daarbij, als DNS server X gehacked wordt heeft dat waarschijnlijk veel minder gevolgen dan als de CA van bijv. Verisign het onderspit delft. De meeste DNS servers hebben een veel kleiner bereik.

[Cloud]

Als enige browsers ondersteunen momenteel Firefox, Internet Explorer en Googles eigen browser Chrome de functionaliteit.

'Enige'? Eigenlijk vind ik dat nogal wat. Firefox, IE en Chrome samen hebben toch een aanzienlijk marktaandeel zou ik zo zeggen. Eigenlijk kende ik deze techniek helemaal niet, maar als het al ingebakken in meerdere browsers zit dan bestaat het blijkbaar al even.

Goed om te horen dat het web nog altijd veiliger gemaakt wordt

[Reactie gewijzigd door Cloud op 25 juli 2024 21:59]

[kramerty88]

Wat ik me meer afvraag is:

Google gaat onder andere de keys tijdelijk opslaan voor forward secrecy. Als enige browsers ondersteunen momenteel Firefox, Internet Explorer en Googles eigen browser Chrome de functionaliteit.

Diensten als Gmail, Docs, Google+ en Google Search maken nu standaard gebruik van forward secrecy.

Standaard, dus geen andere optie meer? Betekend dit dat Opera en Safari nu geen G-Diensten meer kunnen gebruiken?

Ik heb zelf geen Opera of Safari, zou iemand dit kunnen verifiëren? Zou namelijk een rare stap zijn door deze buitenspel te zetten.

[Moartn]

Denk je nou serieus dat dat het geval is? Natuurlijk niet. In de handshake-fase zal ongetwijfeld bepaald kunnen worden of zowel server als client die forward secrecy ondersteunen. Is dat niet het geval, dan wordt er gewoon "ouderwets" SSL gebruikt.

[bartvb]

Bij het opzetten van een SSL verbinding vindt er eerst een onderhandeling plaats tussen jouw browser en de server. Jou browser meldt welke standaarden/ciphers hij aankan, server kijkt wat de grootste gemene deler is. Als je browser niet aan forward security doet dan wordt automatisch teruggevallen op een optie die net iets minder veilig is.

[Moartn]

Ik wou net zeggen. Met de browsers die daar opgenoemd worden kom je al snel op 80% van de markt. Eigenlijk vallen alleen Opera, Safari en waarschijnlijk oude versies van browsers erbuiten.

[dvz89]

Goed nieuws! Al maak ik me toch nog zorgen met tools zoals deze in omloop...

http://img.photobucket.co...orscissors/Uplink/310.png

[roy-t]

Dit soort tools maken niets uit. Zolang er geen short-circuit aanval bestaat kun je altijd door brute-force alles proberen in waarschijnlijk O(n/2) tijd de key berekenen. Het gaat erom dat bepaalde beveiliging zijn geadverteerde veiligheid haalt. Bij een 8 bits key verwacht je dat een gebruiker 255/2 keys moet proberen om achter de key te komen. Als dit zo is dan is de beveiliging 'veilig'. Natuurlijk houd je er wel rekening mee hoe snel iemand alle keys kan genereren en pas je daar de keysize op aan.

[dvz89]

Nou ik weet zeker dat een Trinity gateway met 8x120GHz en 128Gq er gehakt van maakt!

[roy-t]

Gehakt van wat? Mijn oude PC maakt gehad van RSA mit het maar een 32 bits key gebruikt toch is het tot nu toe een veilig algoritme gebleken maar dat komt ook omdat mensen tegenwoordig 2048 bits gebruiken voor hun keys, daar maakt nu niets en over 5 jaar ook nog niets gehakt van maar over 10 jaar misschien weer wel.

Beveiliging is altijd een kwestie van bedenken hoeveel moeite er gedaan moet worden. Met oneindig aantal tijd is geen enkele manier veilig. Maar 2048 bits, dus 2^2048 verschillende keys proberen kan waarschijnlijk zelfs met een botnet of supercomputer de komende tijd niet binnen een jaar.

Sowieso zegt het aantal cores en Ghz niet zoveel, het gaat puur om het aantal keys per seconden wat geprobeerd kan worden, bij een veilig protocol is er immers geen short-circuit attack.

[koter84]

hmm.. ik heb de tool even opgezocht, en het krijgt sterke reviews.. Ik zou maar uitkijken op internet tegenwoordig...

"A stroke of genius...a must for all conspiracy fiends"
PC Gamer – 80%

"A true original...paranoia has never been so much fun"
PC Format – 81%

"Deeply, deeply, deeply compulsive...try it"
Games Master - 80%

het SPEL heet: "Uplink Hacker Elite"
ik heb een aantal van dat soort "hack" spelletjes gedaan, maar dat is wel van het niveau van:
- ow-nee, de verbinding is versleuteld..
- klik op de decrypt-knop om de versleuteling op te heffen...
- gelukt! pas op, je cpu-load loopt op, je moet snel de bestanden uit de /data/secret/ map downloaden...
- voer het commando clean-logs uit voor je de verbinding verbreekt anders ben je terug te vinden..

Het is wel grappig, maar daarmee leer je niet hacken..

[PaulC]

Is dit ook geldig vanop Android phones waar nog 2.2 op draait ?
(dacht dat vanaf 2.3.x er iets met de security was veranderd ?)