#879 Broader support of TLS ECDH curves

Reporter Adrien
Owner Nobody
Created
Updated
Stars ★★ (2)  
Tags
  • Status-New
  • Type-Enhancement
  • Priority-Low
  1. Adrien on

    Lua-sec upstream has just merged support for specifying several ECDH curves in the TLS handshake ( https://github.com/brunoos/luasec/pull/47 ). Prosody should adapt to this in order to help more clients have forward secrecy. For the record, I got interested in this issue after I found out that my XMPP client on Android couldn't use PFS because it only handled secp256r1 while prosody used secp384r1. Server ranked well according to test websites but actual connections weren't necessarily more secure.

  2. Zash on

    Seems like this would be tricky to support while maintaining backwards compatibility.

  3. Adrien on

    I hadn't paid enough attention to the details and I can see two issues now. 1- Names are different: roughly, "secp384r1" would become "P-384". 2- Using a colon-separated list of curve names with an old lua-sec would fail. However I guess that would prevent proper startup of prosody and would therefore be noticed. Is it 1- that concerns you the most or is it something else? It would be easy to make lua-sec first attempt to use

  4. Adrien on

    I hadn't paid enough attention to the details and I can see two issues now. 1- Names are different: roughly, "secp384r1" would become "P-384". 2- Using a colon-separated list of curve names with an old lua-sec would fail. However I guess that would prevent proper startup of prosody and would therefore be noticed. Is it 1- that concerns you the most or is it something else? I think openssl understands various naming schemes. I need to write a bit of code to make sure however.

  5. Adrien on

    And please disregard comment #3 (or possibly remove it along with this one): I submitted it too early by typo-ing.

  6. Thilo Molitor (tmolitor) on

    Adrien, just for your info: Only android 7.0 doesn't support curves other than P-256, all previous android versions and even android 7.1 support P-384 alongside P-256. As far as I know this is a bug in android, see http://stackoverflow.com/a/42047877/3528174 and https://code.google.com/p/android/issues/detail?id=224438 for details.

  7. Adrien on

    That's really good news. I still hope that Prosody can handle multiple curve offers but it indeed definitely lowers the need for now. Thanks for the notice.

  8. Zash on

    This does actually any changes to Prosody to use, just set ssl = { curve = "..." }. The difficulty is in changing the defaults without breaking on older LuaSec. Since having lots of options isn't necessarily a good thing when it comes to crypto, I don' think it needs to be a priority.

    Changes
    • tags Priority-Low
  9. Adrien on

    For the record, this also impacts federation and ejabberd servers seem to default to only P-256 (haven't tried but that's what I've been seeing). And, yes, that only has an impact on defaults.

  10. kseistrup on

    This is a real issue. With Debian 9 (stretch), released just a few days ago, Prosody can't federate with ejabberd servers. Prosody insists on secp394r1 and ejabberd insists on prime256v1. A friend of mine patched his ejabberd so that we can still chat: https://koldfront.dk/archive/2017/06/20-210822.html But that is just one out of many ejabberd servers out there.

  11. MattJ on

    Hey. Can someone who is experiencing the ejabberd connectivity issue please open a new bug report with debug logs and the output of 'prosodyctl about'? Thanks!

  12. Adrien on

    Bug report opened in #951.

  13. kseistrup on

    There's also #943 (not as comprehensive).

New comment