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.
Zash
on
Seems like this would be tricky to support while maintaining backwards compatibility.
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
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.
Adrien
on
And please disregard comment #3 (or possibly remove it along with this one): I submitted it too early by typo-ing.
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.
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
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.
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.
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!
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.
Seems like this would be tricky to support while maintaining backwards compatibility.
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
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.
And please disregard comment #3 (or possibly remove it along with this one): I submitted it too early by typo-ing.
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.
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.
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.
ChangesFor 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.
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.
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!
Bug report opened in #951.
There's also #943 (not as comprehensive).
And similar here: https://prosody.im/issues/963 https://prosody.im/issues/1040
Fixed in https://hg.prosody.im/trunk/rev/92cddfe65003
Changes