End-to-End Encrypted Chat that YOU Control: Hosting XMPP (Jabber) with Prosody

Submitted ⁨⁨1⁩ ⁨day⁩ ago⁩ by ⁨starkzarn@infosec.pub⁩ to ⁨selfhosted@lemmy.world⁩

Take control of your data, join the tech chat. Host an XMPP server and leverage end-to-end encryption for your personal data

source

Comments

Sort:hotnew top

7rokhym@lemmy.ca ⁨8⁩ ⁨hours⁩ ago
Poor XMPP, no one will just let it die.

source
- Wigglesworth@retrolemmy.com ⁨8⁩ ⁨hours⁩ ago
  The VC money won’t let Matrix die. The community support won’t let XMPP die.
  
  I know which I respect more.
  
  source
- starkzarn@infosec.pub ⁨8⁩ ⁨hours⁩ ago
  It has a long healthy life ahead! Come join the party, the proof is in the pudding.
  
  source
litchralee@sh.itjust.works ⁨1⁩ ⁨day⁩ ago
When I see E2EE and XMPP mentioned, I think of this blog post by Soatok, outlining some very odd cryptographic choices in XMPP + OMEMO: soatok.blog/2024/08/04/against-xmppomemo/

It would very much like to see a richer playing field than just Signal for private messaging, but it’s a tough nut to crack. For exactly which aspect that turns me away from XMPP for E2EE, I think this nails it down:

you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can).

When the competition is Signal, these sorts of details matter a lot.

source
- poVoq@slrpnk.net ⁨1⁩ ⁨day⁩ ago
  That article is highly misleading.
  
  A good response can be found here: www.moparisthebest.com/against-silos-signal/
  
  source
  - starkzarn@infosec.pub ⁨1⁩ ⁨day⁩ ago
    This is also a great article! Thanks for the link.
    
    One cool point in favor of XMPP is that in a public setting (MUCs), there’s community. Moparisbest is an active participant in several of the MUCs that I’m in. Very cool!
    
    source
- Swedneck@discuss.tchncs.de ⁨9⁩ ⁨hours⁩ ago
  have you looked at simplex? at a glance it seems robust and it actually works without much fiddling which is nice.
  
  source
  - starkzarn@infosec.pub ⁨8⁩ ⁨hours⁩ ago
    I have experimented with Simplex, but it feels less tuned toward hosting federated infrastructure and more tuned toward participation with the greater network in a pseudo-anonymous fashion.
    
    Adoption is also always a hurdle with any ecosystem like this, and XMPP is certainly ahead of Simplex in that avenue.
    
    source
- possiblylinux127@lemmy.zip ⁨1⁩ ⁨day⁩ ago
  Simplex Chat is another option
  
  source
- starkzarn@infosec.pub ⁨1⁩ ⁨day⁩ ago
  This is great, I have not seen this post before. Thank you for sharing.
  
  You make an excellent point here, that the burden of security and privacy is put on the user, and that means that the other party in which you’re engaged in conversation with can mess it up for the both of you. It’s far from perfect, absolutely. Ideally you can educate those that are willing to chat with you on XMPP and kill two birds with one stone, good E2EE, and security and privacy training for a friend. XMPP doesn’t tick the same box as Signal though, certainly. I still rely heavily on Signal, but that data resides on and transits a lot of things that I don’t control. There’s a time and a place for concerns with both, but I wanted to share my strategy for an internal chat server that also meets some of those privacy and security wickets.
  
  source
  - ArcaneSlime@lemmy.dbzer0.com ⁨1⁩ ⁨day⁩ ago
    Tbf, can’t the other party mess it up with signal too? I have a friend with a Samsung running stock samsung android, bloatware and all; how can I trust there’s no google or samsung keylogger, which I’m pretty sure at least one of those companies installs? With copilot existing now, how can I be sure that, when that makes it’s way to stock android, it won’t capture the signal convo? The man uses windows, how can I be sure he won’t surrender our chats to current copilot?
    
    If you need nation-state level secrecy, rule #1 is don’t associate with idiots who can’t be bothered with at least the most basic opsec. I shouldn’t talk to this motherfucker at all were that my case, or at least not digitally. Thankfully at worst we talk about me middlemanning him some weed, and even local PD dgaf.
    
    My main issue for signal is (mostly iPhone users) download it “just for protests” (ffs) and then delete it, but don’t relinquish their acct, so when I text them using signal it dies in limbo as they either deleted the app or never check it and don’t allow notifs. Now maybe somehow with the removal of SMS maybe that is fixed, but also removing SMS took my biggest selling point to “normals,” so, fuck me.
    
    source
    -> View More Comments
  - mistermodal@lemmy.ml ⁨1⁩ ⁨day⁩ ago
    Never cared for the way this fellow tries to argue that everything is too difficult to be useful. I’ve gotten plenty of friends and family on XMPP and the clients that don’t have encryption on by default are easy to remember. Really blowing it out of proportion.
    
    Honestly, what do security researchers like this even know about normal people? They sit through all kinds of inconveniences to use Facebook. This is a thought experiment.
    
    Some of these are valid criticisms, of course, a lot of XMPP stuff feels like it from the 2010s. It’s still the only real option. Matrix client or server is bloated garbage, theu moved server fixes into a walled garden, its development is dependent on funding from the USA National Endowment for Democracy technology fund. Signal has similar funding issues and is very shady with its centralization, trust issues, demanding phone numbers. Sets users up to leak all kinds of stuff in notifications like Matrix.
    
    The strange insistence that only Signal meets their requirements makes me skeptical, as does the way they have operated in Github threads. They seem like an emotional nightmare to work with.
    
    source
Im_old@lemmy.world ⁨1⁩ ⁨day⁩ ago
This is great as last time I looked to set up prosody there were no official container images.

I just need to figure out how to set up slidge/matrix bridge and then I can ditch my matrix server.

source
- starkzarn@infosec.pub ⁨1⁩ ⁨day⁩ ago
  Yeah they just redid their container image pipeline and these containers are the result!
  
  source
warmaster@lemmy.world ⁨1⁩ ⁨day⁩ ago
STUN/TURN is literally designed to bypass network boundaries. Its necessity comes from the evil of NAT and allowing RFC1918 IP addresses behind firewalls to poke holes so that direct P2P connections can be established for VOIP. By virtue of being technology designed to step around boundaries, you should be weary of controls around this. STUN can be used to relay from the external STUN record to other servers within the same broadcast domain. We’ll add some controls here to limit this, but it would behoove you to place this server in an isolated DMZ without connectivity to other, potentially privileged, internal hosts. Never forget network segmentation.``` Would a VLAN be enough?
source
- starkzarn@infosec.pub ⁨1⁩ ⁨day⁩ ago
  Yes, absolutely. It all depends on implementation. I am using VLANs for L2 isolation. I have a specific DMZ VLAN that has my XMPP server and only my XMPP server on it. My network core applies ACLs that prevent any inter-VLAN traffic from there, so even if STUN/TURN pokes holes, the most that is accessible is that single VLAN, which happens to contain only the single host that I want to be accessible.
  
  Great question.
  
  source
  - qwexfle@lemmy.ml ⁨1⁩ ⁨hour⁩ ago
    I’m interested, although I’m not sure I understand. Isn’t the point of poking holes to enable clients to connect when obscured by NAT? Does voip still work with this?
    
    source