@snikket_im Have the reverse proxy working for other things.

I couldnt get the port 5443 up for some weird reason. I could probably docker up everything again, and share the exact issue with the community to see.

It's quite a basic reverse proxy without any fancy configuration ...

@zerok I will land on some instance I guess... What's yours ? 😂

What about the privacy of ? Except logs any other things to consider ? can we change the cipher it use or that kind of thing ... (sorry new in the xmpp configuration)

@zerok Maybe it could be an alternative, but I'm not sure people (friends/colleagues/family) will bother to install a new client ...

@hyde Reverse proxies are indeed a nuisance! The Github issue linked in your post is (as far as we can tell) not a bug, but a symptom of an incorrect reverse proxy configuration.

It's impossible to test and document every possible reverse proxy setup, but the Snikket community chat is a good place to seek help: snikket.org/contact/

Good luck!

@hyde
Port 5443 won't open until certificates are fetched (which only needs 80->5080 to be proxied).

You inspired me to work on some improvements today, starting with github.com/snikket-im/snikket- and github.com/snikket-im/snikket- - we should be able to get those into the next release.

Meanwhile check out github.com/snikket-im/snikket-
@snikket_im

@mattj

The thing is I've setup a wildcard for that subdomain on the nginx side. I didn't know the pod will try to generate the certificates. Let me explore that trail ...

@hyde :( I pretty much did the same with ejabberd. I got it to work but the configuration was far too complicated for my little 3 user setup I had in mind. I also couldn't really find a decent client for macOS or iOS 😞

@hyde That was the other aspect of XMPP that drove me nuts: There are multiple standards for E2E encryption and half of the clients only support only one. I eventually gave up. Luckily, I have nobody to communicate to via XMPP anyway, so I just set up a Matrix server instead :P

@zerok
OMEMO is the only E2EE standard in widespread use on XMPP, and has been for quite some years.

OTR was prevalent before that (not only on XMPP), but was never standard (it utilized clever hacks that allowed it to run over *any* IM protocol). These days I only see it used by die-hard Pidgin users who think XMPP is the same as it was in 2008.

The only other E2EE standard uses OpenPGP (XEP-0373) but no clients implement that, that I'm aware of.
@hyde

@mattj @hyde Yeah, and my main problem was that I couldn't find any macOS/iOS clients that supported OMEMO that I actually liked :(

@mattj @zerok @hyde

There is a OX (XEP-0373) plugin for gajim.

I started to implement XEP-0373 in #profanity #xmppc and into my own client.

@hyde

> What about the privacy of #xmpp ?

From an admin or user point of view? From the context of your post I assume the former.

> can we change the cipher it use or that kind of thing

Very good question. 👍

Technically, IIRC this is outside the protocol specification. Practically, yes you can. For #ejabberd see:

process-one.net/blog/securing-

And of course refer also to the manual.

It is good practice to review the list of allowed ciphers once in a while and make a decision on those considered obsolete or insecure.

@zerok

@101101000
Actually, both admin and users POV.

Thanks for the feedback
@zerok

@hyde

From a user's perspective, the ciphers chosen by the client will be those available to its #TLS implementation, which may or may not have a mechanism for user configuration. Of course, the eligible ciphers would be the intersection of those supported and enabled by the server and the client. This is quite advanced stuff though. Is there any reason why, as a user, you would like to manipulate those?

The other thing under your control as a user would be whether to user encryption at all or not, though nowadays not all clients may give you the choice and your server would still have to run an unencrypted port, which on the public internet is rather unlikely.

The above is as far as client to server communications are concerned and addresses the authentication, integrity and confidentiality #security properties during transport.

You can also encrypt the message body within the payload independently of the communication channel, this is often referred as end to end encryption or E2EE for short. #XMPP has generally followed the best popular practices current at any given time in its 22 years of existence. #E2EE does not enjoy the same level of standardisation (or adoption rate) as transport encryption. I believe this is a consequence of commercial interests from the ad industry (Google, Facebook, etc) but that is a discussion for another day.

A summary of current and past #E2EE options for XMPP is available at wiki.xmpp.org/web/XMPP_E2E_Sec

In brief, at the user level you would choose any reasonably modern client and a reputable + answerable provider such as conversations.im, and update your system regularly.

No different than any other choice of service, really. Unless you are a professional user (like me) as opposed to a regular consumer, in which case you probably have particular requirements and will want to discuss them with suitably qualified advisors or solutions providers, such as the #ProcessOne lot, @tigase, or a few of the consultants that hang around here.

Hope this helps.

@zerok

Sign in to participate in the conversation
Lazybear.social

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!