-
Martin
Anybody knows why I get a penalty on the ciphers? https://xmpp.net/result.php?domain=mdosch.de&type=server#ciphers
-
Martin
Also the cipherlist seems incomplete as cryptcheck or testssl.sh see more: https://cryptcheck.fr/xmpp/mdosch.de
-
jonas’
cipherlist doesn’t load here
-
jonas’
maybe it’s not finished yet?
-
jonas’
it also shows a Grade A now
-
jonas’
ah, yeah, cipherscore isn’t at 100% though
-
jonas’
not sure why
-
Martin
Yeah, I just rerun the test that's why it was not yet finished when you looked.
-
mss_cyclist
Do you experience as well that xmpp.net is fu*in' slow last time?
-
mss_cyclist
Martin: Just an idea: > Server does not respect the client's cipher ordering.
-
mss_cyclist
>TLSv1 No >TLSv1.1 No
-
Martin
Dunno. TLS v1 is deprecated so why should I use it.
-
mss_cyclist
Sure, at least it is some feedback given. I suppose all gray fields should be green. And these exist but are gray. So I think they might be needed for max. score
-
Martin
No, actually only ciphers are not 100% so protocol level is fine.
-
tom
I don't think forcing server preferred cipher order is a good thing despite what qualsys says
-
tom
As long as you only allow string ciphers and hmacs, like AESGCM256+EDH:chacha20poly1305:ecdh (not my exact cipher line just an example) it's better to let the client pick which ones out of those it wants to use
-
tom
The client is going to know best wither or not it has AES-NI hardware offload, or if chacha20 might be a better option given it's arch
-
tom
Or if the client's entropy source is suspect and it wants to use a cipher that doesn't explode in a ball of fire spectacularly if entropy runs out mid-way through a session like chacha20
-
Martin
I think prosody/luasec does this. At least I'm not aware forcing the order.