Google maakt clientside-encryptie in Gmail voor zakelijke gebruikers beschikbaar

Google heeft de eerder aangekondigde clientsideversleuteling in Gmail algemeen beschikbaar gemaakt voor Workspace en Education-gebruikers. Met die encryptie worden berichten versleuteld voordat ze de servers van Google bereiken.

Google schrijft dat het de client side encryption of CSE algemeen beschikbaar heeft gemaakt voor Gmail-gebruikers binnen Workspace Enterprise Plus en binnen de onderwijspakketten Education Standard en Education Plus. Met CSE worden de body en bijlagen van e-mails versleuteld, al blijven headers nog steeds onversleuteld. Dat geldt alleen clientside. De e-mails zijn door Google en andere externe partijen niet te onderscheppen, maar een organisatie kan als dat nodig is wel de decryptiesleutels achterhalen om berichten te ontsleutelen. Dat is binnen bedrijven bijvoorbeeld vaak nodig vanuit compliance-eisen.

Beheerders van een Workspace- of Education-pakket kunnen instellen wanneer gebruikers de encryptie aan of uit kunnen zetten. Gebruikers kunnen dat dan zelf doen in Gmail, waar een aparte knop voor bestaat. Het is daarnaast ook nog mogelijk om 'additionele encryptie' in te schakelen. In dat geval dwingt een verzender af dat een ontvanger eerst moet inloggen om een bericht te lezen, bijvoorbeeld als die ontvanger binnen dezelfde identity management-policy's zit. Standaard staat encryptie overigens uit.

Google kondigde de CSE-functionaliteit in december al aan als bèta, maar nu is die er definitief. Of een soortgelijke functie er ooit komt voor standaard Gmail-gebruikers is niet bekend.

Reacties (19)

[bvgastel]

En de software (JavaScript/WASM) om de mails te ontsleutelen komt van de webserver van Google... Wordt die gehackt, dan kan een aanvaller nog steeds de mail meelezen (want een aangepaste JavaScript die een kopie opstuurt is te doen).

Jammer dat browsers niet ondersteunen dat alleen JavaScript die offline getekend is (door key in DNSsec bv) uitgevoerd kan worden. Dan is in ieder geval het aanpassen van de uitgeleverde software (JavaScript) niet meer mogelijk.

[faim]

Voor Javascript is er Subresource Integrity wat het onmogelijk maakt deze bestanden te manipuleren/wijzigen.

[Xantis]

En waar wordt die integrity hash gedefinieerd? Volgens mij in de html, die ook geserveerd wordt door Google's webserver

[bvgastel]

Zoals @Xantis al zei, die wordt in de HTML gedefinieerd. Die subresource integrity hashes zijn handig voor externe bronnen, maar voor wat ik beschreef gaat het om software/javascript van de oorspronkelijke webserver zelf...

[faim]

Als je dit dus goed implementeert staan je CDN files gescheiden van je HTML files, wordt de CDN gemanipuleerd zal dit niet werken en andersom ook niet. Worden beide gehackt dan heb je wel wat grotere problemen dan JS files die aangepast worden.

[Hatsjoe]

CDN files? Ik neem aan dat je gewoon statische assets bedoelt zoals JS, CSS, plaatjes etc...? Een CDN serveert namelijk zowel de statische content als de HTML, en cachet vaak ook beide.

Ik denk dat het punt dat hierboven in de thread gemaakt wordt is dat je nu maar 1 plek hoeft te hacken om de data te kunnen ontsleutelen. Als de integrity hash extern gedefinieerd staat, zoals in DNS, dan moet je al 2 plekken hacken om als aanvaller data te kunnen ontsleutelen. Beveiliging gaat altijd in lagen, en 2 lagen zijn beter als 1.

[bvgastel]

Dit is geen oplossing: het is bij inbraak webserver makkelijk om naar ander bestand+integrity hash te wijzigen. Dat valt niet in de browser te detecteren: er is geen policy die uit een andere bron komt die gebruikt kan worden om te controleren.

[faim]

Je hebt het telkens over één webserver, waarom denk je dat de html bestanden en static assets van dezelfde server zouden worden geserveerd?

[bvgastel]

Dat is geen nuttig onderscheid: je wilt juist beter grip op het niet statische gedeelte. Dat is meestal de hoofdwebserver (niet op CDN, etc). Die bepaalt welke andere resources er ingeladen worden. En dat is dan de zwakste schakel.

Hoe dan ook blijft er dan altijd 1 webserver over waar je een aanval op kan doen, en eigen injectie kan doen van script/resources/etc.

[DJMaze]

Over wat voor encryptie hebben we het hier eigenlijk?
Meestal is het PGP of S/MIME namelijk.

Mailvelope werkt in gmail op het web, maar je kan natuurlijk met je eigen mail client (web of niet) prima berichten versleutelen.
Dat het bedrijf waar je werkt ze wil ontsleutelen is dan helemaal niet mogelijk.
En anders kan je gewoon net als vroeger je belangrijke tekst verstoppen/encrypten in de meta data van een jpeg.

[telenut]

bij mij op het werk kan ik mijn mails niet encrypten alvast...
En als ik niet wil de de werkgever de inhoud kan zien mail ik gewoon via gmail. daar heeft die geen toegang toe :-)

[honey]

Gebruiken van prive e-mail voor je werk is niet overal toegestaan. Ik zou dat eens navragen bij jullie ICT.

[telenut]

ik bedoel uiteraard als ik privé wil mailen, voor zaken die niet met het werk te maken hebben :-)

[eamelink]

Google's CSE is op basis van S/MIME

[!GN!T!ON]

En anders kan je gewoon net als vroeger je belangrijke tekst verstoppen/encrypten in de meta data van een jpeg.

Volgens mij heet dat Steganography i.p.v. encryptie. Kan mij herrineren dat ik heel vroeger als jongkje een programma had die dingen kon verstoppen in afbeeldingen, was leuk speelgoed

[Sando]

Voordat ik volledig overstapte op ProtonMail (Mail Plus) gebruikte ik ook al Gmail (de "gewone" versie) met versleuteling met behulp van FlowCrypt. Een andere manier om Gmail te versleutelen is met Mailvelope.

Dat werkt uiteraard alleen als de verzender of ontvanger meewerkt, en in mijn cirkel is dat ongeveer een kwart van de mensen, wat best veel is.

Hoewel vooral buitenlandse bedrijven het ondersteunen, en ik geen enkele Nederlandse bank ken waar ik mijn publieke sleutel kan uploaden, is FlowCrypt toch mede-ontwikkeld door het Duitse Bundesamt für Sicherheit in der Informationstechnik (BSI). En de ontwikkeling van OpenPGP.js, waar vele extensies en webmails gebruik van maken, is van 2014 tot 2020 door de EU medegefinancierd.

Ik zou toch echt graag de volgende stap willen zien: Overheidsdiensten en verzekeringen moeten verplicht public keys accepteren en je voortaan versleutelde bijlagen opsturen, in plaats van dat je steeds een bericht krijgt die je zelf bij een berichtenbox moet gaan "ophalen".

[Reactie gewijzigd door Sando op 22 juli 2024 18:00]

[junkchaser]

Hoeveel encryptie ze ook inbouwen, ik vertrouw geen enkele grote speler meer. AI is de nieuwe strijd op de wereldmarkt en om deze te voeden hebben ze data nodig. 1+1=2...

[bilkin2005]

Ik speel even advocaat van de duivel; wat als de data geindexeerd wordt, vlak voor de encryptie? Dan hebben ze die data alsnog?!

[Sando]

Dat zou kunnen. Een beetje zoals Google FLoC Topics API:

To figure out your interests (...) a lightweight machine learning algorithm in the browser will take over and provide an estimated topic