Xmpp-providers schakelen 'verplichte' encryptie in

Een groot aantal xmpp-servers is na het ondertekenen van een manifest vanaf maandag uitsluitend nog via een versleutelde verbinding te gebruiken, in een poging passief afluisteren te bemoeilijken. Bij een volgende stap wordt ook gekeken naar certificaten en andere manieren van identificatie.

Mede naar aanleiding van de Snowden-onthullingen ondertekenden in maart meer dan zeventig xmpp-serveroperators een manifest. Daarin beloofden zij alle instant-messagingverbindingen via het xmpp-protocol voortaan via ssl-versleuteling te laten verlopen. Dit moet het aftappen van chatverkeer lastiger maken. De deadline waarop alle ondertekenaars aan deze voorwaarde moesten voldoen, werd gesteld op 19 mei.

Nu de 'ssl-verplichting' is ingegaan, overleggen de deelnemende xmpp-serverbeheerders inmiddels over mogelijke vervolgstappen. Zo ligt er het plan om gebruik te gaan maken van certificaten die door certificaatautoriteiten worden uitgegeven, zoals op veel https-websites al langer gebeurt. Er is echter bij sommigen om verschillende redenen weerstand tegen dit model, zoals vanwege de hoge kosten of uit principe. Alternatieven die worden overwogen zijn het toepassen van het dsnssec-protocol en het Monkeysphere-project, dat gebaseerd is op OpenPGP. De opstellers van het manifest roepen serverbeheerders op om de mogelijke alternatieven voor certificaten in de praktijk te testen.

Reacties (23)

[The Zep Man]

Encryptie bij XMPP vanuit de providers maakt niet veel uit zolang:
• Wachtwoorden voor client naar server authenticatie niet over de lijn gaan op een manier dat replay attacks ingezet kunnen worden.
• De gebruikers zelf hun encryptie van end-point naar end-point regelen. Denk bijvoorbeeld aan het gebruik van OTR. Dit moeten gebruikers sowieso doen, omdat server operators een partij zijn die je niet hoeft te vertrouwen (buiten het leveren van beschikbaarheid om).

Nu de 'ssl-verplichting' is ingegaan, overleggen de deelnemende xmpp-serverbeheerders inmiddels over mogelijke vervolgstappen.

Aangenomen dat aan de genoemde voorwaarden wordt voldaan, kunnen servers zelfs onderling 'blind' (zonder vertrouwen) encryptie toepassen indien gewenst. Hierdoor maak je de drempel tot een initiële aanval al een stuk hoger met weinig kosten doordat een aanvaller een man-in-the-middle moet zijn in plaats van een passieve afluisteraar. En zelfs als man-in-the-middle kan een aanvaller niet veel met het berichtenverkeer van gebruikers wanneer OTR wordt toegepast.

Dit zou ook wat kunnen zijn voor HTTP 2.0 (of wat dan ook de volgende standaard wordt): 'http' (TCP poort 80) werkt alleen met niet-vertrouwde encryptie. Om 'http' verkeer af te luisteren moet een aanvaller dus een man-in-the-middle zijn. Het is niet veilig (daarom ontbreekt de 's' ook), maar maakt met een relatief kleine inspanning het al een stuk lastiger voor aanvallers die op grote schaal geen man-in-the-middle kunnen zijn. Andersom wordt afluisteren op grote schaal (bijvoorbeeld door overheden) een probleem door de grote hoeveelheid extra rekenkracht die nodig is om al het verkeer te decrypten en weer te encrypten als man-in-the-middle.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 17:41]

[i-chat]

maar ort is dan weer onmogelijk met muc, er schijnen wel mensen aan te werken maar het lijkt niet te willen vorderen (wat ik trouwens behoorlijk logisch vind).

[ralphm]

OTR of andere vormen van end-to-end encryption zijn lastig bij meerdere partijen, omdat alle deelnemende partijen de versleutelde berichten moeten kunnen lezen of juist hun uitgaande berichten moet versleutelen voor alle anderen. Je moet dan sleutels uitwisselen bij een potentieel zeer veranderlijke groep deelnemers.

Een ander nadeel van OTR in dat het alleen de platte tekst van berichten versleutelt. Meta-data zoals ontvanger en afzender, maar ook andere informatie zoals presence, discovery of profiel informatie wordt niet afgedekt in de huidige manier van OTR over XMPP.

[drdelta]

Daarnaast hebben XMPP programma's/OTR geen ondersteuning voor meerdere devices, waardoor je ook niet meerdere keys kunt hebben voor een contactpersoon, waardoor je iedere keer iemand opnieuw zou moeten authenticaten als jij en/of hij/zij van apparaat veranderd. Reden voor mij en vrienden om zonder OTR ( ) nu te werken.

[xnyhps]

• Wachtwoorden voor client naar server authenticatie niet over de lijn gaan op een manier dat replay attacks ingezet kunnen worden.

Een heel groot deel van de servers biedt beter authenticatie aan dan PLAIN: https://xmpp.net/reports.php#saslmechanisms. DIGEST-MD5 en SCRAM-SHA-1 maken replay attacks onmogelijk, en veel clients ondersteunen minimaal 1 van die 2.

[Reactie gewijzigd door xnyhps op 23 juli 2024 17:41]

[theBazz]

Wat voor principes kan ze dan tegen houden?
DE kosten kan ik nog begrijpen, dit moet passen binnen je businessmodel.

Iemand een idee?

[ralphm]

Er zijn een aantal overwegingen. Om authenticatie tussen servers met certificaten te laten werken, moet er vertrouwen zijn dat het afgegeven certificaat van de ander inderdaad van die partij is en niet van iemand anders die jouw verkeer wil onderscheppen. Je kunt daarmee verschillende kanten op.

1. Een zogenaamd self-signed certificaat. Je moet dan buiten het protocol om vaststellen dat het certicaat klopt. Bijvoorbeeld aan de hand van de fingerprint. Dit is vrij omslachtig als je graag wil dat iedereen met zijn eigen server met je wil communiceren, maar misschien vertrouw je dat wel meer dan CAs (zie hieronder).

2. Een certificaat laten tekenen door een Certificate Authority (CA). Hier vertrouw je dat de handtekening van alle CA's uit een bepaalde lijst betrouwbaar genoeg zijn om vast te stellen dat dat certificaat afkomstig is van de server waarmee je wil communiceren. Er begint steeds meer weerstand hiertegen te komen. Niet in de laatste plaats door affaires als DigiNotar. Niemand controlleert daadwerkelijk of al die CAs wel te vertrouwen zijn, maar ondertussen kunnen ze allemaal tekenen voor alle certificaten. Aan de andere kant maakt het alles wel 'gemakkelijk' en gaat er bovendien een hoop geld in om. Denk ook aan partijen die wel gratis certificaten verstrekken, maar geld vragen voor 'revocations', zelfs als er een enorme bug in OpenSSL gevonden is.

3. Een combinatie van bovenstaande, waarbij je bepaalde certificaten 'pinned'. Of waarbij je het certificaat van de allereerste verbinding accepteert en onthoudt. Als er dan plots een ander certificaat gebruikt wordt, is er misschien een Man-in-the-middle aanval.

Uiteraard is het in de praktijk nog wat lastiger. Als je bijvoorbeeld je XMPP server door iemand anders wil laten hosten, hoe zorg je dan dat die partij jouw certificaat kan presenteren. Of misschien wel zijn eigen certificaat, en een verklaring dat die partij mag optreden namens jou.

Zo zijn er verschillende uitdagingen, zowel sociaal als technisch, en de XMPP Standards Foundation probeert daar de community zo goed mogelijk in te ondersteunen.

[jaapzb]

Naar mijn idee is self-signed altijd veiliger, mits je een manier hebt om de fingerprint inderdaad goed te controleren. Met een paar honderd "trusted" CA's op deze wereld weet ik niet of je daar nog wel kan zeggen dat die allemaal super vertrouwd kunnen worden, zeker als je voor 25 euro een certificaat voor goggle.com kan afsluiten

[DataGhost]

Ik denk dat ze het niet eens zijn met het vertrouwen van een X-aantal vooraf vastgestelde partijen, waarvan ook nog maar de vraag is hoe betrouwbaar ze zijn of blijven. Zo vertrouwt bijvoorbeeld je browser waarschijnlijk blindelings certificaten die ondertekend zijn door "Staat der Nederlanden Root CA". Ik doe verder geen uitspraken over de betrouwbaarheid daarvan en volgens mij bestaat deze CA vooral om de uitgifte van certificaten tbv overheidszaken makkelijker te maken, maar mocht de AIVD toegang hebben tot deze CA (lees: de mogelijkheid om willekeurige certificaten uit te (laten) geven), kunnen zij een certificaat maken wat zonder meldingen geaccepteerd wordt door je client maar waarmee toch je verkeer wordt afgetapt.

Dit was slechts een voorbeeld, er zitten in de standaardlijstjes ook CA's waar je meer vraagtekens bij zou kunnen zetten, waaronder een paar Chinese.

[Reactie gewijzigd door DataGhost op 23 juli 2024 17:41]

[Glashelder]

Zo vertrouwt bijvoorbeeld je browser waarschijnlijk blindelings certificaten die ondertekend zijn door "Staat der Nederlanden Root CA". Ik doe verder geen uitspraken over de betrouwbaarheid daarvan en volgens mij bestaat deze CA vooral om de uitgifte van certificaten tbv overheidszaken makkelijker te maken, maar mocht de AIVD toegang hebben tot deze CA (lees: de mogelijkheid om willekeurige certificaten uit te (laten) geven), kunnen zij een certificaat maken wat zonder meldingen geaccepteerd wordt door je client maar waarmee toch je verkeer wordt afgetapt.

Dit kan, maar er wordt tegenwoordig steeds meer aan Certificate pinning gedaan. Dit houdt in dat een service controleert of het certificaat is uitgegeven door een te verwachte partij (of zelfs zo extreem als het controleren van de thumbprint van het ontvangen servercertificaat).

Google doet dit bijvoorbeeld met Chrome (en Gmail). Zo is ook de hele Diginotar affaire ontdekt.

Dus ja, het kan, maar het is voor een CA wel een _extreem_ riskante onderneming. Ontdekking betekend per direct het einde van je CA.

De PKI overheid CA wordt verder inderdaad gebruikt voor overheidsdiensten zoals DigID maar ook door de belastingdienst. Iedereen die beroepsmatig aangifte doet (BTW of andere aangiftes) heeft tegenwoordig ook een PKI overheid certificaat voor communicatie met de belastingdienst

[Reactie gewijzigd door Glashelder op 23 juli 2024 17:41]

[Verwijderd]

Tjeetje,

Net efkes gekeken naar mijn root-certificates maar dat is ook een wildvreemde lijst zeg.
Glashelder kan het mij wellicht 'glashelder' uitleggen maar ik snap niet waar en hoe ik aan sommige certificaten kom. Veel 'Swiss' certificates

Nederlandse staat er voorheen uitgeknikkerd maar staat er mooi weer in enzo...

Edit: moet ik me eens in verdiepen maar dan wordt het een gebed zonder einde...
Ben zo met beveiliging al veel te veel tijd kwijt naar mijn wil.

Maar kort door de bocht CA-certifactes zijn goed (en altijd vertrouwd) ?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 17:41]

[robvanwijk]

CA certificates (en alles wat daarmee getekend is) worden vertrouwd. Of het ook betrouwbaar is... tja, wie zal het zeggen?

Er is, op technisch vlak, niets wat MS, Google of Mozilla tegenhoudt om "North Korea CA" op te nemen in het lijstje van vertrouwde CAs van IE, Chrome of Firefox. Of het overgrote merendeel van hun gebruikers daar blij mee is, dat is een heel andere vraag. Ik kan ook mijn eigen CA oprichten en (hopelijk zonder succes!) proberen om die aan allerlei software toe te laten voegen. Als ik een leverancier zo gek krijgt dan vertrouwen opeens al zijn klanten alles wat ik onderteken.

Dat is uiteindelijk het grote probleem van CAs: je vertrouwt ze omdat de leverancier van je browser ze vertrouwt en je hoopt maar dat die heel goed opletten bij het samenstellen van die lijst. De oplettendheid van degene die het lijstje van CAs beheert is namelijk de enige garantie die je hebt dat de namen van de CAs in hun lijst enigszins kloppen. Ik zou die eigen CA van mij bijvoorbeeld prima "Nederlandse Overheid CA" kunnen noemen; als de browser leverancier zit te slapen en dat ding toevoegt, dan heb jij (realistisch gezien) geen enkele manier om vast te stellen dat er iets helemaal mis is.

[Jester-NL]

maar mocht de AIVD toegang hebben tot deze CA (lees: de mogelijkheid om willekeurige certificaten uit te (laten) geven), kunnen zij een certificaat maken wat zonder meldingen geaccepteerd wordt door je client maar waarmee toch je verkeer wordt afgetapt.

En mocht dat uitlekken, dan heb je een debacle dat qua omvang vele malen groter is (zou kunnen (moeten) zijn) dan het diginotar-verhaal.

Er zijn diverse CA's waar ik mijn vraagtekens bij zet... en dat zijn niet per se de Chinezen.
Het werk van CA's (en in het verlengde daarvan: de werking/veiligheid) is grotendeels gebaseerd op vertrouwen. En voor mij heeft bovenstaande een grotere impact op mijn vertrouwen in certificaten, dan een Chinese club, die in ieder geval het vertrouwen heeft van de grote(re) software-makers

[jaapzb]

Het kan ook lastiger voor de klant zijn om de juiste gegevens op te zetten voor een ssl verbinding? En lastiger voor de klant is nooit goed voor je business.

[svenslootweg]

Het kan ook lastiger voor de klant zijn om de juiste gegevens op te zetten voor een ssl verbinding? En lastiger voor de klant is nooit goed voor je business.

Niet echt, nee. Is niet meer dan een vinkje zetten. Sterker nog, volgens mij staan de meeste XMPP clients standaard ingesteld om eerst SSL te proberen.

[jaapzb]

Tja, maar meestal zitten dat soort vinkjes verstopt in een dubieus settings paneltje ergens ver weg Als het default aan staat is het natuurlijk geen probleem, maar als mensen zelf dingen aan moeten gaan zetten word het wat lastiger. Dan werkt het default dus gewoon niet en dan worden mensen boos enzo

[Verwijderd]

Wat voor principes kan ze dan tegen houden?

Ik ben geen expert op dit gebied, maar ik kan me indenken dat het ook te maken heeft met de extra belasting voor de servers. Een encrypted sessie bouwen en onderhouden kost flink wat meer resources (zowel cpu als geheugen) dan unencrypted. Ik kan me indenken dat dit bij IM (honderden of duizenden connecties?) best wel merkbaar gaat zijn.

[Gurd]

De root certificaten zijn door overheden gewoon opvraagbaar bij de certificaat autoriteiten. Als dit een reactie is op de onthullingen dan zou ik me ook achter de oren krabben of je die dan wel moet gebruiken.

Natuurlijk ontkom je je er niet aan om de officiële certificaatautoriteiten te gebruiken voor je website maar voor XMPP kun je naar alternatieven kijken.

Ze zouden imho gezamenlijk hun eigen specifieke certificaat autoriteit moeten beginnen voor XMPP doeleinden of inderdaad die alternatieven uit proberen.

[mmjjb]

in een poging passief afluisteren te bemoeilijken.
... die door certificaatautoriteiten worden uitgegeven

Ik dacht dat ze het wouden bemoeilijken, het gebruiken van certificaten van certificaatautoriteiten die veelal in amerika zitten en waarbij de kans bestaat dat ze met de NSA samen werken lijkt me niet echt een bemoeilijking.

Volgens mij kunnen ze beter een eigen dan wel niet erkende ca authority runnen waarbij gebruiker de hash eenmalig checked, dan het gebruik maken van een authoriteit die mogelijk aan de NSA een kopie van je cert geeft.

[Reactie gewijzigd door mmjjb op 23 juli 2024 17:41]

[ralphm]

Vooralsnog worden certificaten niet gecontrolleerd. Door verbindingen standaard te versleutelen wordt het lastiger om op grote schaal informatie te verkrijgen. CAs gaan over het tekenen van je certificaat met een publieke sleutel. De private sleutel kun je geheim houden. Om je berichten te kunnen lezen moet een aanvaller dus je private sleutel verkrijgen, een zwakheid in het algoritme van de versleuteling of het genereren van de sleutel benutten, of van het versleutelingsprotocol. Op grote schaal is dat veel duurder dan bakken platte tekst doorspitten. En zogenaamde 'perfect' forward security maakt het ook moeilijker om verzamelde versleutelde data achteraf te ontsleutelen.

[Reactie gewijzigd door ralphm op 23 juli 2024 17:41]

[Seth_Chaos]

Het gaat hier ook om schijn veiligheid. Het hoeft niet veiliger te zijn, als het publiek maar denkt dat het veiliger is.

[Verwijderd]

Ik gebruik al lang SSL op mijn server. Plus OTR natuurlijk. Is toch common sense?

[Jack Flushell]

Nou: (Open)SSL bleek afgelopen jaar anders ook niet even veilig (te zijn geweest). Just sayin'.