Facebook test encryptie in Messenger

Facebook is begonnen met het testen van encryptie in zijn chat-app Messenger. Dat heeft het sociale netwerk bekendgemaakt. Eerder schakelde Facebooks dochterbedrijf WhatsApp end-to-end-encryptie in voor alle gebruikers.

Facebook maakt een functie met de naam Secret Conversations, waarin berichten end-to-end versleuteld zijn. Dat doet het niet voor alle chats, omdat veel gebruikers berichten op verschillende apparaten ontvangen. Dat is problematisch voor end-to-end-encryptie, zegt Facebook. Daarmee lijkt het sociale netwerk uit te sluiten dat het alle berichten zal versleutelen in de dienst.

Het Amerikaanse bedrijf start met Secret Conversations bij een beperkte groep gebruikers, maar het zal in de loop van de zomer het aantal gebruikers uitbreiden. Daardoor moeten uiteindelijk alle negenhonderd miljoen gebruikers van de dienst een Secret Conversation kunnen starten.

Voor de encryptie gebruikt Facebook Messenger net als WhatsApp het Signal-protocol van Open Whisper Systems. Dat protocol zit ook in Open Whispers eigen chat-app Signal.

Reacties (114)

[Verwijderd]

De encryptie is een goede stap, alleen is het wel zo dat de meta data helemaal versleuteld wordt. Dat is in ieder geval zo bij Whatsapp. Dus met wie je wanneer een babbeltje had, is gewoon op te vragen met de juiste rechterlijke machtigingen. TL;DR

But it’s important to keep in mind that, even with the Signal protocol in place, WhatsApp’s servers can still see messages that users send through the service. They can’t see what’s inside the messages, but they can see who is sending a message to whom and when. And according to the WhatsApp privacy policy, the company reserves the right to record this information, otherwise known as message metadata, and give it to governments:

WhatsApp may retain date and time stamp information associated with successfully delivered messages and the mobile phone numbers involved in the messages, as well as any other information which WhatsApp is legally compelled to collect.

Bron: https://theintercept.com/...ow-signal-beats-whatsapp/

De enige die het echt goed voor elkaar heeft is Open Whisper met haar chatapp Signal.

Bruce himself geeft op https://www.schneier.com/...6/06/comparing_messa.html het volgende advies:

"Don't use Telegram."

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:28]

[WhatsappHack]

Nee dat je Telegram niet moet gebruiken als je veiligheid zoekt is al tijden bekend, al willen door goede (misleidende) marketing en de underdog positie veel mensen dat absoluut niet horen.

Meta-data is idd niet versleuteld, dat gaat ook niet in de setup van WhatsApp.
Bij Signal trouwens volgens mij ook niet, want de server daar moet ook weten waar t bericht heen moet... WhatsApp gebruikt ook volledig de double-ratchet en diens implementatie, wat dat betreft is dat gedeelte hetzelfde als Signal. (Sterker nog: Moxie heeft t zelf in WhatsApp ingebouwd ) Je kan echter wel een eigen server instance draaien bij Signal, dat scheelt wel...

Het grote voordeel blijft wel dat de inhoud van berichten niet op te vragen, in te zien of te manipuleren valt zonder toegang tot de data op een toestel. Hoewel metadata erg gevaarlijk kan zijn, is t voor mijn huis-tuin-keuken gebruik bijvoorbeeld niet zo boeiend. Het gaat mij er niet zo om dat ze niet weten met wie ik praat, maar het gaat ze gewoon geen donder aan *wat* ik zeg en bespreek. (En nee, voordat iemand erover begint: dat is geen kwestie van verbergen, maar een kwestie van privacywaarborging...)
Voor mensen met hele zware encryptie benodigdheden is dat wel een probleem, maar dan kan je sowieso maar beter P2P gaan babbelen in plaats van met een client-server model.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 19:28]

[Verwijderd]

Het verschil bij Signal is dit:

Signal’s privacy policy is short and concise. Unlike WhatsApp, Signal doesn’t store any message metadata. Cryptographer and Open Whisper Systems founder Moxie Marlinspike told me that the closest piece of information to metadata that the Signal server stores is the last time each user connected to the server, and the precision of this information is reduced to the day, rather than the hour, minute, and second.

[WhatsappHack]

Dat kan, maar dat maakt het nog niet encrypt. Tappen blijft mogelijk indien opgedragen.

Maar dat is iets dat imho niet echt te patchen valt in een client-server opzet... De server weet op een gegeven moment toch waar t heen moet, dus er kan altijd gelogd worden.

Dat Signal het niet doet is natuurlijk een ander verhaal, maar een zwakte blijft een zwakte. En dan moet je dus hopen dat Moxie stalen ballen heeft als ie opeens een secret order krijgt om jou metadata te tappen

Het maakt t systeem niet onveilig trouwens, enkel niet waterdicht; qua metadata. Dus als je leven er vanaf hangt dat die metadata ook niet achterhaald kan worden: ga lekker via TOR oid met daarbovenop nog eens end-to-end encryptie P2P chatten.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 19:28]

[Verwijderd]

:-) Als ik écht privé met iemand wil praten, dan doe ik persoonlijk. In de diepste punt van het bos!

[WhatsappHack]

Ja alleen heeft niet iedereen de vrijheid om ff naar het bos te gaan; laat staan dat ze per se in hetzelfde land zitten. Denk aan spionnen/deserteurs/klokkenluiders en dergelijke.

[Verwijderd]

Ken je Hans Teeuwen conferences
"Hallo kaboutertje!"

[WhatsappHack]

Hehe, ik ken Hans Teeuwen en z'n shows heel goed; maar dit is wel heel erg ver gezocht In de context van dit gesprek kan het prima zijn dat je inderdaad bedoelde dat je gewoon iemand diep in het bos wil ontmoeten waar niemand je kan horen of zien.

[Dr. Prozac]

De reden dat WA metadata _wel_ logt is mogelijk ook omdat een commercieel bedrijf als WA "in harmonie" wil leven met de regering. Wanneer de regering om gegevens vraag, wil WA tenminste iets kunnen geven aan die regering... dit omdat diezelfde regering (met name die van grote landen) in staat is de belangen van WA flink te dwarsbomen.

Tegelijk willen ze ook "in harmonie" leven met de consument... dus zeggen ze tegen ons dat alle data veilig is versleuteld.

[WhatsappHack]

Dat eerste is een goede mogelijkheid, maar ik denk ook dat Facebook baat heeft bij de metadata zodra deze volledig met Facebook gedeeld mag worden. (Noot: nadat gebruiker opt-in toestemming geeft.)
Metadata kan handig zijn om bepaalde verbanden te leggen, en met 1 miljard+ gebruikers kan dat best aantikken.

Overigens zegt WhatsApp dat enkel de chats, media en oproepen encrypted zijn; zij zeggen niets over metadata noch dat "alle data" beveiligd is.
Het is overigens echter al een enorme stap vooruit dat de grootste messaging app ter wereld überhaupt end-to-end encryptie toepast op de inhoud van alle chats, inclusief bijlagen.

[J_Gonggrijp]

Moxie heeft daadwerkelijk minder mogelijkheden dan WhatsApp als het op metadata tappen aankomt. De serverkant bij Signal is namelijk federated, dwz dat er niet één centrale server is en dat er niemand volledige controle heeft over het netwerk. Als ik jou een bericht stuur, gaat dat misschien wel helemaal niet via een server waar Moxie toegang toe heeft. Als Moxie opeens van gedachten veranderd en vindt dat niemand meer versleuteld mag chatten, kan hij ook niet de stekker eruit trekken. WhatsApp heeft al die voordelen niet.

[Verwijderd]

Mijn grote probleem met WhatsApp is dat ik niet kan zien of mijn chat-partner de backup functie heeft ingeschakeld. Ik vermoed dat 99% van mijn chat-partners de backup functie aan heeft staan, de app zeurt er anders bij elke update weer opnieuw over. Als dat inderdaad zo is, is de encryptie zo goed als nutteloos en hebben discussies over de implementatie ook niet zoveel zin meer.

[WhatsappHack]

Daar komt verandering in gelukkig.
Op Android zal in de aankomende versie, en ik dénk dat het er in de beta misschien al inzit, je backups naar Google Drive ook gaan encrypten. (Behalve media zoals fotos en videos, dat volgt later.)

Op iOS zal dit denk ik ook snel volgen..

[aval0ne]

Goh een chatapp maker die het advies geeft om een concurrent niet te gebruiken. Je verwacht het niet. Gevalletje wij van WC Eend ...

[Verwijderd]

Sinds wanneer is Bruce Schneier een chatapp maker?? Gevalletje TL;DR?

[Nees]

Oh, ik dacht dat al over HTTPS ging.... Enkel via je browser dan?
edit: Ok, duidelijk 4x hetzelfde maar anders verwoord

[Reactie gewijzigd door Nees op 22 juli 2024 19:28]

[TwistedMindNL]

End-to-end encryptie is anders dan HTTPS! HTTPS is een versleutelde verbinding tot de server, zodat er moeilijk iemand tussen kan kruipen en die info uit kan lezen (man-in-the-middle aanval). End-to-end encryptie betekent dat het op mijn mobieltje versleuteld wordt, en pas op het mobieltje van mijn contact ontsleuteld kan worden.
Dit betekent dat zelfs de server ertussenin niet kan lezen wat erin staat, terwijl dat bij HTTPS wel het geval is.

[Proxx]

man in de middle kan nog steeds gedaan worden met https.
Jij bedoeld eavesdropping.

[Firefly III]

Man in the middle "kan" gedaan worden met HTTPS, net zoals je "kan" inbreken in het Catshuis.

Het is niet alleen een kwestie van certificaat vervangen. Want niemand geeft zomaar facebook.com uit. Dat betekent dat je het zelf moet doen, maar zo'n certificaat wordt niet vertrouwd door de browser. Dat betekent dat je ook een root-certificaat moet installeren waarmee je doet alsof het certificaat geldig is.

Maar moderne browsers doen aan HPKP waarmee ze dit soort geintjes juist voorkomen. En zo zijn er meer gemene trucjes die een man-in-the-middle aanval tegenwerken.

[MiesvanderLippe]

Echter, mensen klikken op vanalles om maar bij hun messenger uit te komen.

[Firefly III]

Ah yes, magic malware.

Als ze toch op van alles klikken is een keylogger een stuk makkelijker.

[MiesvanderLippe]

Nee dan moet je of de gebruiker op een plek krijgen waar vandaan dat kan of hardware toegang hebben.

[Proxx]

Dat kan prima zo zijn, maar HTTPS in niet de heilige graal tegen MITM.
HTTPS zorgt er voor dat er onderweg niet mee geluisterd word.
Daar is het voor bedoeld.
En zolang 95 procent van de HTTPS implementaties nog kwetsbaar is voor MITM aanvallen blijf ik bij mijn standpunt.

[Reactie gewijzigd door Proxx op 22 juli 2024 19:28]

[Firefly III]

Ja ok maar hoe wil je dan man in de middle doen? Als je niet mee kan luisteren?

[Proxx]

Jij gaat nu uit van een goede implementatie van HTTPS wat volgens mijn bron bij 95% niet het geval is.

De gebruiker is over het algemeen geen raket-geleerde en
Als de gebruiker het al opvalt dat er een groen slotje staat
Dan zal het wel goed zijn volgens de gebruiker!

Maar dat is dus niet altijd waar.

[Armin]

Je hebt in principe gelijk, maar het artikel dat je linkt dat rept van "trivial connection hijacking attacks" overdrijft enorm. Wat ze namelijk bedoelen is dat ze een HTTPS verbinding kunnen provberen te downgraden naar een non-HTTP verbinding en dan hopen dat de client software en/of persoon het niet merkt.

Gelukkig blijtk dit in de praktijk juist heel erg moeilijk, en ook zonder HTST blijken MITM aanvallen erg zeldzaam. Dat neemt niet weg dat HTST we gewenst is, en HTTPS inderdaad geen heilige graal is tegen MITM.

[Yaminike]

Niet om het een of het ander, maar als jij een poging wil doen de data te decrypten zul je eerst een vals certificaat moeten hebben, welk overduidelijk een melding geeft in elke moderne browser omdat ie natuurlijk gewoon een gevalletje nep is.

Ja, je kan de data onderscheppen, maar daar houdt het ook wel een beetje bij op. Of je moet de verbindingen al kunnen downgraden

[Proxx]

Squid https bump bewijst het tegendeel.

Ik stelde niet dat het makkelijk zou zijn.
Ik wees TwistedMindNL alleen op het feit dat de techniek nog steeds mogelijk is en dat https niet de oplossing is voor MITM.
en dat hij eerder eavsdropping bedoelde.

Nokia deed eerder MITM in hun browser.

En zoals hier aangegeven word is ongeveer 95% van de (https) servers kwetsbaar voor MITM attacks.

Ja, je kan de data onderscheppen, maar daar houdt het ook wel een beetje bij op.

Waarom zou je HTTPS of End-to-End gebruiken als het toch niet uit maakt als iemand je data onderschept?

[Reactie gewijzigd door Proxx op 22 juli 2024 19:28]

[ReTechNL]

[...]
Waarom zou je HTTPS of End-to-End gebruiken als het toch niet uit maakt als iemand je data onderschept?

Jij bent zeker ook zo iemand die niets te verbergen heeft?

[Proxx]

https is er voor zodat er niet ongewild mee geluisterd kan worden.

@Yaminike zegt

Ja, je kan de data onderscheppen, maar daar houdt het ook wel een beetje bij op.

HTTPS is er juist voor zodat de data niet onderschept kan worden.

Dus als het onderscheppen van de data je niet uitmaakt kun je net zo goed HTTP gebruiken.

Dus nee ik ben niet zo iemand.
Jij leest niet goed of je begrijpt me verkeerd.

[WhatsappHack]

Waarom zou je HTTPS of End-to-End gebruiken als het toch niet uit maakt als iemand je data onderschept?

... Dat is het hele punt van encryptie, dat iedereen de data kan onderscheppen: maar het vervolgens onmogelijk kunnen lezen.

[Proxx]

dat is dan een andere definitie van data ik snap hem.

Waarom zou je HTTPS of End-to-End gebruiken als het toch niet uit maakt als iemand je (on-versleutelde) data onderschept?

of

Waarom zou je HTTPS of End-to-End gebruiken als het toch iedereen mag weten wat jij aan het doen bent.

[Reactie gewijzigd door Proxx op 22 juli 2024 19:28]

[Yaminike]

Squid https bump bewijst het tegendeel.

Squid, en bijv. WireShark, werken niet zonder een root certificaat te installeren op je computer, anders geeft de browser wel degelijk een error dat de verbinding niet veilig is.

Nokia deed eerder MITM in hun browser.

Dit konden zij alleen omdat ze zelf de certificaten konden vertrouwen, omdat ze zelf natuurlijk de browser gemaakt hebben.

[quote]En zoals hier aangegeven word is ongeveer 95% van de https servers kwetsbaar voor MITM attacks. [/qoute]

Dit is inderdaad een 'downgrade' van HTTPS naar HTTP, hier zal het slotje dus ook uit de browser verdwijnen. Dit kan alleen als de gebruiker all expliciet http:// gebruikt ipv https://. De title van dit artikel had dus eigenlijk moeten zijn "100% of HTTPS clients vurlnerable (if they use the web in a certain way)", want met de server gebeurt er uiteindelijk niks.

[quote]Waarom zou je HTTPS of End-to-End gebruiken als het toch niet uit maakt als iemand je data onderschept?[/qoute]

Wellicht omdat je data nog versleuteld is? End-to-End kan je ook gewoon onderscheppen, dat is het punt niet. Zonder de key waar de data me versleuteld is, kan de versleuteling niet ongedaan gemaakt worden.


Overigens heb ik het idee dat er niet helemaal, of helemaal niet, begrepen wordt hoe HTTPS nou werkt en waar het voor bedoelt is.
Kortom, HTTPS bestaat om te voorkomen dat een 3rde partij de data tussen de client en server kan uitlezen. Als een MITM dus echt mogelijk was, is er überhaupt geen reden om HTTPS te gebruiken. Dus stel je zelf de vraag. Waarom gebruiken zoveel sites dan wel HTTPS?

[Proxx]

mijn squid en nokia voorbeelden geven alleen aan dat het mogelijk is.
dat er een certificaat geïnstalleerd moet worden en dat het niet makkelijk is doet er niet toe.

die 95% van de servers die kwetsbaar. zijn wel een groot probleem voor jan met de pet (normale gebruikers)

Wellicht omdat je data nog versleuteld is? End-to-End kan je ook gewoon onderscheppen, dat is het punt niet. Zonder de key waar de data me versleuteld is, kan de versleuteling niet ongedaan gemaakt worden.

Daar begreep ik jou definitie van 'data' verkeerd.
ik ging bij data uit van onversleutelde gegevens.

[tomk94]

HTTPS is wat anders dan End-to-end encryption. HTTPS versleuteld de verbinding tussen je appraat en de servers van Facebook.

End-to-end encryption versleuteld de berichten tussen de verzender en ontvanger van het bericht.

Het verschil is dat bij HTTPS Facebook de berichten zelf ook nog kan lezen. Bij end-to-end encryption in theorie niet, dan kunnen alleen de verzender(s) en ontvanger(s) het lezen.

[RobinF]

Bij HTTPS is mijn verbinding met Facebook en jouw verbinding met Facebook geëncrypt.
Met E2E-encryptie is de verbinding tussen mij en jou geëncrypt en kan Facebook er totaal niet bij. Ik weet dus zeker dat alleen jij het bericht ontvangt

[borft]

Dat is niet helemaal waar. Je weet zeker dat alleen de ontvanger het kan lezen (decrypten).

[Verwijderd]

Klopt. Dit is een belangrijk verschil waar je best een plusje voor mag krijgen. Berichten die nu niet ontsleutelt kunnen worden kunnen dat in de toekomst misschien wel. Gesprekken die je als tiener veilig denkt te voeren kunnen dus best ergens op het hoogtepunt van je carriere opeens uitlekken, mocht iemand de versleutelde berichten hebben bewaard.

[Ventieldopje]

Dat is in principe ook end to end maar alleen van client (jij, versleuteld) -> server (fb, ontsleuteld) -> client (iemand, versleuteld). Met deze end-to-end bedoelen ze van client naar client versleuteld zonder dat Facebook de keys heeft.

[Proxx]

Met deze end-to-end bedoelen ze van client naar client versleuteld zonder dat Facebook de keys heeft.

wie zegt dat fb die sleutels niet heeft?
dat is een gevaarlijke aanname!

in de ideale wereld zou het zo wel moeten zijn idd.

[Ventieldopje]

Ik snap niet waarom het offtopic gemodereerd wordt maargoed. Dat is het basisprincipe van end-to-end encryptie en ook omschreven in de paper die Facebook heeft gepubliceerd waarin ze hun implementatie van Signal uitleggen:

Pagina 4: "Keys
Each device manages various cryptographic keys. All keys are generated
or derived on-device. Private keys are never sent to Facebook."

Bron: https://fbnewsroomus.file...versations_whitepaper.pdf en https://whispersystems.org/blog/facebook-messenger/

[Skoucail]

Is er iets mis met de end-to-end encryption bij imessage?
Want Apple slaagt er wel in om dacht ik end-to-end encrypted messages naar alle geregistreerde devices te sturen.
Dit blijft voor Whatsapp en nu blijkbaar ook FB een probleem...

[Aaargh!]

Is er iets mis met de end-to-end encryption bij imessage?
Want Apple slaagt er wel in om dacht in end-to-end encrypted messages naar alle geregistreerde devices te sturen.

Bij iMessage wordt het bericht voor elk ontvangend apparaat apart encrypted. Elk iDevice dat je hebt stuurt z'n public key op naar Apple welk deze weer doorstuurt naar degene die jou een bericht wil sturen. Als je vervolgens een bericht stuurt naar iemand met X iDevices worden er eigenlijk X identieke berichten gestuurd.

[Skoucail]

Ik dacht inderdaad dat het zo gebeurde.
Maar is er dan een reden waarom deze manier van werken niet wordt overgenomen door andere gelijkaardige diensten? Want dat is toch een van de meest genoemde nadelen van end-to-end encryptie dat men het bericht niet op alle devices kan lezen.

[borft]

Als elk apparaat de PK van Apple krijgt, dan is er niets dat Apple ervan weerhoudt om een andere PK te sturen, en lekker man-in-the-middle te gaan spelen

Maar ik ben het wel met je eens dat het veel praktischer is

[Skoucail]

Dus bij een systeem met het signal-protocol wordt de publieke key peer to peer verstuurd?
Want als alles via FB verloopt dan kunnen ze toch even hard man-in-the-middle spelen?

[Armin]

Want als alles via FB verloopt dan kunnen ze toch even hard man-in-the-middle spelen?

Ze kunnen ook een backdoor in de client bouwen. Als je Facebook niet gebruikt moet je hun client/netwerk niet gebruiken. UIteindelijk moet je namelijk *iets* vertrouwen.

Zelfs die signal-apps zijn vaak binary downloads en moet je vertrouwen dat het echt van de source gemaakt is.

[borft]

Hmm, dat is een goeie vraag. De meest veilige manier is om een vertrouwde infrastructuur te gebruiken om public keys te distribueren Of om elkaars keys te signen, zodat je meer zekerheid hebt over de identiteit van iemand.

Volgens mij zit het zwakke punt erin, dat er geen mechanisme is om te verifieren of de key die je van de ander krijgt, ook daadwerkelijk van die ander is

[Skoucail]

Inderdaad.
Dus komt het er op neer om de persoon die de keys uitwisselt te vertrouwen. En zie ik dus geen reden waarom een systeem zoals Apple heeft voor imessage (multi device deel) niet overgenomen wordt door andere aanbieders (whatsapp/fb)
Want denk dat we alle 2 akkoord gaan dat dit pak praktischer is

Net wel even over Signal gelezen. Daar zitten er paar build-in functie in tegen man-in-the-middle attacks. Maar opnieuw zijn deze "makkelijk" te omzeilen doordat men zelf de app/site maakt en dus kan displayen wat men wil. (Komt er op neer dat je van de afzender een fingerprint kan zien en deze dan via een andere weg (mail/telefoon) kan vergelijken.

Denk de enigste manier om een mitm attack 100% te voorkomen is als je op een secure manier zelf de key uitwisselt.

Risico kan verkleind worden als alles opensource zou zijn ook. Maar denk niet dat Facebook daar snel ga aan meedoen

[Reactie gewijzigd door Skoucail op 22 juli 2024 19:28]

[borft]

Jep. Zelfs als het opensource wordt, is het nog steeds lastig om het probleem van het key uitwisselen op te lossen (alleen wordt het dan duidelijker hoe het protocol het precies implementeert). Uiteindelijk is de meest veilige manier, de ouderwetse, key-signing parties... (zoals we dat vroeger deden met GPG/PGP keys)

[Skoucail]

Bij opensource software kun je wel zien dat de fingerprint die getoond wordt gegenereerd wordt op basis van de publieke key die op je device staat en bijvoorbeeld niet opgehaald wordt met een web service zodat de 3de partij kan tonen wat deze wil.
Dan is het wel nog steeds aan de gebruiker om de fingerprint manueel te controleren via een ander kanaal.

Inderdaad bij GPG/PGP heb je mooi de opsplitsing tussen het systeem die keys uitwisselt (veelal zelfs decentraal) en het systeem die de berichten verstuurt. Waardoor het bijna onmogelijk is om een mitm attack uit te voeren.

[.oisyn]

Of om elkaars keys te signen, zodat je meer zekerheid hebt over de identiteit van iemand.

Voor het verifiëren van een signature heb je weer de public key van de auteur nodig. Het probleem was nou juist dat de partij die jou die key heeft gegeven mogelijk comprimised is. Signing werkt dus alleen als er al een vertrouwde key distribution aanwezig is, of je gebruik kan maken van een betrouwbare derde partij (die dan de boel kan signen)

[Reactie gewijzigd door .oisyn op 22 juli 2024 19:28]

[Aaargh!]

Er zit een potentieel security probleem in het mechanisme zoals Apple dit gebruikt. Omdat Apple de public keys beheert kunnen ze makkelijk een extra key toevoegen en vanaf dat moment kunnen ze elk nieuw bericht lezen.

[Armin]

Klopt, maar dat is een gevaar met elke key-server. WhatsApp werkt ook zo bij Group Chats en heeft ditzelfde potentiele gevaar.

Je kunt overigens bij iMessage met een netwerk sniffer zien welke public keys voorgeschoteld worden. Dus je kunt kijken of er exra zijn en/of nieuwe/onverwachte. Niet voor de gewone leek of zelfs menig Tweaker, maar er zijn genoeg argwanende mensen dat Apple dit niet zal doen. Bij ontdekking is het namelijk een enorm verlie svan vertrouwen.

[MajorMuff]

Is het niet zo dat wanneer de sleutel via Apple wordt verstuurd, Apple in feite ook vrij makkelijk je berichten kan ontsleutelen? Of denk ik dan te makkelijk?

[Aaargh!]

Dat denk je te makkelijk inderdaad. Het gaat hier om public-key encryptie. Bij public-key encryptie worden er 2 sleutels gemaakt, een publieke en een private sleutel. De publieke key mag iedereen weten, die kan je van de daken schreeuwen of groot in de krant afdrukken, dat maakt niets uit. Sterker nog: je wilt dat iedereen die key weet.

Met te publieke sleutel kan je alleen encrypten, niet decrypten. Om te decrypten heb je de private key nodig en die houdt je uiteraard geheim. Verder is het ook mogelijk om met de private key iets te ondertekenen en dan met de publieke key te controleren of dat inderdaad ondertekend is door de private key die hoort bij de publieke key. Dit is hoe b.v. SSL certificaten werken.

[.oisyn]

Nou denk jij weer iets te makkelijk. Als Alice haar public key wilt sturen naar Bob, maar dat doet via een derde partij (Charlie aka Apple), dan kan Charlie gewoon een ándere public key aan Bob geven waar hij wel de private key van heeft. Als Bob dan een bericht wil sturen naar Alice, dan versleuteld hij dat met de public key waarvan hij denkt dat die van Alice is. Dat kan Charlie dan ontsleutelen en opnieuw versleutelen met Allice' daadwerkelijke private key.

[Reactie gewijzigd door .oisyn op 22 juli 2024 19:28]

[WhatsappHack]

Dat gaat toch enkel werken bij unauthenticated encryptie...?

[.oisyn]

Authentication werkt alleen als je zeker weet dat iemands public key ook echt van hem is, dus daarvoor moet je eerst op een betrouwbare manier sleutels hebben uitgewisseld. Er is een trusted third party nodig die verder geen inzage heeft in de berichten die je onderling kunt versturen.

[WhatsappHack]

Je moet betrouwbaar sleutels hebben uitgewisseld, en/of kijken of de sleutels wel overeenkomen... Bij de laatste optie heb je geen TTP nodig, maar wel out-of-band verificatie.

[Aaargh!]

Klopt, dat scenario had ik net uitgewerkt in een andere reactie eindje verderop.

Uiteindelijk moet je OF face2face keys gaan uitwisselen OF op een of andere manier gebruik maken van een TTP. Die TTP hoeft natuurlijk niet Apple te zijn (b.v. je laat je public key signen door een andere partij), en dan is een key-exchange via iMessage wel veilig. Er zijn meerdere manier waarop je de authenticiteit van een public key met redelijke zekerheid zou kunnen vaststellen. Helaas nog niet in iMessage.

[Skoucail]

Zie ook wel de posts hierboven tussen borft en mezelf.
Tenzij we iets missen is een man-in-the-middle attack ook mogelijk (bij alle systemen)

[Aaargh!]

MitM door Apple is in praktijk nu mogelijk ja. De manier waarop dit op te lossen zou zijn is door de public keys te laten ondertekenen door een TTP.

Overigens hoeft Apple geen MitM te doen, ze kunnen ook een extra public key aan jouw iMessage account koppelen.

[Reactie gewijzigd door Aaargh! op 22 juli 2024 19:28]

[MajorMuff]

Goed verhaal, dank!

[Verwijderd]

Technisch detail, maar ik neem aan dat een bericht maar één keer wordt encrypted met een (random) symmetrische key, en dat alleen die key meerdere malen wordt encrypted, met de public keys van elk apparaat.

[Aaargh!]

Lijkt me logisch maar of ze dat ook daadwerkelijk doen weet ik niet.

[Mic2000]

Dus als je een secret conversation begint weet Facebook direct dat het een belangrijk gesprek is? Met het signal-protocol weten we toch nog steeds niet of er een uitgewisselde key op de servers van fb/WhatsApp bewaard blijft om het alsnog te decrypten?

[YumYum]

Als het goed is staat de private key alleen op jou eigen telefoon (en in de iCloud voor backup )

[Aaargh!]

Dat wil niet zeggen dat Facebook geen MitM attack kan uitvoeren.

[YumYum]

Bij end-to-end encryptie kun je zonder private key's geen mitm uitvoeren.

Maar Facebook kan altijd een software update maken waarbij jouw private key geupload wordt naar de fb-server. Of de FBI kan apple even vragen om je key uit de iCloud. Vraag is hoeveel druk Facebook moet krijgen om dit uit te voeren, maar het blijft software...

Mitm is meer voor ssl verkeer waarbij je certificaten manipuleert, bijvoorbeeld door een eigen root certificaat op je slachtoffer zijn machine te zetten. Dan kun je idd als proxy er tussen gaan zitten en al het SSL-verkeer uitpakken.

[Aaargh!]

Bij end-to-end encryptie kun je zonder private key's geen mitm uitvoeren.

Alice genereert een keypair met private key K_A en public key P_A en stuurt P_A naar de server van Facebook.
Bob genereert een keypair met private key K_B en public key P_B en stuurt P_B naar de server van Facebook.
Facebook genereert een keypair met private key K_E en public key P_E.

Alice en Bob willen veilig communiceren via Facebook en Alice vraagt aan FB de public key van Bob op. Facebook antwoord met P_E. Bob vraagt de public key van Alice op en Facebook antwoord met P_E.

Alice stuurt een bericht naar Bob en encrypt deze met P_E, Facebook ontvangt dit bericht, decrypt deze met K_E , slaat de plaintext op en encrypt vervolgens met P_B. Bob ontvangt het bericht en decrypt met K_B en ziet niet dat Facebook het bericht heeft afgeluisterd.

Bij end-to-end encryptie is wel degelijk een MitM attack mogelijk als je geen manier hebt om te garanderen dat je daadwerkelijk de juiste public key gebruikt. Normaliter gebruik je hiervoor een TTP (Trusted Third Party) die je verzekerd dat je de juiste key hebt. In het geval van FB Messenger is Facebook de TTP, als je Facebook niet vertrouwd dan is het game over.

[YumYum]

Ben ik niet met je eens: Facebook is geen TTP. Als de software correct geïmplementeerd is zijn de keys alleen bekend op de twee end-devices.

Het is ook de bedoeling dat je de public key van de contactpersoon vergelijkt met de key die in jou contactpersonen staat. Bij whatsapp (welke eenzelfde opzet heeft) staat bijvoorbeeld onder encryptie een (bar)code welke je moet vergelijken.

Als je de codes vergelijkt zou je *redelijk* veilig moeten kunnen communiceren...

[Verwijderd]

Ben ik niet met je eens: Facebook is geen TTP. Als de software correct geïmplementeerd is zijn de keys alleen bekend op de twee end-devices.

Hoe komen die twee end-devices met elkaar in verbinding? Hoe wisselen die veilig hun keys onderling uit?

Het is ook de bedoeling dat je de public key van de contactpersoon vergelijkt met de key die in jou contactpersonen staat. Bij whatsapp (welke eenzelfde opzet heeft) staat bijvoorbeeld onder encryptie een (bar)code welke je moet vergelijken.

Zonder elkaar face to face te ontmoeten kan dat niet.

Daarnaast zijn Whatsapp en Messenger ook nog eens closed source, dus ook al heb je echt elkaars key (en geen man in the middle key van Facebook) dan nog kun je niet uitsluiten dat die keys niet lekken naar Facebook.

[WhatsappHack]

Hoe komen die twee end-devices met elkaar in verbinding? Hoe wisselen die veilig hun keys onderling uit?

Daar weet je het antwoord toch wel op?
Bij een key-exchange moet het in principe niet uitmaken wie er allemaal tussenin gaat zitten, mits de sleutels zelf veilig genoeg zijn en er een up to date proces wordt gebruikt voor deze zaken.

Je kan een key-exchange natuurlijk al prima uitvoeren op een geheel unencrypted verbinding, en met de juiste algoritmen kan je er tussenin gaan zitten wat je wil en te proberen te manipuleren hoe je wilt: maar dan nog wordt het heel erg lastig tot bijna onmogelijk om het voor elkaar te krijgen **mits er ook authenticatie plaatsvindt**.

Daarnaast zijn Whatsapp en Messenger ook nog eens closed source, dus ook al heb je echt elkaars key (en geen man in the middle key van Facebook) dan nog kun je niet uitsluiten dat die keys niet lekken naar Facebook.

Dat kan je bij open-source ook niet per definitie zeker weten, noch of er lekken inzitten... En dan heb je ook nog het probleem dat je andere software op je telefoon ook moet vertrouwen, de fabrikant moet vertrouwen, third-party drivers, de maker van het OS; en in elke layer kan potentieel een lek zitten dat jou het leven zuurt maakt. Open-source is niet per definitie veiliger can closed-source; en andersom is closed-source niet perse onveiliger can closed-source; alleen heeft open-source het nadeel vaak onterecht als veel veiliger en betrouwbaarder aangezien te worden.

Maar die discussie hebben we al eens uitgebreid gevoerd geloof ik.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 19:28]

[Verwijderd]

Daar weet je het antwoord toch wel op?

Eerlijk gezegd niet?

Zolang je een onveilig communicatiekanaal hebt, weet ik niet hoe je daar veilig keys over kunt uitwisselen (om vervolgens veilig te kunnen communiceren over ongeacht welk kanaal). Ik bedoel dat ik niet weet hoe je met een onveilige lijn kunt uitsluiten dat je eigenlijk de key van een middle man krijgt in plaats van die van je gesprekspartner.

Bij een key-exchange moet het in principe niet uitmaken wie er allemaal tussenin gaat zitten, mits de sleutels zelf veilig genoeg zijn en er een up to date proces wordt gebruikt voor deze zaken.

Dat lijkt mij alleen het geval als ik de keys van de juiste persoon kan onderscheiden van de keys van een middle man. Maar hoe zou ik dat moeten doen? Of in welk opzicht kan een sleutel zelf "veilig genoeg" zijn zodanig dat een kwaadwillende tussenpersoon mij niet een andere net zo "veilig" lijkende sleutel (van zichzelf) kan sturen?

Het is precies het scenario wat Aaargh! hier schetst. Ik moet P_B ontvangen, maar als ik P_B niet ken, hoe weet ik dan of ik echt P_B of eigenlijk P_E voorgeschoteld krijg?

Je kan een key-exchange natuurlijk al prima uitvoeren op een geheel unencrypted verbinding, en met de juiste algoritmen kan je er tussenin gaan zitten wat je wil en te proberen te manipuleren hoe je wilt: maar dan nog wordt het heel erg lastig tot bijna onmogelijk om het voor elkaar te krijgen **mits er ook authenticatie plaatsvindt**.

Hoe zou die authenticatie plaats moeten vinden?

Dat kan je bij open-source ook niet per definitie zeker weten, noch of er lekken inzitten... En dan heb je ook nog het probleem dat je andere software op je telefoon ook moet vertrouwen, de fabrikant moet vertrouwen, third-party drivers, de maker van het OS; en in elke layer kan potentieel een lek zitten dat jou het leven zuurt maakt. Open-source is niet per definitie veiliger can closed-source; en andersom is closed-source niet perse onveiliger can closed-source; alleen heeft open-source het nadeel vaak onterecht als veel veiliger en betrouwbaarder aangezien te worden.

Maar die discussie hebben we al eens uitgebreid gevoerd geloof ik.

Klopt

[WhatsappHack]

Eerlijk gezegd niet?

Zolang je een onveilig communicatiekanaal hebt, weet ik niet hoe je daar veilig keys over kunt uitwisselen (om vervolgens veilig te kunnen communiceren over ongeacht welk kanaal). Ik bedoel dat ik niet weet hoe je met een onveilige lijn kunt uitsluiten dat je eigenlijk de key van een middle man krijgt in plaats van die van je gesprekspartner.

.......

Het is precies het scenario wat Aaargh! hier schetst. Ik moet PB ontvangen, maar als ik PB niet ken, hoe weet ik dan of ik echt PB of eigenlijk PE voorgeschoteld krijg?

Hoe zou die authenticatie plaats moeten vinden?

Dat weet je niet perse, en dat is ook een kwetsbaarheid in DH. Bij STS is dit al moeilijker als ik het me goed herinner. (Pin me er niet op vast.)

Echter; er van uitgaande dat je de server of iets op de route niet vertrouwd, is het daarom van belang om of een certificaat te gebruiken (dus inderdaad een derde partij vertrouwen) of de vingerafdrukken van de sleutels Out-of-Band met elkaar te vergelijken (een beetje zoals two-factor authentication ); dus bijvoorbeeld zoals WhatsApp dat doet door je de optie te geven om de fingerprints van de sleutels met elkaar te vergelijken of een barcode te scannen. Dan kan jij zien of je wel werkelijk P_b hebt gekregen, of blijkt opeens dat je P_e hebt. In dat laatste geval ontstaat een mismatch tussen de fingerprints en weet je dus dat er stront aan den spreekwoordelijke knikker is; en zo kan je dus uitsluiten of je wel de goede sleutel hebt gekregen en zo vindt de authenticatie/verificatie plaatst.

Door authenticatie/verificatie van de sleutels toe te passen, is het overigens niet per definitie onmogelijk om een slachtoffer te worden van een MITM; maar wordt de MITM wel bijzonder makkelijk detecteerbaar waardoor je stappen kan ondernemen (niet gaan chatten, of stoppen met chatten als de sleutel onverwacht wijzigt.). Uiteraard is het 't beste als je de vergelijking buiten de niet-vertrouwde server/hop om doet.

Of zie ik iets over het hoofd?

Overigens, bij WhatsApp wordt ook nog eens extra beveiligd door een symmetrische sleutel te ratcheten. Hier is timing wel van belang: het is onmogelijk om op een later moment nog een MITM te beginnen, en *moet* tijdens de eerste exchange al gebeuren.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 19:28]

[Verwijderd]

Dat weet je niet perse, en dat is ook een kwetsbaarheid in DH. Bij STS is dit al moeilijker als ik het me goed herinner. (Pin me er niet op vast.)

Kijkend naar de beschrijving van dat protocol op die wikipedia pagina, zou ik niet weten waarom de standaard middle man attack (Eve doet zich naar Bob voor als Alice, en naar Alice als Bob) niet zou werken (of zelfs maar moeilijker zou zijn) in dat scenario?

Echter; er van uitgaande dat je de server of iets op de route niet vertrouwd, is het daarom van belang om of een certificaat te gebruiken (dus inderdaad een derde partij vertrouwen) of de vingerafdrukken van de sleutels Out-of-Band met elkaar te vergelijken (een beetje zoals two-factor authentication ); dus bijvoorbeeld zoals WhatsApp dat doet door je de optie te geven om de fingerprints van de sleutels met elkaar te vergelijken of een barcode te scannen.

Ja precies, dat bedoelde ik met "Zonder elkaar face to face te ontmoeten kan dat niet". Met Whatsapp heb je geen authenticatie, en ook geen out-of-band communicatiekanaal tenzij je elkaar live ontmoet en ter plekke elkaars public key controleert.

Of zie ik iets over het hoofd?

Whatsapp (of welke communicatie tool dan ook) blijft met het probleem zitten dat je over een onveilige lijn, in essentie geen veilige communicatie kunt opzetten.

Certificering is op gevallen zoals Whatsapp niet van toepassing, en is eigenlijk ook maar een matige oplossing: het hangt toch weer van trusted third parties af (waarvan de betrouwbaarheid soms zeer te wensen overlaat) en de authenticatieprocedure is altijd een compromis tussen veiligheid en gemak. Als je al een CA vertrouwt, hoe kunnen zij dan op afstand 100% veilig nagaan dat jij écht jij bent?

Overigens, bij WhatsApp wordt ook nog eens extra beveiligd door een symmetrische sleutel te ratcheten. Hier is timing wel van belang: het is onmogelijk om op een later moment nog een MITM te beginnen, en *moet* tijdens de eerste exchange al gebeuren.

Tja zo'n ratchet voegt in de praktijk volgens mij bijzonder weinig veiligheid toe. Een MITM moet sowieso al tijdens de eerste key exchange gebeuren, zodra je eenmaal elkaars public key hebt kunt je voortaan altijd veilig communiceren, een derde kan de boel later niet meer faken.

Ook de forward secrecy vormt voor zover ik kan zien slechts een marginaal verschil (maar misschien zie ik ook iets over het hoofd?)
Encrypted communicatie opslaan en later proberen te kraken, tja leuk dat je dan per bericht een verschillende sleutel hebt (in plaats van één vaste sleutel voor alles) maar zodra je een vroeger bericht decrypt kun je daarmee ook de forwarding key exchanges en dus latere berichten ontcijferen.
Uiteindelijk komt het er toch op neer dat je één keer een cruciaal gegeven uitwisselt (de eerste key exchange) en alle latere keys en communicatie hangen in essentie alleen daar vanaf.

[WhatsappHack]

Ja precies, dat bedoelde ik met "Zonder elkaar face to face te ontmoeten kan dat niet". Met Whatsapp heb je geen authenticatie, en ook geen out-of-band communicatiekanaal tenzij je elkaar live ontmoet en ter plekke elkaars public key controleert.

Natuurlijk wel.
Je kan een screenshot maken van de (eventueel encrypted) barcode en via dropbox, mms of wat dan ook versturen. Je kan bellen en de code opnoemen, de code via SMS of zelfs per post versturen; of zelfs met een PBtje via Tweakers. Zat mogelijkheden zonder elkaar face to face te ontmoeten natuurlijk. En dat kan je zelf nog zo veilig maken als je wilt.

Whatsapp (of welke communicatie tool dan ook) blijft met het probleem zitten dat je over een onveilige lijn, in essentie geen veilige communicatie kunt opzetten.

Dat is afhankelijk van de verificatie imho.

Certificering is op gevallen zoals Whatsapp niet van toepassing, en is eigenlijk ook maar een matige oplossing: het hangt toch weer van trusted third parties af (waarvan de betrouwbaarheid soms zeer te wensen overlaat) en de authenticatieprocedure is altijd een compromis tussen veiligheid en gemak. Als je al een CA vertrouwt, hoe kunnen zij dan op afstand 100% veilig nagaan dat jij écht jij bent?

Dat ligt eraan hoe ver je wilt gaan eigenlijk... Een standaard certificaatje zoals je dat bijvoorbeeld bij SSL ziet met domain verification dan weten ze niet wie er precies achter zit maar kunnen ze enkel het domein garanderen. Bij EV certificering gaat een behoorlijk proces aan vooraf waar van alles gecontroleerd wordt, je allerlei documenten moet opsturen, et cetera. Natuurlijk blijft er een factor voor ruimte; maar dat wordt aardig gereduceerd.
Maar nee, een CA is niet ideaal noch helemaal waterdicht.
Eigenlijk ook bedoeld voor andere doeleinden.

Tja zo'n ratchet voegt in de praktijk volgens mij bijzonder weinig veiligheid toe.

Ook de forward secrecy vormt voor zover ik kan zien slechts een marginaal verschil (maar misschien zie ik ook iets over het hoofd?)

In tegendeel, het is een enorme toevoeging omdat je inderdaad PFS en Future Secrecy toevoegt. De computer kracht die benodigd is om een heel gesprek te decrypten bestaat op dit moment gewoon niet...

Encrypted communicatie opslaan en later proberen te kraken, tja leuk dat je dan per bericht een verschillende sleutel hebt (in plaats van één vaste sleutel voor alles) maar zodra je een vroeger bericht decrypt kun je daarmee ook de forwarding key exchanges en dus latere berichten ontcijferen.

Nope, dat is niet mogelijk zonder opnieuw de sleutel te gaan berekenen. Misschien dat de entropie lager wordt en het iets gemakkelijker is om te kraken (mits je het eerste bericht te pakken hebt), maar daar houdt het wel op eigenlijk... Maar voor zover ik weet is zelfs dat niet het geval, die session key is enkel bekend bij de twee apparaten die met elkaar babbelen en daar wordt doorheen geknald; die wordt niet of slechts deels meegezonden met het bericht. Omdat de key uniek is voor elk bericht, kan je dus niet zien aan bericht A wat de sleutel voor bericht B gaat worden zonder een enorm computing vermogen en dan maar bidden dat je het kraakt.

Een MITM moet sowieso al tijdens de eerste key exchange gebeuren, zodra je eenmaal elkaars public key hebt kunt je voortaan altijd veilig communiceren, een derde kan de boel later niet meer faken.

Dat is afhankelijk van het protocol... Alles valt en staat bij de sterkte van de sleutels.
Er zijn aanvallen mogelijk waarop een tussenliggend systeem toch een MiTM kan uitvoeren op een later moment. Een bekend voorbeeld daarvan is een probleem in MProto van Telegram waardoor met een relatief gezien simpele birthday-aanval een hash-collission uitgevoerd kan worden en de server er zo alsnog een MiTM op kan uitvoeren en zelfs de fingerprints kan vervangen. Helaas is dit overigens slechts een van de voorbeelden van problemen met MProto, maar dat terzijde.
En dan is er nog het probleem van eavesdropping op zwakke protocols, uiteraard. Het ligt gewoon aan hoe goed de crypto is hoe veilig je bent.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 19:28]

[Verwijderd]

Als het goed is, ja. Maar het is closed source software, dus uiteindelijk weet je dat nooit zeker.

Ze hoeven er zelfs niet eens iets voor te verzenden. Misschien zit er een onherkenbare maar doelbewuste zwakheid in het genereren van de keys waardoor facebook ze (met kennis van die specifieke zwakheid) kan brute forcen. En er zijn nog talloze andere manieren waarop dit lek kan zijn, zonder dat je dat uit de werking van de app of de datacommunicatie kan afleiden.

[YumYum]

Klopt. En ook al zou de implementatie helemaal goed zijn dan heeft de NSA nog wel ergens een GPU cluster, kwantum computer of forest gump die alsnog private key kan terugvinden uit de public key & data

[Verwijderd]

Ja maar dát geloof ik dan weer niet, fatsoenlijke AES encryptie met een key met voldoende entropie (d.w.z. 256 random bits) gaat niemand kraken. Ook de NSA met een supercluster en een leger autisten niet.

[WhatsappHack]

Daar hebben ze een trucje op gevonden... WhatsApp bijvoorbeeld maakt gebruik van Future Secrecy en Perfect Forward Secrecy. (Meer info? Lees de tech-sheets van WhatsApp en double-ratchet (voorheen AXOLOTL)). Dat wil zeggen dat als je van één bericht de sleutel weet te achterhalen, je met die sleutel enkel dat bericht kan ontsleutelen. Berichten uit het verleden én nieuwe berichten in de toekomst gebruiken een andere key.

Het is al bijna ondenkbaar dat iemand de sleutel weet te kraken, maar ALS het ze lukt om een bericht te kraken: dan hebben ze alsnog enkel wat aan de sleutel voor dat specifieke bericht... En gezien de hoeveelheid mazzel die je moet hebben om de sleutel voor 1 berichtje te achterhalen, lijkt het me stug dat het echt een actieve aanval kan zijn om constant mee te luisteren.

Doordat er dus meerdere "lagen" encryptie (om het zo even te noemen, want praktisch is het iets compleet anders.) met die sleutel worden toegepast maakt het onmogelijk om de originele private key te berekenen. Met de huidige technologie dan tenminste he. Wie weet hoe dat over 10 jaar is; en of ze de berichten van nu bewaren om het dan nog eens te proberen te kraken.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 19:28]

[Proxx]

Wow, eerst is iedere smartphone een iPhone, toen werden alle tablets iPad's

en nu is iedere "Cloud" een iCloud.

[Skoucail]

De FB server heeft (bij correcte implementatie) alleen de publieke key.
En dus geen private key om de berichten met de decrypten. Wat net het volledige concept is van end-to-end encryptie

[borft]

Maar zoals eerder gezegd, als het uitwisselen van public keys via facebook verloopt, wie belet hun dan om in het midden even de public key te verwisselen voor een andere? En zo dus lekker in het midden alles te gaan zitten afluisteren

[r.elu]

Daarom moet je ook af en toe controleren of de keys matchen (offline). Dit kan gewoon met WA en Signal.

[Skoucail]

Inderdaad (uitgebreidere reactie op je andere post )

[Pixxel]

Wellicht wat offtopic, maar wat mij zou het pas fijn zijn wanneer ze die reguliere chatfunctie eerst weer gewoon beschikbaar maken in mobiele browsers, of de chat app wat minder zwaar maken.
Ik geloof niet dat ik iemand in mijn vriendenkring heb die blij is met het constant naar beneden moeten vegen van die bubbeltjes.

[icratox]

Godzijdank zijn die bubbeltjes uit te schakelen. Als er iets is wat mij zo zwaar irriteerde aan messenger was dat het wel...

[RoelRoel]

Ik heb zo'n hekel aan Facebook Messenger. Die app wordt echt aan je opgedringt. Je kunt bijna geen Facebook gebruiken zonder die app. Een paar weken geleden kon ik de berichten nog via de mobiele site van Facebook lezen, maar die verwijst zelfs nu naar de Play Store. Ik gebruik Facebook alleen via de mobiele site omdat deze ook alles kan en mij niet in een Facebook gevangenis zet zoals de app wel doet. De Facebook app gaat tegen alle basisprincipes van Android in zoals het delen van zaken met andere apps via Intents en het gebruiken van andere apps voor bepaalde functionaliteiten zoals de camera. Nee dat moeten ze allemaal zelf inbouwen zodat je een soort Facebook telefoon krijgt.
Als iemand me nu een privébericht stuurt via Facebook kan ik dit gewoon niet lezen tenzij ik op de desktop Facebook open (wat bijna nooit gebeurt).

[Reactie gewijzigd door RoelRoel op 22 juli 2024 19:28]

[comecme]

Of je laat je mobiele browser de desktopversie van Facebook opvragen. Ziet er hetzelfde uit als de mobiele versie, maar biedt wel chatfunctionaliteit.

[Verwijderd]

Ik vind het onhandig dat ik steeds moet nadenken of een bericht 'geheim' is of niet.

Aan de andere kant zit er wel een Timed Message feature op waarmee je naaktfoto's kan versturen die maar beperkt zichtbaar zijn, a la SnapChat.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:28]

[alwaysleft]

Zie ook in het filmpje over deze functie dat het gesprek nooit op je toestel bewaard kan blijven, maar na een enkele uren zal verdwijnen. Dat is ergerlijk.

[Verwijderd]

Ik vind het niet echt nuttig als het niet voor alle conversaties geldt. Is er niet een manier om veilig de sleutels te delen over alle mogelijke clients?

[borft]

gaat dat niet in tegen het hele principe van de beveiliging? Hoe wil je de private keys veilig gaan distribueren?

[Dreamvoid]

Je zou het via NFC kunnen doen, door de telefoons tegen elkaar te raken.

[stresstak]

Je zou het via NFC kunnen doen, door de telefoons tegen elkaar te raken.

Maar je stuurt je telefoon toch niet naar de ander ? En als je de ander in persoon ziet hoef je de telefoon niet te gebruiken.

[Dreamvoid]

Eenmalig 'pairen' om de keys uit te wisselen, daarna kan je weer veilig berichtjes via het grote boze internet sturen.

[stresstak]

Ja, dat begrijp ik, maar het internet en telefoons zijn juist zo handig als je niet in elkaars buurt woont.
Even pairen wordt lastig bij grotere afstanden tot lieden die je sporadisch of nooit ziet en waarmee je wel belt.

[WhatsappHack]

Het gaat toch om *jou* devices die sleutels moeten uitwisselen; en niet die van de ander?

Wat je wilt, in de context van jullie gesprek (want er zijn betere manieren.), is een veilige methode om jou eigen private key (en eventuele session key counter) te kopiëren naar een tweede device; en dat zou inderdaad best via NFC kunnen. Maar de tegenpartij heeft nog altijd uitsluitend jou ene public key nodig... Je geeft je private key nooit aan iemand anders, en je public key kan je altijd versturen; zelfs over een unencrypted kanaal. Dus het boeit niet hoe ver de tegenpartij wegzit, omdat die de public key nodig heeft; niet je private key. Je kan je public key zelfs integraal hier op Tweakers posten en dan nog kan niemand er ene hol mee behalve berichtjes versleutelen adhv die key die enkel jij kan decrypten met je private key. Meer kunnen ze er niet mee.

Al is dit een mega basale uitleg trouwens, want met die session keys zoals bijvoorbeeld in double-ratchet ontstaat er volgens mij nogal een probleem als twee devices los van elkaar door de session keys heen gaan ratcheten omdat jijzelf en/of de tegenpartij dan geen idee meer heeft waar we nou eigenlijk gebleven waren... Het irriteert me mateloos dat Signal daar een oplossing voor had gevonden mbhv pairwise gelazer; maar dit helemaal nergens meer terug te vinden is omdat alle shit verwijderd is. Ik weet zeker dat ik het ook ergens in mijn comments op Tweakers heb vermeld, als ik de links terug kan vinden dan kan ik misschien via Archive.org die techsheet van het protocol nog achterhalen. Sla mezelf nu omdat ik het niet heb opgeslagen.

Het enige dat ik nog weet is dat het een beetje leek op hun private group systeem. (Doorscrollen naar "The TextSecure Group Protocol" als je de grote inleiding wil skippen. ).
Maar dan met wat aanpassingen zodat het puur is voor de user zelf met multi-device support én authenticatie, zonder dat de encryptie afgezwakt wordt. (... Dus in de praktijk alsnog compleet anders dan het groepsysteem, maar de methode *leek* er een beetje op.) Basically: meerdere devices die dezelfde berichten end-to-end kunnen zenden/ontvangen zonder in te leveren op veiligheid en zonder verhoogd risico op potentiële spionnetjes.
Maar ik kan die f*cking techsheet die ze daar specifiek over hadden geschreven dus niet meer vinden, en geeft 404.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 19:28]

[WhatsappHack]

Het probleem is aan de ene kant dat hoe meer devices de sleutels hebben: hoe meer zwakte punten je hebt. Daarnaast moet je dan je private keys over meerdere devices delen, en die moeten dus uitgewisseld worden; normaliter wil je niet dat dat ding ooit je device verlaat; al gaat het over een super secure kanaal.

Echter, Signal had er een oplossing voor verzonnen. Die hadden een pairwise key-mechanisme ontworpen waarbij meerdere devices hetzelfde bericht konden ontvangen (en ook vanaf meerdere devices berichten verzonden konden worden), zonder de encryptie en authenticatie zelf af te zwakken. (Het lijkt een beetje op de groep functie trouwens, maar werkte toch behoorlijk anders.) (Natuurlijk heb je wel een zwakte doordat je een extra point-of-entry hebt.)

Het probleem is alleen dat ze alle mogelijke informatie hierover verwijderd lijken te hebben, dus ik denk dat het idee dood is; mislukt of ze hebben er geen zin meer in om wat voor reden dan ook.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 19:28]

[mutley69]

Zal dat helpen encryptie bij Facebook? Tot ze van Putin of iemand anders de sleutels moeten afgeven...

[WhatsappHack]

Als je de sleutels niet hebt, kan je ze ook niet geven.