Onderzoekers: stop direct met gebruik pgp vanwege lekken - update

Diverse Duitse onderzoekers en de Electronic Frontier Foundation waarschuwen dat gebruikers direct moeten stoppen met het gebruik van pgp. Er zitten kritieke en niet gedichte lekken in de e-mailversleuteling die mails uit het verleden leesbaar kunnen maken.

De Electronic Frontier Foundation zegt dat het stoppen met pgp een tijdelijke maatregel moet zijn, totdat de impact van de lekken beter duidelijk is en er wellicht manieren zijn om pgp weer veilig te gebruiken. Tot die tijd raadt de organisatie aan om Signal te gebruiken voor versleutelde communicatie.

Een van de ontdekkers van de lekken, beveiligingsonderzoeker Sebastian Schinzel, zegt ook dat gebruikers per direct zouden moeten stoppen met het gebruik van pgp, omdat de lekken het mogelijk maken om de inhoud van berichten te ontsleutelen.

Details zijn er nog niet. Gnupg-oprichter Werner Koch zegt dat het lek zou zitten in de html-parsing van pgp-mails in mailclients. Het uitzetten van de mogelijkheid om html te tonen in mails zou daarom ervoor zorgen dat aanvallers het lek niet kunnen misbruiken. Koch zegt de paper onder ogen te hebben gehad in een posting waar NOS-journalist Joost Schellevis naar verwees.

De onderzoekers, onder meer verbonden aan de Fachhochschule Münster, brengen de details van de lekken, die zij #efail hebben gedoopt, dinsdag naar buiten in een paper. De lekken zitten in zowel pgp als s/mime en er zijn momenteel nog geen patches voor.

Update, 13:21: De site en de paper van #efail staan online, eerder dan de onderzoekers zeiden. De onderzoekers maakten inderdaad gebruik van het tonen van html van externe bronnen in mails om inhoud van pgp-mails te pakken te krijgen.

Reacties (128)

[atomos]

Hmm voor extra info: https://lists.gnupg.org/p...sers/2018-May/060315.html

Tis de vraag of het PGP zelf is.

[gekkie]

Hmmm als ik het dan wel lees is dan het idee dat je:
Een pgp encrypted mail onderschept, deze aanpast zodanig dat sommige mail user agents die aangepaste mail als HTML parsen waardoor het geencrypte deel middels het automatisch opvragen van een link wordt prijsgegeven aan een server van derden. Terwijl de MUA eigenlijk de mail zou moeten afkeuren (dan wel uiterst voorzichtig parsen) omdat de integriteit niet in orde is en dit ook al als zodanig herkent kan worden.

Dus geen html bekijken en/of geen automagische plaatjes downloads toestaan, zouden het probleem ook al voorkomen.

Klinkt weer als een orkaan in een glas water, wel weer een hippe nieuwe naam erbij in het lijstje met de "efail"

[aswelter]

En uit wat ik net las op https://lists.gnupg.org/p...sers/2018-May/060321.html zou de MUA gewoon een melding moeten geven.

By default, GnuPG will scream bloody murder if a message lacks an MDC or
if the MDC is invalid. At that point it's up to your email client to
pay attention to the warning and do the right thing. Enigmail 2.0 and
later are fine, but I can't speak for other systems.

Is wel meer dan orkaan in glas water, is pertinente nepnieuws. Maar helpt wel om meer aandacht aan PGP te geven wat weer wel oke is

[Jerie]

Note to anyone coming fresh to the conversation: disabling the display
of HTML email is *probably* a sufficient mitigation in either case.

GPG/PGP niet meer gebruiken is een mug neerschieten met een kanonskogel.

https://lists.gnupg.org/p...sers/2018-May/060330.html

MDC staat standaard als compile flag aan.

MDCs stop it dead. If a message has no MDC or an invalid MDC, GnuPG
_will_ warn you about it. Now, whether your email client does the right
thing upon being warned, that's between you and your email client...

Dat zou dus betekenen dat de bug in MUAs zitten.

https://lists.gnupg.org/p...sers/2018-May/060336.html

[tweaknico]

Klopt, en de MUA's verwerken de foutmeldingen van GPG/PGP niet correct (door verduistering van foutmeldingen, dat is toch maar lastig voor de simpele eidgebruiker)...

Versimpeling is niet altijd verbetering.

[Maurits van Baerle]

Ik zou het geen orkaan in een glas water noemen. Het is wel degelijk een probleem, voornamelijk voor mensen die op PGP in hun emailclient vertrouwen voor vertrouwelijke communicatie.

Het is dan ook belangrijk dat er veel aandacht voor is zodat emailclients gedwongen worden het probleem snel op te lossen. Ik denk dat we morgen rond deze tijd een uitgebreide lijst van emailclients hebben waar dit probleem speelt en het dus zaak wordt om de makers ervan onder druk te zetten.

Je zou hooguit kunnen zeggen dat headlines als “PGP is onveilig” niet zo handig zijn. De vraag is of de onderzoekers meer hadden kunnen doen om dat soort headlines te voorkomen of dat een reeks journalisten er ook schuld aan hebben.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 14:46]

[gekkie]

Ik zeg ook niet dat het geen probleem is (en dus geen oplossing zou verdienen), maar als je in die gebruikssituatie je het automagisch downloaden van afbeeldingen nog aan hebt staan is dat al het merendeel van de storm ...
En dan is het hele getamboer inderdaad nogal overdreven in mijn optiek en had men beter gewoon full disclosure kunnen geven inclusief mitigation. Aangezien bij mijn weten elke MUA wel een instelling daar voor heeft was full disclosure prima mogelijk geweest.

[Reactie gewijzigd door gekkie op 23 juli 2024 14:46]

[Maurits van Baerle]

Ik heb nog niet de kans gehad om me er uitgebreid in te verdiepen maar op het eerste gezicht lijken er twee problemen te zijn:

1) Niet alle mailclients luisteren naar foutmeldingen van de PGP module zodat waarschuwing over gebrekkige veiligheid van een specifieke email genegeerd worden.

2) Middels automatische parsing van externe links kan soms met PGP versleutelde inhoud lekken.

Beiden lijken me vrij eenvoudig op te lossen, mailclients moeten PGP foutmeldingen niet negeren en zouden bij PGP mailtjes niet automatisch externe links moeten parsen (of misschien zelfs helemaal geen HTML moeten parsen maar daarvoor heb ik me er nog niet genoeg in verdiept).

[gekkie]

Mjah tis een opeenstapeling lijkt het.

• het is al niet slim van MUA's om automagisch urls te volgen en proberen content te downloaden (img's)
• aangezien dit altijd tot een info lek kan leiden (gelezen / ontvangen status).
• het is dubbel niet slim om bij PGP versleutelde mail dat soort info te lekken en dat niet automagisch uit te schakelen en gewoon niet toe te staan.
• het is driedubbel niet slim om dat nog steeds te doen als PGP aangeeft dat de mail gemanipuleert is.
• afkeuren en eventueel plaintext weergeven en meer niet.

Maar goed als je niet met sensitieve mail doet zou je 1 al uitgeschakeld moeten hebben, wat vervolgens ook zorgt dat 2 en 3 niet meer werken denk ik.
Maar goed of iedereen dat achter het automagisch tonen van afbeeldingen zoekt is de vraag (want het is zo handig (ofzo)).

[Maurits van Baerle]

Ik denk dat er wel een aardig compromis gevonden kan worden voor het afbeeldingenprobleem. Zelfs mensen die veel PGP email ontvangen zullen waarschijnlijk hooguit 10% van hun email met PGP ontvangen. Uitgerekend newsletters, reclame etc. zullen zonder afbeeldingen amper werken maar zullen ook niet zo snel de inhoud encrypten.

Een defaultinstelling van een MUA waarbij automatisch afbeeldingen getoond worden maar niet bij PGP emails lijkt me een prima default die veel problemen voorkomt.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 14:46]

[gekkie]

Er zullen inderdaad genoeg mensen zijn die van ploatjes kieken houden (en gemak).

Maar zonder werkt over het algemeen ook prima, meeste is prima als plaintext te lezen en ook chinese boeren hebben netjes middels alt attributes een tekst aan plaatjes gekoppeld. Meeste mua's bakken er vervolgens toch doorgaans wel wat leesbaars van in plaintext ook al is de mail HTML only.
Op het moment dat je als nog getracked wil worden voor die aanbiedingen is er nog een link naar de website waar die meuk te vinden is (of je gaat gewoon zelf naar de site zonder tracking id in de url).

[Cerberus_tm]

De webmail van Google download plaatjes naar de server van Google zelf, die ze dan vervolgens weer doorstuurt naar jouw browser. Zo is er qua plaatjes dus alleen contact tussen de server van Google en jouw computer, waardoor dit probleem lijkt mij niet op kan treden. Alleen moet je Google dan wel daarmee vertrouwen...

[gekkie]

Als google de querystring niet stript dan lekt er volgens mij nog steeds info en ik zie niet helemaal in hoe ze failsafe de querystring kunnen strippen.

[Cerberus_tm]

Hmm ik weet ook niet precies hoe Google dat doet. Maar ik neem aan dat Google sowieso geen scripts gaat draaien in een e-mail? En kun je met pure html/css dynamisch een url van een plaatje veranderen? Weet niet of ik het zo goed omschrijf.

[Reactie gewijzigd door Cerberus_tm op 23 juli 2024 14:46]

[EraYaN]

Dat wordt gewoon op de verzendende server gedaan, denk fingerprinting.

[Cerberus_tm]

Oké maar dan is het lek daar dus niet van toepassing, d.w.z. dat er geen manier is voor de inhoud van een bericht om via de link van zo'n plaatje bij de boef te geraken.

[Ge Someone]

De vraag is of de onderzoekers meer hadden kunnen doen om dat soort headlines te voorkomen ...

De waarschuwing komt van EFF, en voor de rest zijn de journalisten verantwoordelijk voor de koppen.

[locke960]

Het geeft wel weer aan hoe slecht de beslissing was om HTML in email te gaan gebruiken. 20 jaar geleden dacht iemand "he das leuk", en sindsdien zijn we bezig met het dichten van security en privacy gaten.
En bijna al die gaten zaten in functionaliteit die in E-mail helemaal niet nodig zijn, zoals scripts, inline content van externe servers en toegang tot het lokale filesysteem.
Rich Text Format is wat dat betreft 100x beter.

[BasieP]

Das niet helemaal een eerlijke reactie.
Ook in rtf kan je externe elementen toevoegen.
Als je client zo stom is om die ook gewoon direct in te laden is dat niet de schuld van het formaat dat je gebruikt. Het is de client-implementatie die zorgt dat het mis gaat. Niet het feit dat het html is.

[DJMaze]

Een pgp encrypted mail onderschept, deze aanpast zodanig dat sommige mail user agents die aangepaste mail als HTML parsen

Ik neem aan dat je DKIM gebruikt zodat de e-mail al een dikke error krijgt bij aanpassingen.

Natuurlijk zijn er systemen die geen DKIM ondersteunen, maar dat is dan eigenlijk al probleem #1

[Verwijderd]

Ik gebruik zelf een oude Thunderbird en heb al dat soort html zooi voor mails uitstaan behalve voor vertrouwde afzenders (en dat zijn allemaal afzenders die me toch niks vertrouwelijks mailen).

[Verwijderd]

There are two ways to mitigate this attack

- Don't use HTML mails. Or if you really need to read them use a
proper MIME parser and disallow any access to external links.

- Use authenticated encryption.

Raar. Ik dacht dat PGP email altijd authenticated encryption gebruikte.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:46]

[MacGyverNL]

Kort antwoord: dat doet het niet.

Lang antwoord: Allereerst is de term "authenticatie" overloaded in deze context, d.w.z. er zijn meerdere betekenissen die allemaal van toepassing zijn.

De eerste betekenis: de authenticatie van dat een e-mail daadwerkelijk is opgesteld door een specifieke afzender. Die krijg je door wat gegoochel met asymmetrische cryptografie, de zogeheten digitale handtekeningen. Dat is waar de meeste mensen aan denken in de context van versleutelde e-mail, maar is niet de betekenis die hier bedoeld wordt.

De tweede betekenis: de authenticatie dat een versleutelde ciphertext die met een symmetrisch algoritme is versleuteld, ongewijzigd is en versleuteld is door iemand die in het bezit is van de sleutel. Het is voornamelijk een zeer sterke garantie op de integriteit van wat je binnenkrijgt, en is normaal gesproken zo gemaakt dat de integriteitscheck gedaan wordt voordat decryptie plaatsvindt. De gestandaardiseerde vormen hiervan noemen we "Authenticated Encryption" (en tegenwoordig vinden we eigenlijk alleen maar "Authenticated Encryption with Associated Data", ofwel AEAD, interessant). Voorbeelden hiervan zijn GCM, EAX, en OCB.

Omdat er rond 2000 al problemen verwacht werden met de klassieke, unauthenticated modes of encryption (CBC, CFB, OFB e.d.), maar er nog geen gestandaardiseerde manier was om dat op te lossen, heeft men in PGP de zogeheten "Modification Detection Code" ingevoerd. Zonder verder op de technische details in te gaan, heeft PGP het probleem dat het compatible moet zijn met oudere versies, dus kan het zomaar zijn dat die MDC ontbreekt. Daarnaast begaat MDC de zonde dat de check pas gedaan wordt na decryptie -- en het falen van de MDC-check is geen obstakel om de decrypted content alsnog te gebruiken. Dit is waar GnuPG in mijn ogen wel degelijk de bal laat vallen: als je authenticatiemiddel aangeeft dat er wijzigingen hebben plaatsgevonden, moet je alle operaties gewoon stoppen en niet alsnog de decrypted plaintext aan je consument geven met een error als sausje ernaast.

En waar het dan fout gaat is dat e-mailclients deze fout, die ze wel te horen krijgen van GnuPG, gewoon negeren en de decrypted content laten zien -- met alle gevolgen van dien.

Bottom line: gebruik voor je symmetrische behoeftes altijd authenticated encryption, los van of je daarna ook nog handtekeningen gaat zetten met asymmetrische algoritmes.

[Verwijderd]

Dat de ciphertext met een MAC wordt geauthenticeerd is altijd onderdeel van een encryptie systeem, volgens mij. Als dat er niet zou inzitten (of het nou in de cipher zit, zoals bij XTS of GCM, of met een aparte MAC zoals HMAC maakt niet uit) dan zou PGP gewoon slecht ontworpen zijn, en dat geloof ik niet.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:46]

[MacGyverNL]

Dat de ciphertext met een MAC wordt geauthenticeerd is altijd onderdeel van een encryptie systeem, volgens mij.

Was het maar zo'n feest. Vaak genoeg wordt symmetrische crypto ongeauthenticeerd toegepast; daar komen alle oracle attacks vandaan.

Als dat er niet zou inzitten (of het nou in de cipher zit, zoals bij XTS of GCM, of met een aparte MAC zoals HMAC maakt niet uit)

Dat maakt wel uit, voornamelijk omdat de meeste programmeurs geen cryptografie-programmeurs zijn en derhalve niet in staat om een dergelijke compositie veilig op te stellen.

edit:
Case in point: XTS is géén AEAD-mode of operation. Er is geen authenticatie, het garandeert alleen maar dat je plaintext volledig random wordt. En daarbij is het dus weer de taak van de consument om te zorgen dat hij aanpassingen detecteert, zoals een checksum in z'n eigen protocol, met alle risico's (timing oracles e.d.) van dien. XTS gebruiken voor iets anders dan disk encryptie is daarom een vrij slecht idee -- en eigenlijk wil je bij disk encryptie dus wel een bestandssysteem met checksums.

dan zou PGP gewoon slecht ontworpen zijn, en dat geloof ik niet.

En toch is het zo. Zie https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html. Dat wil niet zeggen dat PGP slecht ontworpen is -- bedenk dat PGP is ontworpen voordat we in de cryptografie het brede besef hadden dat malleable ciphertexts zo'n gigantisch probleem waren, ook in contexten waar asymmetrische handtekeningen geplaatst werden.

De MDC die ze nu gebruiken is ook maar matig, om 't simpele feit dat 't een MAC-then-encrypt-constructie is.

edit:
Het is nog erger dan dat, zie beneden.

Ergo, je kunt je integriteitscheck niet doen voordat je decrypt, en dat levert ook weer potentiële aanvalsvectoren op die je kunt vermijden met een encrypt-then-MAC- of andere AEAD-constructie.

edit:
Iemand wees me erop dat de MDC niet eens een MAC-then-encrypt-constructie is, maar een hash-then-encrypt-constructie. Je kunt dat ding berekenen zonder de symmetrische sleutel te hebben. Dat stelt je bloot aan meer aanvalsvectoren dan MtE. Dat is wel degelijk slecht design.

[Reactie gewijzigd door MacGyverNL op 23 juli 2024 14:46]

[Verwijderd]

Dat is dus het probleem: dat mensen die niets (of heel beperkt) van cryptografie afweten een cryptografisch systeem in elkaar proberen te knutselen.

[Kewne]

De officiële site (want ja, ieder lek heeft er een nodig) is inmiddels up: https://efail.de/

[bartvb]

Alleen lijkt het erop dat dit eerder een publiciteitsstunt is dan een serieus probleem met PGP of S/MIME:
https://news.ycombinator.com/item?id=17064129

De 'officiele site' geeft alleen het verhaal van de 'ontdekkers' van het lek, niet van de mensen en organisaties die zich bezig houden met de protocollen en implementaties. Niet bepaalt objectief dus.

Valt me nogal tegen van de EFF dat ze hier zo enorm zijn meegelopen met het verhaal zonder contact op te nemen met de mensen achter o.a. PGP.

[tweaknico]

Het is niet direct een probleem van PGP S/MIME maar in dit geval een groot gebrek van de E-mail clients....
waarbij PGP en S/MIME alleen maar slachtoffer.

De oplossing is ook niet direct in PGP of S/MIME op te lossen (al kunnen een paar zaken scherper gesteld worden).., maar in hoe Mail clients om moeten gaan met inhoud... en niet klakkeloos alles maar accepteren als er fouten in zitten.

[Ventieldopje]

Wauw een onderzoeker die aandacht wil

Ik krijg netjes waarschuwing (Postbox 5) als ik een mail versleuteld wil versturen met PGP maar het geen plain-tekst email is. Lijkt mij dus dat dit al veel langer bekend is.

Sowieso een beetje onnodig om prachtige html mails naar elkaar op te sturen als ze vertrouwelijk zijn en vesleuteld moeten worden als je het mij vraagt.

Update: ik heb de paper doorgespit en er is inderdaad wel het een en ander aan de hand. Goed, de aanval is alleen uit te voeren als je een HTML mail ontvangt. Nou zei ik al van tsja het is ook dom als je HTML mails verstuurd en die encrypt. Het nare is dus dat als de aanvaller via een MITM, SMTP / IMAP hack jouw emails weet te onderscheppen hij de ciphertext aan kan passen en vervolgens (nog een keer) kan sturen naar de ontvanger. Vervolgens is het ook mogelijk (en blijkbaar doodsimpel) om de hele authenticatie en integrity protection uit te schakelen waardoor die wijzigingen dus niet snel opvallen en wanneer dit opvalt het vaak al te laat is. Ook is het mogelijk (en dit is naar) om een plain-text mail om te toveren naar een HTML mail waardoor de aanval alsnog uitgevoerd kan worden.

Zoals te lezen in hoofdstuk 7:

Backchannels are critical, because they provide a way
to instantly obtain the plaintext of an email. Reliably
blocking all backchannels, including those not based on
HTML, would prevent all the attacks as presented. However,
it does not fix the underlying vulnerability in the
S/MIME and OpenPGP standards.

[...]

In the following section we present long-term mitigations
which require updating the standards.

Laten we hopen dat het inderdaad echt een implementatie fout is bij veel clients Ook wel erg vreemd hoe de mensen van efail er mee omgaan.

[Reactie gewijzigd door Ventieldopje op 23 juli 2024 14:46]

[piderman]

Het meest vervelende is dat in elk PGP bericht staat welke sleutels er gebruikt zijn, en meestal ook de daarbij behorende email adressen. Dus als je een willekeurig geëncrypt bericht op straat vindt (of door een email relay aan het internet te hangen of zo), kan je vrolijk al die berichten sturen naar de email adressen die genoemd worden (hoeven niet per se dezelfde te zijn als de afzender/geadresseerde) en geheid dat je ergens beet hebt.

[Jerie]

Matthew Green's reactie. Leesbare thread.

[Reactie gewijzigd door Jerie op 23 juli 2024 14:46]

[Candymirror]

Zit dit lek alleen in PGP of in de manier van versleutelen en is dus de opensource variant GnuPG ook geraakt?

[rbr320]

Geen van beiden. Het issue ligt bij de manier waarop sommige mailprogramma's om gaan met versleutelde HTML emails, met name als er links naar buiten toe in de HTML zitten. De versleuteling van GPG en GnuPG zelf is prima in orde en je hebt van het hele issue geen last als je "plain text" emails gebruikt.

[kvdveer]

Die informatie is nog niet openbaargemaakt.

Gegeven dat de auteurs van GnuPG niet benaderd zijn door de bezoekers, maar de makers van email-clients wel, kunnen we aannemen dat het niet op de versleuteling misgaat, maar ergens in de behandeling van ontsleutelde berichten.

[mocean]

Is er een goed alternatief? Onversleutelt mailen is ook leesbaar. Dus maar weer post sturen?

[kvdveer]

Als (zoals de meeste bronnen melden) het lek in de HTML parser zit, kun je gewoon tekst-email sturen. Dat zou je sowieso al moeten doen, want HTML heeft een veel te groot attack surface voor dingen die je veilig wilt houden.

Gegeven het feit alle secundaire bronnen geen moord en brand schreeuwen (GnuPG was niet eens benaderd door de onderzoekers), denk ik dat het allemaal wel meevalt, en dat de onderzoekers proberen hun 15 minuten fame te innen door een klein issue enorm op te blazen.

[Nystran]

Een kwade stem in mijn hoofd zegt dat dit een ideaal moment is voor "entiteiten die tegen encryptie zijn" om een media aanval op PGP zelf te starten, zodat mensen gaan twijfelen over PGP zelf en minder veilige communicatie gaan/blijven gebruiken.

Maar misschien heb ik teveel "Merchants of Doubt" gelezen...

[stresstak]

Een kwade stem in mijn hoofd zegt dat dit een ideaal moment is voor "entiteiten die tegen encryptie zijn" om een media aanval op PGP zelf te starten, zodat mensen gaan twijfelen over PGP zelf

Een beetje zoals ik heb met het plotselinge stoppen van TrueCrypt. Wantrouwen is een deugd.

[Eagle_Erwin]

Op de website van EFAIL:

The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim.

De aanvaller zal dus ook een niet-HTML-mail gewoon omzetten naar een HTML-mail om de aanval uit te voeren, waardoor de encrypted inhoud van je niet-HTML-mail kan lekken.

[tweaknico]

Oplossing: geen HTML mail meer lezen..., alleen te Plain tekst erin gebruiken.

(Waar dan meestal een link staat naar clickable content....)
Als mensen/organisaties mij iets willen mailen ZONDER HTML wil ik het wel lezen, als het HTML only moet jammer dan.

[Pikoe]

De EFF raadt op het moment Signal aan, dat staat hierboven beschreven.

[Reactie gewijzigd door Pikoe op 23 juli 2024 14:46]

[marcmeide]

Kan iemand me uitleggen wat het verdienmodel van Signal is? Ik kan het op de site niet vinden maar ze moeten wel op een manier hun servers draaiende houden toch?

[Tha]

https://www.iculture.nl/n...ichter-50-miljoen-signal/ ze krijgen in ieder geval geld van de mensen die hun ziel zelf reeds aan de duivel hedden verkocht.

[Bastiaan V]

Brian Acton zijn ziel aan de duivel verkocht? Je bedoelt omdat hij whatsapp heeft verkocht aan facebook.. Commercieel gezien was/is er natuurlijk geen andere mogelijkheid dan het aan 1 van de groten te verkopen, gezien het product gratis is. (En je dus betaald met je privacy).

Hij is zelf juist weer bij facebook weggegaan omdat hij zich niet kon vinden in de manier waarop facebook met privacy om gaat...

[Cerberus_tm]

Ik vind dat toch wel vrij ernstig. Als hij dat niet had gedaan, en Whatsapp veilig had gemaakt, had de halve wereld nu automatisch veilige communicatie gebruikt. Er is altijd een andere mogelijkheid. Desnoods inderdaad fondsen ophalen bij idealistische partijen / overheden.

[Bastiaan V]

En waarvan had hij dan het beleg op zijn brood moeten betalen?

Als buitenstaander is het natuurlijk makkelijk praten, maar als het er op aan komt en je krijgt de mogelijkheid zo'n megadeal te sluiten, dan zou 99%+ hem pakken. Zeker als er al alternatieven zijn die meer op de privacy gericht zijn.

[fleshlight]

Volgens Signal zelf:
"Signal is made for you. As an Open Source project supported by grants and donations, Signal can put users first. There are no ads, no affiliate marketers, no creepy tracking. Just open technology for a fast, simple, and secure messaging experience. The way it should be."

[tweaknico]

Met alleen nog een single entiteit als centrale server....
Dus nog steeds een centraal Watering hole....

Beter is een federated oplossing met veel partijen die hetzelfde protocol gebruiken..
oh dat zelfde protocol doen ze al signal, whatsapp, ... gebruiken allemaal XMPP als basis....
Nu alleen nog de wil tot samenwerken. en niet de verplichting tot een eenduidig etiket (telefoon nummer) op iedereen plakken...

Of een andere die dat wel gaat opzetten: https://matrix.org
Matrix servers kennen ook het fenomeen bridges waarbij een exit point naar een andere omgeving kan worden gelegd. (naar IRC bijvoorbeeld) IRC heeft alleen geen encryptie die ben je op IRC zelf dus kwijt.

[MrNGm]

Geen. Ze lijken op crowdfunding en sponsoring te zitten. Zie ook https://signal.org/blog/how-to-help/ en https://en.wikipedia.org/wiki/Open_Whisper_Systems#Funding

[Unsocial Pixel]

Signal laat je ook je eigen server draaien maar volgens mij donaties? Idunno zal het zo wel opzoeken

[tweaknico]

Maar dan niet federated, het is dan je private cloud.

[rbr320]

Okee we stellen de vraag anders: is er een goed email alternatief? Want voor zover ik weet is Signal niet in staat om versleutelde email berichten te sturen, het is zijn eigen berichtenecosysteem.

[mbb]

Het grote alternatief is S-mime. Wat volgens de titel niet getroffen is, maar volgens de laatste regel van het artikel wel?

[PPie]

Het lijkt dus niet echt een 'PGP lek' als wel een 'Mail App' lek?

[mbb]

Klopt; het belangrijkste artikel lijkt de lijst met getroffen clients te zijn, en ze zijn nu bezig die te fixen.
S-Mime blijkt trouwens een stuk harder getroffen dan PGP implementaties.

Vulnerable clients (was: US-CERT now issuing a warning for OpenPGP-SMIME-Mail-Client-Vulnerabilities)
https://lists.gnupg.org/p...sers/2018-May/060375.html

[DamirB]

Persoonlijk gebruik ik ProtonMail, erg tevreden mee.

[s_schimmel]

Gebruik ik zelf ook maar ook ProtonMail maakt gebruik van OpenPGP. We moeten wachten op de paper maar de kwetsbaarheid zou dus ook in ProtonMail kunnen zitten.

[Frederik99NL]

Ik gebruik ook sinds een aantal weken proton, werkt inderdaad erg fijn!

[Tormbo]

ProtonMail gebruikt toch ook gewoon een variant van PGP? Ik vermoed dat zij even zo vatbaar zijn voor deze lekken.

[DamirB]

https://protonmail.com/su...g-a-message-using-pgppgp/

Volgens mij gebruik protonmail het niet, wel end-to-end encryptie.

Persoonlijk heb ik de de nodige kennis over versleuteling van data, een van mijn rede's voor het kiezen protonmail is de extra decrypt code die je moet invoeren om in je mail te komen, toch nog een extra stapje veiliger mochten mijn emailadres en wachtwoord op straat komen na een grote data breach. Ook zijn de mails tussen protonmail gebruikers encrypted.

@Kermit123

[Kermit123]

Proton gebruikt weldegelijk intern PGP, je kan vanaf het allereerste begin (was beta tester en bij de eerste 10.000 accounts) je publieke pgp sleutel versturen en PGP mail ontvangen.
https://protonmail.com/security-details

De door jouw aangehaalde link gaat over het versturen met een externe publieke sleutel. Dit kan al heel lang niet en daar snapt eigenlijk niemand wat van. De core van Proton is wel degelijk PGP. Wordt nu eindelijk aan gewerkt, maar nog in Beta zie link.
---------------------------
PGP is a time-tested and proven method of protecting email communications with end-to-end encryption (which prevents emails from being read by any third parties, including the email provider). Historically, PGP has been difficult to use, and it was not possible for most users to set up and regularly use PGP.

ProtonMail is unique because it has PGP fully integrated such that you do not need to take any additional steps to benefit from PGP encryption. This means that with ProtonMail, anybody can use PGP, regardless of their technical knowledge.

All messages between ProtonMail users are automatically end-to-end encrypted. Additionally, all messages in ProtonMail inboxes are protected with PGP encryption to prevent us (or anyone else) from reading or sharing your emails while at rest, a concept known as zero-access encryption.

https://protonmail.com/su...edge-base/how-to-use-pgp/

[Reactie gewijzigd door Kermit123 op 23 juli 2024 14:46]

[Kermit123]

Maar het lijkt een PGP/GPG generiek probleem te zijn en daar maakt Protonmail ook gebruik van. Ik heb al snel even op de site van Protonmail gekeken, maar daar is nog geen melding van problemen.

Ik heb de vraag bij Protonmail al neergelegd

[Reactie gewijzigd door Kermit123 op 23 juli 2024 14:46]

[Maurits van Baerle]

Zoals het er nu naar uitziet is het niet een probleem in PGP maar een probleem met hoe sommige mailclients omgaan met PGP.

Als dat klopt dan is het is dus prima mogelijk dat een dienst of of client gebruik maakt van PGP en hier geen last van heeft.

[Lapa]

Precies, ik kan me haast niet voorstellen dat onversleutelde mail nu veiliger is dan met PGP versleutelde berichten.

[watercoolertje]

Signal, staat in het artikel.

[mocean]

Maar van mensen waar ik een e-mailadres van heb (bijv.) heb ik niet automatisch een Signal adres toch?

[RobinF]

Klopt, maar ook niet iedereen waarvan je een emailadres hebt wil met PGP zitten.

[Zer0]

Het mooie is dat de meeste email clients met pgp ondersteuning de mogelijkheid bieden deze wel of niet te gebruiken, waardoor je op één platform zowel "gewoon" als versleuteld kunt communiceren.

[tweaknico]

Signal adres = telefoon nummer.

[SuperDre]

tja, dan kun je ook gewoon zeggen, Whatsapp, want die versleuteld de communicatie ook..
Het gebruik van Signal is ook maar de vraag of die wel veilig is, net zoals nu dus PGP ook niet veilig blijkt te zijn waarvan al jaren gedacht werd van wel, en het is opensource dus iedereen had de source kunnen bekijken of het wel veilig was.. Dus maar weer een goed voorbeeld dat opensource ook niet zaligmakend is als het om beveiliging aan komt.

[watercoolertje]

Ik had dat kunnen zeggen, makkelijker was gewoon als de persoon die het vroeg het artikel had gelezen, of jij op hem had gereageerd om er op te wijzen dat whatsapp ook een alternatief is, hij vroeg het namelijk, niet ik

[mbb]

Het 'lek' lijkt geen programmeerfout in het protocol, maar een indirect gevolg te zijn van hoe de opensource gemeente met software werkt.
Ze hebben allemaal kleine projecten die door verschillende andere projecten voor verschillende doelen gebruikt worden. Maar daardoor moeten ze veel verschillende functies ondersteunen. En wordt er niet goed tussen alle groepen gecommuniceerd, waardoor er soms in het gebruik verkeerde implementaties ontstaan.

Of zoals Fiedler Roman het op de gnupg.org mailing list omschrijft:

In my opinion it is hard to find such a "one size fits all" solution. Like Werner's example: disabling decryption streaming operation might increase security for some use-cases (validation before decryption&output) but might make others impossible, like streaming of backups (decryption&output before final validation). So you need something on the interface to support that non-standard behavior, deviate from the default.

Then why are there already so many command line options for decryption/validation gpg not just one: "--insecure"? From my point of view, monopolists might be able to push one set of defaults but the open source software ecosystem might work differently: those projects survive, that enable that many use-cases per development effort, so that they find sufficient developers/funds to support development. If they drift off, the project will fork/another project might take over.

So gpg has to watch out for the optimum point between following extremes:

1) Only supporting one standard use-case with default settings (thus increasing security but loosing users)
2) Supporting many use-cases via different gpg-internal decryption/validation-process models (requiring loads of parameters, complex models, lot of implementation, risk to invoke gpg with wrong parameters)
3) Supporting one generic use-case/process model and leaving it to the caller (other side of interface) to decide what to make from it (risk, that other party just does not do it right - e.g. ignores a warning like with Efail)

Assuming, that the ideal point would be somewhere in between, supporting only a single FAIL status like old-style shell commands might not be sufficient to attract sufficient users from world 1, 2, 3 above.
LG Roman

[Dorank]

En stoppen met pgp maakt je historische mail niet opneens onleesbaar!

Gelukkig is de impact minimaal, niemand gebruikt PGP via email. Ik loop rond met gnupg smartcards maar het aantal PGP encrypted mail wat ik stuur is maximaal nog geen 10, voornaamste gebruik is als ssh key, heel af en toe signing.

Maar verder gebruik ik natuurlijk geen MUA die HTML doet, als ik al een HTML mail open dan wordt eerst het bericht naar file geschreven en start m'n MUA gewoon de default browser op.

Vooralsnog bestempel ik persoonlijk dit bericht als hoax. De melding en de impact zijn sensationeel en lijken geen probleem van PGP te zijn.

[GekkePrutser]

Hier ook.. Ik gebruik PGP voor file encryptie, met OpenPGP smartcards inderdaad als SSH key. Ook heb ik wat Yubikeys (de "touch to sign" functionaliteit voorkomt misbruik van de authenticatie agent). Daar is geen probleem mee.

[WhatsappHack]

Is er ergens een plugin om te mailen via Signal Protocol dan? Anders een beetje rare opmerking van de EFF.

Trouwens, als het lek in het parsen van HTML zit dan zou je denken dat S/MIME misschien kwetsbaar is voor dezelfde aanval. Al is het raar om te stellen dat het lek dan in de encryptiemethode zit.

[Ventieldopje]

S/MIME heeft dus ook kwetsbaarheden omdat die helemaal niet gebruik maakt van authenticated encryption (zie ook de paper) en hier.

[Reactie gewijzigd door Ventieldopje op 23 juli 2024 14:46]

[s_schimmel]

Wat ik niet snap is waarom vandaag bekend wordt dat er een kwetsbaarheid zit in PGP en morgen de details pas volgen. Is die tijd nodig om de fix klaar te hebben? Als dat zo is kan dat toch worden aangegeven?

Dit komt nu als sensatie zoeken op mij over.

[Xenomorphh]

Nee, die fix is er morgen niet. het vroeg melden geeft organisaties en individuen vast de mogelijkheid om het uit te schakelen. Het publiceren van de lek betekent namelijk dat kwaadwillende er ook mee aan de haal kunnen.

[wica]

Het probleem schijnt te zitten in de html parser. Als je geen html mail gebruikt of niet laat parsen zou er geen probleem zijn volgens GnuPG https://lists.gnupg.org/p...sers/2018-May/060315.html .


Wie gebruikt er dan ook html mail ipv plaintext mail

[Adlermann]

De hele niet-tweaker wereld

[wica]

Maar die gebruiken toch ook geen PGP.
En de mensen die wel PGP gebruiken, moet toch al weten dat HTML e-mail evil i.v.m. met het verraden van info en andere ongein in HTML mail?

/edit
Ik bedoel beveiliging van je communicatie eindigt niet met het aanzetten van PGP, maar is een begin.

[Reactie gewijzigd door wica op 23 juli 2024 14:46]

[goarilla]

Maar die gebruiken toch ook geen PGP.

Sommige "leken" gebruiken gewoon COTS software om dit voor hun te doen (https://www.symantec.com/products/desktop-email-encryption).

[kvdveer]

Maar die gebruiken doorgaans ook geen GPG, toch?

[gfgw]

PGP wordt o.a. ook gebruikt door mensenrechtenactivisten en journalisten. Als je in een land leeft waar de vrijheid van meningsuiting iets minder is dan hier, wil je niet dat iedereen je mail kan lezen. Het gebruik van PGP maakt je daarom nog geen tweaker.

[zenlord]

Als er 1 reactie is die niet thuishoort onder bovenstaand artikel, dan is het dit wel. Hoe overroepen de boodschap ook moge zijn, het toont wel aan dat de keuze voor HTML in emails onveiliger is dan plaintext. Dit hoeft ook niet te verbazen: hoe eenvoudiger, hoe makkelijker te beveiligen.

[Dorank]

Ik kreeg van een bedrijf een mailtje dat ze stopten met het sturen van de nieuwsbrief aangezien ik die toch niet las volgens hun tracking/analyze. En toch las ik die dingen, echter keek ik naar of de plain tekst of de gestripte html variant als tekst, geen idee welke maar de streking is dat de unieke callbacks (scripts/images) niet werden uitgevoerd. En dat is waarom ik niet aan standaard HTML mail doe, heeft dus helemaal niets met klikken op links te maken maar met "spionage".

[goarilla]

Ik ben lang geleden al gestopt met mensen hun Outlook/Gmail html massa reply-threads te ontcijferen in plaint-text. Het is al erg genoeg in html. Het helpt ook niet wanneer je oversten een html signature voor iedere gebruiker eisen ! Ik moest daar gewoon dat oog dichtknijpen of ik kreeg geen werk gedaan.

edit: toevoeging
Al de netiquette uit de usenet wereld is gebleven bij de usenetters. De modale internet gebruiker
die replyed, forward, top-post in outlook html en die vinden dat normaal zonder dat ze er ooit bij hebben stil gestaan.

[Reactie gewijzigd door goarilla op 23 juli 2024 14:46]

[trisje]

Je doet nu net of iedere mail die je krijgt niet te lezen is. Je overdrijft hier heel sterk. In het bedrijfsleven heb ik daar nog nooit problemen mee gehad. Het wordt pas een probleem als hun e- mail client op plain tekst staat. En al die personen die vinden dat ze het netwerk moeten beschermen tegen HTML mail. Wordt eens een echte beheerder, dan een alles op slot beheerder. Zodat iedereen gewoon kan werken en productief is zonder dat je elke keer moet uitleggen dat een linkje sturen niet mag. En ook geen nieuws brieven mag lezen in de e-mailadres client die van je eigen bedrijf komen of van bedrijven waar je mee samenwerkt. Zorg voor een goed virus scanner en een goed policy belijd, maar beknibbelen niet op onzinnige acties die mensen het plezier om te werken ontnemen.

[goarilla]

En dat is juist net hetzelfde als wat ik probeer te zeggen.
Ik moet samenwerken met mensen die hun mail op manier x gebruiken, een manier die
de puristen pijn doet, maar ik moet en zal dat doen want anders krijg ik geen werk gedaan.
Dus ook mijn email client rendert html !!! Jezus ...
Wellicht wou jij replyen op Dorank's post.

[Reactie gewijzigd door goarilla op 23 juli 2024 14:46]

[wica]

/off-topic
Sinds ik tweakers reclame op Q-music gehoord heb, heb ik de verwachting niet, dat mensen hier per definitie iets van technische kennis hebben. Wat niet inhoud, dat technische mensen niet naar Q-music luisteren. Maar de doel groep van Q-music is totaal anders dan die van tweakers was.

[Verwijderd]

Dorank hier net boven geeft een heel simpel voorbeeld waarna iedereen die zijn breinpan gebruikt wel moet snappen wat er mis is met inline html parsing in je email client. Ook Q-music publiek ( trouwens, heb niks tegen geen enkele radio zender hoor, denk ook niet dat er een direct verband is tussen welk radio station iemand prefereert en hoeveel kennis deze persoon heeft ) zou dat moeten kunnen snappen, als ze maar bereid zijn om naar de beter geinformeerde mening van anderen te luisteren.

[wica]

Nee, ik verwacht niet van een bouwvakker ( welk ander niet technisch beroep ), dat die weet wat er mis kan gaan met HTML mail, die wilt gewoon zijn e-mail kunnen versturen met een hoop smillies en plaatjes.
Maar de bouwvakker, verwacht ook niet van mij dat ik een muur metsel. Ieder zijn eigen tak van sport.

Ook Q-music publiek ( trouwens, heb niks tegen geen enkele radio zender hoor, denk ook niet dat er een direct verband is tussen welk radio station iemand prefereert en hoeveel kennis deze persoon heeft )

Ik bedoel hier, zoals ook gezegd, dat de doel groepen van een radio station meestal niet de zelfde is, als de doel groep waar tweakers zich oprichten.

Alleen dat door reclame te maken, trek je wel meer volk, wat niet direct technisch is.

[Verwijderd]

/off topic

et is niet dat ik zeg dat er geen niet technisch onderlegd publiek hier is, maar dat ik daarvan wel verwacht dat men het zelf inzicht heeft niet technisch onderlegd te zijn en dus open staat voor de beter geinformeerde mening van anderen. Als er dus een stelling gemaakt wordt dat inline html parsing een risico is, en er wordt gereageerd met 'je bent purist' en 'zoekt gevaar wat er niet is', tja dat vind ik toch echt tweakers onwaardig.

Sorry voor off topic discussie trouwens, denk niet dat we echt een bijdrage leveren aan het onderwerp op het moment

[wica]

'je bent purist' en 'zoekt gevaar wat er niet is', tja dat vind ik toch echt tweakers onwaardig.

Ben het met je eens, maar dit soort reacties zijn hier tegenwoordig vrij normaal.

En nu stop ik er mee, voordat ik weer een admin edit of waarschuwing krijg ;p

[wica]

Kijk een goed op wie ik reageer en wie ik quote.
En neem nog een broodje.

[trisje]

Hij reageert op mij en jij op hem. Met je hebt gelijk. Reacties zijn normaal. Bovendien ga je er vanuit dat andere dan jouw mening per definitie niet technisch onderlegd zijn. Dus zo onschuldig is jouw reactie niet.

[Verwijderd]

trisje in 'nieuws: Onderzoekers: stop direct met gebruik pgp vanwege lekken -...

Dat links gevaarlijk kunnen zijn klopt, maar een beetje verstand snap je best waar je op kan klikken en waarop niet. ook voor de dege die echt niets snappen van computers.en je hebt gelijk die reactie van jouw hoort hier niet thuis, je zegt het zelf.

Je snapt niet eens dat het niet om links gaat maar om het risico vanwege insluiting plaatjes e.d? Jammer dat je begon met het uitsluiten van mensen hier met bovenstaande reactie, erg jammer. Zeker omdat je dus geheel fout bent ( ja, dat is een mening, en tja die van jou mag je ook hebben hoor natuurlijk ).

[trisje]

Nou in mijn andere reacties is toch best wel duidelijk dat het niet alleen maar om links gaat. weer een verwijt die niet klopt. Bovendien gaat het hier helemaal niet om het insluiten van plaatjes. Maar om het halen van data uit mail. die hier wordt misbruikt.

Ook heb ik het helemaal niet over pgp en e-mail, maar reageer ik op html e-mai niet gebruik zou moeten worden, daarbij zeg ik dat plain tekst inderdaad minder gevaarlijk is dan html mail , maar om dat nu volledig uit te zetten wat overdreven is. de meeste e-mail clients zowel webmail houden in eerste instantie het laden van content in zo mailtje al tegen.waarbij de gebruiker kan aangeven of deze wel of niet geladen an worden. Je kan daar wel of niet mee eens zijn. Maar dingen moeten wel bruikbaar blijven naar mij idee.
uitsluiten van mensen ?? ik snap die niet. wie sluit ik uit dan. ?

[Reactie gewijzigd door trisje op 23 juli 2024 14:46]

[Verwijderd]

Bovendien gaat het hier helemaal niet om het insluiten van plaatjes. Maar om het halen van data uit mail. die hier wordt misbruikt.

En... insluiten plaatjes / media levert geen data op? Even nadenken voor je onzin verkondigd.

Dorank in 'nieuws: Onderzoekers: stop direct met gebruik pgp vanwege lekken -...

[trisje]

Ik vind je nogal al een onsympathieke persoonlijkheid hebt. Je reacties zijn telkens van jij ben dom en ik weet het. Een eigenschap die wel meer IT hebben helaas.
Nou welke data kan je dan krijgen uit het mailtje met dat plaatje. Ja je kan zien dat het mailtje geopend is en misschien nog door wie. Maar de mail lezen is een ander verhaal. Bovendien, de gene die de mail verstuurd weet de inhoud. Dus of dit nu een groot probleem is.

[SuperDre]

Aan de andere kant vraag ik me dan af waarom het bij html wel een probleem is en bij plaintext niet, immers is html ook gewoon text die encrypted wordt en dan decrypted..

[wica]

The topic of that paper is that HTML is used as a back channel to create
an oracle for modified encrypted mails. It is long known that HTML
mails and in particular external links like <img href="tla.org/TAG"/>
are evil if the MUA actually honors them (which many meanwhile seem to
do again; see all these newsletters). Due to broken MIME parsers a
bunch of MUAs seem to concatenate decrypted HTML mime parts which makes
it easy to plant such HTML snippets.

Maar dit is geen probleem voor PGP, maar de e-mail client.

[Terrestrial]

inderdaad, het zou helemaal niet mogen uitmaken of een mail html is of niet. Iets wat je versleuteld wordt onleesbare soep ongeacht wat het is.

[goarilla]

Wie gebruikt er dan ook html mail ipv plaintext mail

Iedereen buiten sommige van ons.

[Mythling]

Het lijkt weer een storm in een glas water. Deze kwetsbaarheid heeft weinig met PGP zelf te maken, maar meer in fouten in mail client implementaties. Het lijkt een trend te worden, gevonden kwetsbaarheden groots aankondigen terwijl de impact eigenlijk vrij beperkt is.

https://twitter.com/GossiTheDog/status/995949985823952896

[Cronax]

Ach, beter zo dan omgekeerd...de trend in het verleden was om grote kwetsbaarheden niet of nauwelijks aan te kondigen en liefst een beetje te doen alsof er niets aan de hand was. Dan zie ik liever dat er harder geroepen wordt dan nodig...

[farmertjes]

Het gevaar is wel dat je een "the boy who cried wolf" effect creëert. Wat moet je roepen als er echt iets met een grote impact vind.

[Maurits van Baerle]

Ik denk dat het verschil is dat bij The Boy Who Cried Wolf hij steeds voor hetzelfde waarschuwde. Bij de reeks security en privacy waarschuwingen van de afgelopen jaren was het steeds een ander onderwerp.

Het begon met encryptiebibliotheken en die zijn daarna zo'n allemaal ofwel afgeserveerd ofwel flink onder handen genomen. Een aantal waarschuwingen verder zijn nu emailclients aan de beurt. Het is steeds een andere groep developers die ineens aan de slag moet om gaten te dichten.

[Verwijderd]

Ach, beter zo dan omgekeerd...de trend in het verleden was om grote kwetsbaarheden niet of nauwelijks aan te kondigen

Ik zag net dat er op Teletekst melding wordt gemaakt van deze bug.
Ik moet er toch aan wennen. Ik had in 1990 niet gedacht dat een bug in PGP het gewone nieuws zou bereiken.