XMPP Service Operators - 2020-03-14

Anybody knows why I get a penalty on the ciphers? https://xmpp.net/result.php?domain=mdosch.de&type=server#ciphers

Also the cipherlist seems incomplete as cryptcheck or testssl.sh see more: https://cryptcheck.fr/xmpp/mdosch.de

cipherlist doesn’t load here

maybe it’s not finished yet?

it also shows a Grade A now

ah, yeah, cipherscore isn’t at 100% though

not sure why

Yeah, I just rerun the test that's why it was not yet finished when you looked.

Do you experience as well that xmpp.net is fu*in' slow last time?

Martin: Just an idea: > Server does not respect the client's cipher ordering.

>TLSv1 No >TLSv1.1 No

Dunno. TLS v1 is deprecated so why should I use it.

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

No, actually only ciphers are not 100% so protocol level is fine.

I don't think forcing server preferred cipher order is a good thing despite what qualsys says

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

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

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

I think prosody/luasec does this. At least I'm not aware forcing the order.