How secure is XMPP with self-signed SSL certificates?

Question

I'm looking for an easy way to set up a simple IM infrastructure that protects messages in transit as well as avoids having logs in places that neither I nor someone I trust controls. I'm based in Germany and according to Mr. Snowden, my traffic actually gets sifted through and analyzed, and I'm not comfortable with that at all. IM is something that bugs me a lot in that regard.

I'm thinking about having an isolated XMPP server with accounts for everyone in the group of people who needs this, and to require SSL with self-signed certificates. I'm running an XMPP server on my raspberry pi anyway, so why not pimp it with some SSL security. It's configured to not write any logs except for errors and diagnostics, so the log issue is fixed there already. The people in question know how to use Pidgin, but anything overly annoying wouldn't fly with any of them. Mobile would be a requirement as well, Facebook's just too convenient. I think XMPP has that covered.

I'm not so fond of OTR, as the Pidgin plugin requires a decent bit of technical literacy, crashes Pidgin every once in a while and takes 10+ seconds to initiate a conversation (for me) during which Pidgin completely freezes. Also, as far as I know there's only IM+'s plugin for mobile platforms and is quite pricey. Relying on a self-hosted server and SSL certificates should work for all conceivable platforms (I guess?), be relatively easy to set up on the client side and provide a decent improvement in security.

The question is, would that be safe enough? At the very least I aim to keep my communication over this infrastructure out of the NSA databases. I'm not aiming to withstand any directed attack by trained experts or the like, I'd just like to have private conversations that actually are as private as a phone call once was, and not archived and analyzed somewhere else as a matter of routine.

If it is, another side question, any recommendations on how exactly to generate the certificates to make them secure? I read that some algorithms may have been compromised, I'd like to avoid those if possible. I've seen a few threads on here on that, but none (that I understoof) with that NSA-proofness spin.

Answer 1

Self-signed certificates are just as good as certificates signed by another entity. The only thing that they're not is in the Public Key Infrastructure. Every modern computer comes with a list of known, trusted root certificates. Any certificate signed by one of these trusted roots is automatically trusted by your computer. Your self-signed certificates are not part of this trust chain, so it's up to you to trust these certificates. Clients will typically prompt you when encountering a certificate which cannot be traced back to a known root, so it's up to you to confirm that prompt.

The problem in this is that if you confirm this prompt every time by hand, it's very easy to be compromised by a man in the middle, since human verification of a certificate is very error prone. So you will have to establish trust in your self-signed certificate once initially and then let your client handle it. How to do this depends on the client and platform, but most/all platforms have some way of adding arbitrary certificates to the trusted certificate store.

Answer 2

Regarding how secure it is.. It is as told above too, nearly as secure as any other certificate unless you use softwares or an OS with vulnerabilities. TBH, I use an own CA and roll my certificates for several things myself and theyre just fine so far (e.g. server certs, user certs, RADIUS cert, SQUID MITM CA).

I'd probably suggest you to consider creating a CA and signing each user certificate using the CA or its Intermediate CAs as this would assure that the user is really the user you have trusted and not someone else in the middle who you trust each time a connection establishes. And another advantage: You just gotta trust the root certificate and all users will be trusted then.

I don't know very much of XAMPP, but you should also lookup for ways to implement a Forward Secrecy. In TLS connections, this is dealt using DH Keys (at least 2048 bit to be secure, I go for 4096 dhparam usually, but on a RasPi, I'd advise you to use dsaparam cuz that's faster and said to be as secure as dhparam). That way with each session, a new secret is generated per handshake and even if later on your certificates got compromised, it'd be nearly impossible to decrypt previous messages. You can also check up for which ciphersuits and curves to use to keep things secure at cipherli.st as there are secure ciphers regularly updated,

Also note, generating 8k bits keys does not mean you will really have the strength of the 8k, so don't go over the horizon just to make things "more secure". It always depends on the entropy on the device and e.g. in an old Debian version, there was some kinda "Debian Weak Key Vulnerabilty", so doesn't matter how many bits you set, the keys were always weak, so also keep up your System up to date and use a secure OS that you personally trust. (I personally use BSD to generate keys nowadays since NSA made a commit in the Linux Kernel as far as I know and this commit is said to affect several security points in any Linux Distro. So for obvious reasons, I don't trust the NSA even in open source commits, but won't judge Linus' decision on that tho)

Between, you do not need to manage an own PKI for just a few users, just the self-made openSSL CA would be sufficient enough. But if you wanna go clean, EJBCA is not so bad to manage CAs androlled certificates as well as revocation lists.

Answer 3

OK, phone calls were never private. The phone company has always had the ability to tap and record your calls. The system was designed in such a way as to aid law enforcement and government spying from early on. The idea that phone calls are personal and cannot be violated is a fallacy.

It sounds like you are trying to put together a system which is easy for technically illiterate people to use, in which case I'd suggest just using existing tools rather than rolling your own. I mean do you really think your personal communications are really of interest to the spy agencies that it is worth re-inventing the wheel, especially when it makes the system harder to use?

Delf-signed certificates are not a great option because they don't offer any assurance of the identity of the certificate holder unless you specifically configure your own pool user-key associations, which is a load of administrative overhead. If a user wants to log into the tool from multiple systems he/she must either associate each private key from each system with their identity, or export-transfer-import the same self-signed key to each machine. Most literate computers users wouldn't want to bother with that, asking a novice to do those things would just make your tool unusable. So it just makes things difficult without any security benefit.