XMPP Service Operators - 2020-03-14

  1. Martin

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

  2. Martin

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

  3. jonas’

    cipherlist doesn’t load here

  4. jonas’

    maybe it’s not finished yet?

  5. jonas’

    it also shows a Grade A now

  6. jonas’

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

  7. jonas’

    not sure why

  8. Martin

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

  9. mss_cyclist

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

  10. mss_cyclist

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

  11. mss_cyclist

    >TLSv1 No >TLSv1.1 No

  12. Martin

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

  13. 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

  14. Martin

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

  15. tom

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

  16. 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

  17. 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

  18. 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

  19. Martin

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