Google verbetert HTTPS-encryptie met forward secrecy
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.
Ja, want dan is het nog steeds relevant. 10 jaar in ICT is nogal wat. ^^
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.
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"
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:
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.
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.
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.
Wat dan ook, heb je je best gedaan voor een open & vrij Internet, word het op slot gezet!...
IP bekend bij Redactie.
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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.