Google komt met pgp-plug-in voor Chrome

Google heeft een previewversie vrijgegeven voor een Chrome-plug-in die gebruikers versleuteld laat communiceren. De extensie maakt gebruik van pgp, maar is volgens Google nog niet geschikt voor het grote publiek.

De extensie zal later in de Chrome Web Store worden gepubliceerd, maar op dit moment nodigt Google enkel onderzoekers uit om de broncode te inspecteren op bugs. Alleen de broncode is vrijgegeven; wie hem wil gebruiken, moet de extensie dus zelf compileren. Het is onduidelijk of de extensie slechts in combinatie met Gmail werkt, of ook in combinatie met andere communicatiediensten.

De extensie heeft sleutels met elliptic curve-cryptografie als standaard; vanuit de extensie kunnen alleen ec-keypairs worden aangemaakt. Dat terwijl rsa-sleutels op dit moment nog de standaard zijn en ec-sleutels nog niet door alle pgp-implementaties worden ondersteund. Wel kunnen gebruikers bestaande rsa-sleutels importeren. Verder maakt de extensie gebruik van JavaScript voor het versleutelen van berichten.

Tegelijkertijd heeft Google statistieken vrijgegeven waaruit blijkt dat Google zelf 69 procent van de berichten versleutelt die het naar andere mailservers verstuurt. Bij binnenkomende berichten op Gmail-adressen is dat 48 procent. Google heeft de nieuwe statistieken opgenomen in zijn transparantierapport. Mails vanaf Hotmail-adressen zijn in meer dan de helft van de gevallen versleuteld; in het geval van Twitter is 99,9 procent versleuteld. Mails aan abonnees van de Amerikaanse provider Comcast zijn juist in minder dan 1 procent van de gevallen versleuteld.

Het gaat in het transparantierapport om de verbindingen tussen mailservers. Die kunnen met ssl/tls beveiligd zijn, zodat het bijvoorbeeld voor een inlichtingendienst niet mogelijk is om op grote schaal alle inkomende en uitgaande berichten te vergaren in zonder veel moeite in te zien. Beide mailservers moeten echter ondersteuning voor ssl/tls hebben om de versleuteling mogelijk te maken.

Reacties (48)

[geertdo]

Wat een beetje vreemd overkomt is de 50% (inbound) dan wel 90% (outbound) van de Microsoft infrastructuur (outlook.com/hotmail). Het is niet helemaal duidelijk hoe lang ze al SMTP TLS ondersteunen. Nog niet zo lang in ieder geval, dus dat kan een verklaring zijn.

Dit is wat outlook.com momenteel zegt (via mxtoolbox.com SMTP test)

SMTP Reverse Banner Check OK - 207.46.8.167 resolves to bay0-mc5-f.bay0.hotmail.com
SMTP Reverse DNS Mismatch OK - Reverse DNS matches SMTP Banner
SMTP TLS OK - Supports TLS.
SMTP Connection Time 0.858 seconds - Good on Connection time
SMTP Open Relay OK - Not an open relay.
SMTP Transaction Time 3.229 seconds - Good on Transaction Time

Het zou natuurlijk kunnen zijn dat Google nog even een veeg naar Microsoft uithaalt, nu het nog kan Meten is weten, over 30 dagen maar eens weer kijken. Dan moet alle communicatie tussen GMail en Outlook.com/hotmail eigenlijk 100% versleuteld zijn.

[Reactie gewijzigd door geertdo op 23 juli 2024 19:14]

[Miki]

Als je het laatste boek van Glenn Greenwald leest maakt deze versleuteling niks uit. Microsoft heeft ondanks volledige versleuteling in Outlook.com als nog een backdoor ingebouwd zodat de NSA er nog bij kan. Naar alle waarschijnlijkheid zal Google dit ook hebben moeten doen conform de FISA. Dus dit komt bij mij een beetje over als het iets mooier maken dan het is.
Ik heb het boek nog niet uit maar PGP is veel betere methode als je je mails niet wilt laten lezen door anderen.

Ps. Boek is dus een aanrader

http://www.lebowskipublis...afluisterstaat-T2946.html

[Reactie gewijzigd door Miki op 23 juli 2024 19:14]

[vide]

Tja, je e-mailprovider kan natuurlijk altijd aan je mails en de metadata. Als je PGP gebruikt, dan is enkel de metadata (zender en ontvanger, onderwerp, nog andere headers) beschikbaar.

Die kunnen dus steeds met rechterlijk bevel opgevorderd worden (en vermits er in een aantal geval gag orders zijn, mogen ze je daar niet over inlichten).

TLS zorgt er inderdaad enkel maar voor dat massa afluistering van het internet verkeer niet ineens alle aankomende en vertrekkende mails leesbaar zijn. Het enige wat je dan kan zien is dat bepaalde mailservers met elkaar praten.

Zeker als het er Diffie-Hellman key exchange is (da's DH in de naam van het gebruikte algoritme), wordt het lastig om alles zomaar binnen te halen, vermits zelfs kennis van de private sleutel je dan niet toestaat om iets zomaar te decrypteren.

[Verwijderd]

vermits betekent omdat.

[Blaise]

Het maakt wél een verschil. Zonder versleuteling kunnen ze waarschijnlijk alle emails onderscheppen door massaal internetverkeer af te tappen. Met TLS versleuteling kunnen ze alleen toegang krijgen tot de emails van een individu, na toegang te hebben geëist bij Microsoft, daarvoor hebben ze een rechterlijk bevel nodig (ook al is dat een wassen neus). Als een bericht is versleuteld met PGP kunnen ze alleen de headers lezen, niet de inhoud. Tenzij ze achter de sleutel kunnen komen door te hacken of backdoors te plaatsen.

[Reactie gewijzigd door Blaise op 23 juli 2024 19:14]

[Miki]

Nee het is nog erger, ze hebben geen toestemming nodig. Microsoft heeft speciaal een omweg gemaakt zodat de veiligheidsdiensten er ten alle tijden bij kunnen ongeacht gebruik van TLS/SSL.

Bij deze de bewuste pasage uit het boek en bijbehorende mail:
http://www.dailydot.com/p...a-fbi-outlook-encryption/

Huh waarom word ik hier zo gedownmod Ik breng alleen maar een boodschap...

[Reactie gewijzigd door Miki op 23 juli 2024 19:14]

[Digihelp ®]

Wellicht dat overheden nog steeds een omweg hebben, maar in ieder geval kan niet iedereen die toegang heeft tot een van de servers tussen zender en ontvanger, of publieke hotspots etc, alles zonder inspanning meelezen. Dus in mijn ogen zeker een verbetering.

[i-chat]

en dan nog, je kunt ook gewoon zelf client side versleutelde documenten maken en die als bijlage toevoegen, dan kan google zoveel backdoors aanbieden als ze wil maar kan men er nog niets mee...

[batjes]

1 claimt dat Microsoft de omweg erin gezet heeft. En op dezelfde pagina claimen er 2 dat er nooit zo'n omweg in gezeten heeft en dat alles via de gerechtelijke weg gegaan is.

Wat een domme bron om aan te halen.

[Reactie gewijzigd door batjes op 23 juli 2024 19:14]

[Matthijs8]

Outlook.com gebruikt geen volledige versleuteling. De verbinding tussen Outlook en jouw computer is versleuteld, en als de dienst van diegene met wie je correspondeert STARTTLS ondersteund, dan is ook de verbinding tussen zijn/haar server en Outlook versleuteld. De email zelf is niet versleuteld, dat is wat PGP doet. Als PGP goed is geïmplementeerd kan je emailprovider de mailtjes niet lezen, en de NSA dus ook niet. Die zullen dan gericht moeten gaan hacken om private keys te bemachtingen van het apparaat van de 'verdachte.' Zo wordt massa surveillance een stuk moeilijker.

[Verwijderd]

Klopt, de oude PGP van jaren geleden was door de NSA van een achterdeur voorzien, daarna heeft me de originele PGP afgezworen in Europa en is men een PGP gaan ontwikkelen die de achterdeur niet had, omdat het geen Amerikaans produkt meer was maar Europees was die PGP clean en kon de NSA er niets mee doen.

[ThinkPad]

Jammer dat er geen Nederlandse providers tussen staan zoals Ziggo, XS4All, Telfort, Tele2, KPN etc. Was wel benieuwd hoe die de zaken voor elkaar hebben.

Bij Ziggo kun je namelijk SSL/TLS gebruiken (al zullen veel POP3 gebruikers dat niet hebben ingesteld uit gemakszucht). Nu met IMAP bij Ziggo is het volgens mij verplicht.

[Reactie gewijzigd door ThinkPad op 23 juli 2024 19:14]

[geertdo]

Was wel benieuwd hoe die de zaken voor elkaar hebben.

kpnmail.nl - Warning - Does not support TLS.
ziggo.nl - Warning - Does not support TLS.
xs4all - OK - Supports TLS
upc.nl - OK - Supports TLS
telfort.nl - Warning - Does not support TLS.
tele2.nl - OK - Supports TLS.

Bij Ziggo kun je namelijk SSL/TLS gebruiken (al zullen veel POP3 gebruikers dat niet hebben ingesteld uit gemakszucht). Nu met IMAP bij Ziggo is het volgens mij verplicht

Het gaat vooral om het traject nádat je het verzonden bericht hebt afgeleverd bij jouw provider.

[ThinkPad]

Dank

[New Yorker]

Misschien moeten ze die providers bekend maken zodat we kunnen overstappen.

[Twilkie]

Je kan op hun website je provider zoeken: http://www.google.com/tra...rt/saferemail/#region=001

Mijn provider (Telenet België) verstuurd 0% versleuteld.

[Ytrog]

Bevat deze extensie een eigen PGP implementatie of werkt die samen met reeds geïnstalleerde pakketen zoals gpg/gpg4win?

[Verwijderd]

Als ik het artikel goed begrijp implementeert de plugin zelf PGP. Anders zou het wel raar zijn dat je alleen ec-keypairs kan genereren, terwijl rsa-sleutels op dit moment redelijk standaard zijn. Als het gebruik maakt van de bestaande pakketten, dan zou je verwachten dat het alle functionaliteit van die pakketten ook ondersteund.

[Ytrog]

Dat hoeft natuurlijk niet zo te zijn als je die standaard pakketten wel gebruikt maar je in de interface die opties niet geeft

[Stevie-P]

End-To-End generates Elliptic Curve-based keys, so they're only supported in GnuPG 2.1 and later, as well as Symantec’s PGP software, but not in GnuPG 1.x or 2.0. We recommend that you either generate a key that you will use with the extension from now on, or generate a non-EC key in other OpenPGP software and import that.
Please note that EC support was added to GnuPG 2.1 beta in 2010, but it hasn’t been released as a stable version yet. To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it, or build GnuPG 2.1 yourself.

Het werkt met andere pakketten, maar voor compatibiliteit zal je handmatig je sleutel moeten toevoegen.

[Peatsmoke]

Ergens aan het begin van dit millenium heb ik ooit eens een cursus gevolgd die weinig met PGP te maken had, maar wel met het veilig versturen en versleutelen van bestanden.
Toen wisten de mensen die de cursus gaven al te vertellen dat PGP een backdoor voor de NSA zou hebben. Ervan uitgaande dat ik daar geen onzin geleerd heb, blijf ik daar toch mijn twijfels bij houden.

Voor prive-doeleinden, maakt dat (voor mij persoonlijk) weinig uit, maar voor zakelijke doeleinden hou ik daar wel rekening mee.

[Verwijderd]

Ondanks het feit dat de source code van PGP gewoon ingezien kan worden blijft dit gerucht maar de ronde doen. Ik denk dat het gerucht een slimme zet is van de NSA om PGP al op voorhand te torpederen. Als je de code niet gemakkelijk kan kraken, kraak dan de populariteit af, zodat niemand het wil gebruiken.

[Fawn]

Ook wel FUD genoemd, een reële optie inderdaad om zo'n technologie 'klein' te houden.

[Matthijs8]

Inderdaad, en ik heb het idee dat het ook mogelijk om de software PGP gaat, niet om het protocol. Ik zou adviseren om een opensource alternatief als GnuPG te gebruiken.

[mxcreep]

Ligt wel aan de gebruikte algoritmes voor het genereren van keys. Als die lek zijn is PGP uiteraard ook lek, maar SSL ook.

[FabianNL]

Mails vanaf Hotmail-adressen zijn in meer dan de helft van de gevallen versleuteld

Kan iemand uitleggen waarom dit niet 100% is? Oftewel, als het afhangt of de server het wel of niet ondersteunt, zou je toch verwachten dat alle Gmails het wél of niet ondersteunen, evenals Hotmail? Oftewel, alle mail wordt of wel verleuteld, of helemaal niks.
Nu zijn er blijkbaar bepaalde servers van Hotmail het niet ondersteunen, en andere wel. Lijkt me een rare keuze namelijk...

[Reactie gewijzigd door FabianNL op 23 juli 2024 19:14]

[geertdo]

Ik denk dat het komt omdat outlook.com nog maar pas SMTP TLS ondersteunt en dat de meting van 30 dagen daarom onvolledig is.

[eborn]

Of Microsoft kan delen van zijn server cluster bijgewerkt hebben, terwijl andere delen later volgen. Eventueel om te voorkomen dat onvoorziene problemen meteen je hele cluster treffen.

[Verwijderd]

Een plug-in in Chrome beantwoordt in elk geval mijn zorg waar de private sleutel terecht komt. Ik wil dat niet ergens in de cloud hebben waar zomaar iemand erbij kan.

Ik hoop ook dat dit een paar Google haters geruststelt, die dit initiatief direct al af serveerden als een nieuwe methode om informatie van de gebruiker vast te leggen en misbruiken.

Het is me niet duidelijk of het bij ec keypairs blijft, of dat in een later stadium (liefst voor definitieve release) ook rsa keypairs toe worden gevoegd.

En ik ben natuurlijk ook erg benieuwd wat Mozilla, Opera, Apple en Microsoft hier van gaan vinden. Komen er voor de browsers van die bedrijven ook goede pgp plug-ins? Voorlopig heeft de plug-in hoofdzakelijk marketingwaarde. Voor echt nut zal er een bredere adoptie nodig zijn. Dus meer gebruikers, maar ook zeker meer clients die het moeten gaan ondersteunen.

[Stevie-P]

Hier haal je een heel goed punt aan. Ik ben niet bereid mijn private PGP sleutel te uploaden naar google...

[mxcreep]

Hoe ben je er zeker van dat die sleutel daar nooit terecht komt als je hun plugin gebruikt ?

In dit geval is makkelijker en handiger bijna altijd meteen minder veilig... Helaas maar waar...

[Stevie-P]

Dat bedoelde ik ook te zeggen. Ik ga deze plugin niet gebruiken, want straks staat mijn private key ergens op een google server.

[Chip.]

Van code.google...

How safe are private keys in memory?

In memory, the private key is sandboxed by Chrome from other things. When private keys are in localStorage they’re not protected by Chrome’s sandbox, which is why we encrypt them there.
Please note that enabling Chrome’s "Automatically send usage statistics and crash reports to Google" means that, in the event of a crash, parts of memory containing private key material might be sent to Google.

[Verwijderd]

Lijkt me idd vrij logisch. Een crashreport betekent dat er iets onvoorziens is gebeurt, dus het geheugen rond de crash is dan moeilijk te voorspellen. Daar zou idd prive data in kunnen zitten. Dat was al zo, en dat blijft ook zo.

[Dred]

Zeer slecht gesteld met Belgische providers, geen enkel van de grote providers doet enigsinds moeite (0%). Beveiliging is nog steeds het laatste punt op de agenda van veel bedrijven, ook al worden ze keihard gehacked en in het nieuws gebracht (Belgacom enkele maanden geleden). Ik vraag mij af hoe Telenet dat rijmt met hun beveiligde cloud (AWS like via HostBasket) en portal voor ondernemers (CloudOffice), klaarblijkelijk zijn de veiligheidseisen niet zo hoog.
Wat mij wel positief opvalt is Amazon, en dan vooral hun SES (simple email service) dienst, tof dat die zo hard hun best doen! Je kan zeggen van AWS wat je wilt, ze proberen toch een veilige omgeving uit te bouwen, lijkt mij sowieso beter dan zelf wat te prutsen en dan dergelijke zaken als mails niet op orde hebben. De veiligheidsdiensten raken wel overal in als ze willen, Amerikaans (patriot act) of niet.