1. Manifesto of the fight against unprotected s2s connections to protect users from intercepting plain-text messages
In the past, the certificates were worth the money. In the past, obtaining certificates was a difficult task. This forced the use of self-signed certificates in connections to preserve the federation. Invalid certificates are dangerous because unencrypted (without e2e) user communications can be intercepted and modified.
Currently, certificates have become free and anyone can get them. Unfortunately, 10% servers continue to use invalid encryption. We do not want to compromise with servers that do not care about user security. If they want to support connection us, they will make valid encryption.
We believe that the time has come to stop supporting untrusted certificates to increase user security.
Default settings Ejabberd and Prosody uses encryption but allow self-signed certificates:
s2s_secure_auth = false
Most xmpp servers have valid certificates, but they allow non-valid encryption by default.
we are not the ones who talk about privacy, but at the same time allow to intercept correspondence. We think that our users should be confident that they use only secure connections. Manual for operators XMPP servers
Servers in this list pledge not to accept connections with untrusted certificates.
List servers with non-valid s2s encryption
This section is created for administrators of XMPP servers with incorrect encryption settings. If you find your server in this list, check your encryption configuration. If you do not agree with being in this list, open the Pull request or Issues
Incorrectly listed server encryption algorithms (Support only RSA or ECC)
Outdated way to verify certificates (Support only Dialback)
The reasons for which you must refuse to support self-signed certificates
Unfortunately, we faced resistance to the manifesto from uneducated administrators. we want to explain the reasons why it’s bad to allow using self-signed and untrusted certificates via answers to the most frequent criticism
Now it is easy to get a verified certificate. There is no difficulty in obtaining a free certificate. Self-signed or invalid certificates are used on bogus servers that are sources of flood and spam. Even 90% of opponents of the manifesto do not use self-signed certificates on their server, therefore they consider this a disgrace for their public server.
By allowing untrusted certificates you help one user, but you also make another user unprotected. There is no need allow connect server to poorly configured servers, because the work of correcting certificates errors is not your task. Many server administrators with poorly configured encryption do not have the incentive to properly configure encryption as long as you allow them to do nothing.if administrators with untrusted certifications get massive unavailability, they correct the error themselves.
self-signed certificates have been a necessary measure in the past as a free replacement for paid certificates. Self-signed certificates provide the lowest security class. Yes, hackers find it difficult to intercept a self-signed s2s certificate, but intercepting untrusted s2s and self-signed certificates is an easy task for intelligence services.
Servers using self-signed s2s use self-signed c2s. Even those admins who say that manually check s2s connections, leave a backdoor to intercept correspondence from c2s connections. The self-signed certificate c2s can be intercepted not only by the intelligence services, but by ordinary hackers through a public Wi-Fi.You need to max protect all points of communication users (c2s<=>s2s<=>c2s), if possible.
If I enable certificate validation, can't I use my own CA?
You can have your own CA, but this will require additional configuration efforts. You can set two certificates and the priority between using them. Your second certificate will be available only to those who trust your certificate or your authorization center.
Users of the TOR will not be able to connect to the server?
If you configure the server correctly, users will be able to connect to the hidden service.
Many administrators are trying to upgrade the certificate class by manually listing the ciphers - this is wrong. Leave the defaults s2s list ciphers alone. To upgrade the certificate class, use the ECC certificate instead of RSA, and not guessing with cipher list!
Correct default (example for Ejabberd):
Wrong modification: (example for Ejabberd)
This set includes ECC (ECDHE-ECDSA) and RSA (ECDHE-RSA) ciphers.If you do not include the ciphers in the ECC, you will lose contact with the ECC servers. If you do not enable RSA ciphers, you will lose connection with RSA servers.
This is config right now, but will not work in the future! In the future, new ciphers will appear and the setting will be incorrect.
delete support self-signed certificates "mod_s2s_dialback":
Check verification other sertificates:
s2s_secure_auth = false
s2s_secure_auth = true
What is the use of this manifest?
If your users cannot connect to another server due to invalid encryption, you can send a link to this manifest and add a server with poor encryption to the List servers with non-valid s2s encryption
Why can not I connect to the server untrusted.com?
This server has an untrusted certificate: https://github.com/E-404/Manifestos/blob/master/1.md#list-servers-with-non-valid-s2s-encryption
Connection test. XMPP echo contact (sends back messages to Gajim ):