New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLS policy and ejabberd #5580
Comments
I think we need a new policy identifier, because we actually upgrade the ejabberd configuration from a "default" one to a newly defined (more restrictive) one. Like 2018-10-01 Why to allow only TLS 1.2? Can we allow also TLS 1.1? |
you are right, I checked the documentation (tlspolicy page) and I saw now that sslV3 and tlsv1 is removed, but in the comment code I read that only tls1.2 is allowed....it is my mistake Probably the doc should be adjusted because I Tested with testssl.sh and of course tls1.0/1.1 is still allowed. Honestly I do not think we need another policy name, except if we want to protect other services by a new list of really secure ciphers....But we could enhance the security of ejabberd when the tlspolicy is not default |
Note that docs section is about "slapd"! I'm assuming the server is at "upstream default" setup: if now the ejabberd clients can use It's fine that a policy actually affects just one service, like ejabberd, which has some dedicated TCP ports and protocols. |
Remember the docs! ;)
|
in |
@DavidePrincipi please review the documentation NethServer/docs#364 |
@stephdl, I added some changes: please review them (I cannot set you as reviewer of your PR) |
in |
in |
in |
Test case 0 After RPM update, an existing system must preserve the previous available cipher suite Test case 1 Upgrade to TLS policy 20181001: only TLS 1.2 is available from ejabberd service QA note: as STARTTLS method seems not working with |
@stephdl, did you verify the S2S socket?
|
For me, even our previous configuration has an issue, we ought to prove what cipher you used even with nmap, testssl or https://xmpp.net/ Check https://community.nethserver.org/t/starttls-and-ejabberd/10800 Something is wrong.... Sure we could test the 5223 and accept it could be right for the 5222 (starttls) but I do not understand what it occurs Let me try https://xmpp.net/ with the port 5269 |
in |
from this https://xmpp.net/result.php?id=826718, S2S is well secured by the new policy 20181001 from this https://xmpp.net/result.php?id=826747 , S2S get the default cipher configuration with older policy the s2s is verified @DavidePrincipi |
in |
QA Ciphers list compatible with https://bettercrypto.org/static/applied-crypto-hardening.pdf and the tlspolicy20180621 we implemented (ECC compatible) this time we harden web admin interface 5280 to test 5280,5223 (without starttls) for s2s and c2s (starttls) , please use https://xmpp.net/index.php
|
Remember the docs! ;)
|
in |
VERIFIED See my comment here NethServer/nethserver-ejabberd#16 (comment) |
in |
in |
Ejabberd after the update is not hardened by the tls-policy we implemented, I propose to make it possible.
I followed this tutorial https://blog.process-one.net/securing-ejabberd-with-tls-encryption/ and for now I modified
I saw that we could make also a dh key to enhance the security, for now I did nothing, maybe it could be a NFR.
The text was updated successfully, but these errors were encountered: