Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers
940 views
Skip to first unread message
in...@binarus.de
Dec 22, 2016, 6:28:30 AM12/22/16
to mozilla-dev-s...@lists.mozilla.org
Hi all,
I already have reported the following issue in the bug tracking system and now have been told that the bug has been closed and that I should put it for discussion here.
Please note that I am no way a security expert, so please don't blame me if the following is wrong. But I am sort of a technical person and eventually have understood the key points when it comes to SSL / TLS. So here we go:
I have read several articles and white papers about what SSL / TLS ciphers are considered secure by cryptography experts. A short summary:
1) To enable forward secrecy, the key exchange should be done via "ephemeral" methods (those with "E" at the end of their names, e.g. DHE or ECDHE).
2) AES in GCM mode should be used as payload encryption method.
3) Elliptic curves should NOT be used, at least not the curves from NIST, because they are suspected (some even say: known) to be poisoned intentionally by several sorts of mechanisms. This means that that all ECDHE... ciphers are out of the game.
4) SHA256 or higher is considered safe enough to be used as hashing / digest method.
Firefox does not offer a single cipher which fulfills all of these criteria.
Steps to reproduce:
In Firefox, open "about:config". Type "SSL3" into the search box to view the list of available SSL / TLS ciphers.
Actual result:
There is no cipher which fulfills all of the criteria mentioned above. Notably, all ciphers which use AES-GCM also use the contaminated ECDHE for key exchange; there is no cipher which offers AES-GCM and the secure DHE key exchange.
Expected / desired result:
There should at least be one cipher in the list which fulfills the criteria mentioned above, i.e. something like that:
security.ssl3.dhe_rsa_aes_256_gcm_sha384
(note the dhe ... instead of ecdhe ...).
Personally, I am considering that as a very serious security problem. The fact that other browsers might have the same problem does not change anything about that.
I hereby propose that Mozilla enables at least one cipher like dhe_rsa_aes_256_gcm_sha384 as fast as possible.
Regards,
Binarus
I already have reported the following issue in the bug tracking system and now have been told that the bug has been closed and that I should put it for discussion here.
Please note that I am no way a security expert, so please don't blame me if the following is wrong. But I am sort of a technical person and eventually have understood the key points when it comes to SSL / TLS. So here we go:
I have read several articles and white papers about what SSL / TLS ciphers are considered secure by cryptography experts. A short summary:
1) To enable forward secrecy, the key exchange should be done via "ephemeral" methods (those with "E" at the end of their names, e.g. DHE or ECDHE).
2) AES in GCM mode should be used as payload encryption method.
3) Elliptic curves should NOT be used, at least not the curves from NIST, because they are suspected (some even say: known) to be poisoned intentionally by several sorts of mechanisms. This means that that all ECDHE... ciphers are out of the game.
4) SHA256 or higher is considered safe enough to be used as hashing / digest method.
Firefox does not offer a single cipher which fulfills all of these criteria.
Steps to reproduce:
In Firefox, open "about:config". Type "SSL3" into the search box to view the list of available SSL / TLS ciphers.
Actual result:
There is no cipher which fulfills all of the criteria mentioned above. Notably, all ciphers which use AES-GCM also use the contaminated ECDHE for key exchange; there is no cipher which offers AES-GCM and the secure DHE key exchange.
Expected / desired result:
There should at least be one cipher in the list which fulfills the criteria mentioned above, i.e. something like that:
security.ssl3.dhe_rsa_aes_256_gcm_sha384
(note the dhe ... instead of ecdhe ...).
Personally, I am considering that as a very serious security problem. The fact that other browsers might have the same problem does not change anything about that.
I hereby propose that Mozilla enables at least one cipher like dhe_rsa_aes_256_gcm_sha384 as fast as possible.
Regards,
Binarus
Kurt Roeckx
Dec 22, 2016, 8:09:14 AM12/22/16
to mozilla-dev-s...@lists.mozilla.org
On 2016-12-22 08:58, in...@binarus.de wrote:
> Hi all,
>
> I already have reported the following issue in the bug tracking system and now have been told that the bug has been closed and that I should put it for discussion here.
>
> Please note that I am no way a security expert, so please don't blame me if the following is wrong. But I am sort of a technical person and eventually have understood the key points when it comes to SSL / TLS. So here we go:
>
> I have read several articles and white papers about what SSL / TLS ciphers are considered secure by cryptography experts. A short summary:
>
> 1) To enable forward secrecy, the key exchange should be done via "ephemeral" methods (those with "E" at the end of their names, e.g. DHE or ECDHE).
>
> 2) AES in GCM mode should be used as payload encryption method.
>
> 3) Elliptic curves should NOT be used, at least not the curves from NIST, because they are suspected (some even say: known) to be poisoned intentionally by several sorts of mechanisms. This means that that all ECDHE... ciphers are out of the game.
The elliptic curves can be used for both the authentication and the key
> Hi all,
>
> I already have reported the following issue in the bug tracking system and now have been told that the bug has been closed and that I should put it for discussion here.
>
> Please note that I am no way a security expert, so please don't blame me if the following is wrong. But I am sort of a technical person and eventually have understood the key points when it comes to SSL / TLS. So here we go:
>
> I have read several articles and white papers about what SSL / TLS ciphers are considered secure by cryptography experts. A short summary:
>
> 1) To enable forward secrecy, the key exchange should be done via "ephemeral" methods (those with "E" at the end of their names, e.g. DHE or ECDHE).
>
> 2) AES in GCM mode should be used as payload encryption method.
>
> 3) Elliptic curves should NOT be used, at least not the curves from NIST, because they are suspected (some even say: known) to be poisoned intentionally by several sorts of mechanisms. This means that that all ECDHE... ciphers are out of the game.
exchange. For the authentication it would be the difference between RSA
and ECDSA.
For the key exchange there are options like X25519 and X448. As far as I
know, there is nothing suspicious about them. Firefox offers X25519 as
the first curve.
For the authentication there will be Ed25519 and Ed448 in the future.
Disabling ECDSA support is something you might want to do, but you would
then be unable to talk to people using only an ECDSA certificate.
> 4) SHA256 or higher is considered safe enough to be used as hashing / digest method.
have different requirements. SHA1 might be safe to use for some of them.
Anyway, for TLS 1.3 firefox currently offers the following ciphers in
the following order:
- AES_128_GCM_SHA256
- CHACHA20_POLY1305
- AES_256_GCM_SHA384
Some of the other properties are not part of the cipher anymore, but I
believe it's possible to have everything you want.
For the TLS 1.2 ciphers it offers, it has them in this order:
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[...]
It does offer ciphers that support all your requirements by default. It
will just depend on the server if it's going to use X25519 or not. And
server support for that will currently be very low.
> There should at least be one cipher in the list which fulfills the
criteria mentioned above, i.e. something like that:
>
> security.ssl3.dhe_rsa_aes_256_gcm_sha384
exchange instead.
Kurt
Eric Rescorla
Dec 22, 2016, 8:05:29 PM12/22/16
to in...@binarus.de, mozilla-dev-s...@lists.mozilla.org
On Wed, Dec 21, 2016 at 11:58 PM, <in...@binarus.de> wrote:
> Hi all,
>
> I already have reported the following issue in the bug tracking system and
> now have been told that the bug has been closed and that I should put it
> for discussion here.
>
> Please note that I am no way a security expert, so please don't blame me
> if the following is wrong. But I am sort of a technical person and
> eventually have understood the key points when it comes to SSL / TLS. So
> here we go:
>
> I have read several articles and white papers about what SSL / TLS ciphers
> are considered secure by cryptography experts. A short summary:
>
> 1) To enable forward secrecy, the key exchange should be done via
> "ephemeral" methods (those with "E" at the end of their names, e.g. DHE or
> ECDHE).
>
> 2) AES in GCM mode should be used as payload encryption method.
>
> 3) Elliptic curves should NOT be used, at least not the curves from NIST,
> because they are suspected (some even say: known) to be poisoned
> intentionally by several sorts of mechanisms. This means that that all
> ECDHE... ciphers are out of the game.
>
I don't believe that this claim reflects the consensus of the security
> Hi all,
>
> I already have reported the following issue in the bug tracking system and
> now have been told that the bug has been closed and that I should put it
> for discussion here.
>
> Please note that I am no way a security expert, so please don't blame me
> if the following is wrong. But I am sort of a technical person and
> eventually have understood the key points when it comes to SSL / TLS. So
> here we go:
>
> I have read several articles and white papers about what SSL / TLS ciphers
> are considered secure by cryptography experts. A short summary:
>
> 1) To enable forward secrecy, the key exchange should be done via
> "ephemeral" methods (those with "E" at the end of their names, e.g. DHE or
> ECDHE).
>
> 2) AES in GCM mode should be used as payload encryption method.
>
> 3) Elliptic curves should NOT be used, at least not the curves from NIST,
> because they are suspected (some even say: known) to be poisoned
> intentionally by several sorts of mechanisms. This means that that all
> ECDHE... ciphers are out of the game.
>
community.
In any case, as Kurt Roeckx observes, Firefox currently supports the new
non-NIST CFRG curves.
-Ekr
4) SHA256 or higher is considered safe enough to be used as hashing /
> digest method.
>
> Firefox does not offer a single cipher which fulfills all of these
> criteria.
>
> Steps to reproduce:
>
> In Firefox, open "about:config". Type "SSL3" into the search box to view
> the list of available SSL / TLS ciphers.
>
> Actual result:
>
> There is no cipher which fulfills all of the criteria mentioned above.
> Notably, all ciphers which use AES-GCM also use the contaminated ECDHE for
> key exchange; there is no cipher which offers AES-GCM and the secure DHE
> key exchange.
>
> Expected / desired result:
>
> criteria.
>
> Steps to reproduce:
>
> In Firefox, open "about:config". Type "SSL3" into the search box to view
> the list of available SSL / TLS ciphers.
>
> Actual result:
>
> There is no cipher which fulfills all of the criteria mentioned above.
> Notably, all ciphers which use AES-GCM also use the contaminated ECDHE for
> key exchange; there is no cipher which offers AES-GCM and the secure DHE
> key exchange.
>
> Expected / desired result:
>
> There should at least be one cipher in the list which fulfills the
> criteria mentioned above, i.e. something like that:
>
> security.ssl3.dhe_rsa_aes_256_gcm_sha384
>
> criteria mentioned above, i.e. something like that:
>
> security.ssl3.dhe_rsa_aes_256_gcm_sha384
>
> (note the dhe ... instead of ecdhe ...).
>
> Personally, I am considering that as a very serious security problem. The
> fact that other browsers might have the same problem does not change
> anything about that.
>
> I hereby propose that Mozilla enables at least one cipher like
> dhe_rsa_aes_256_gcm_sha384 as fast as possible.
>
> Regards,
>
> Binarus
> _______________________________________________
>
> Personally, I am considering that as a very serious security problem. The
> fact that other browsers might have the same problem does not change
> anything about that.
>
> I hereby propose that Mozilla enables at least one cipher like
> dhe_rsa_aes_256_gcm_sha384 as fast as possible.
>
> Regards,
>
> Binarus
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
in...@binarus.de
Dec 23, 2016, 4:34:37 AM12/23/16
to mozilla-dev-s...@lists.mozilla.org
Kurt, thank you very much for your illuminating answer.
> For the key exchange there are options like X25519 and X448. As far as I
> know, there is nothing suspicious about them. Firefox offers X25519 as
> the first curve.
> [...]
I have done that for testing and noticed that Firefox was not able to connect to that website any more. The website will definitely only offer AESxxx-GCM for encryption (which is supported by all browsers I am interested in). The open question is what methods of key exchange I should offer.
Originally, as said above, I wanted to disable ECs on the server completely, but that will prevent FF and other major browsers from connecting to my website, which was the reason for my initial post.
Until now, I didn't know that Firefox supports Ed25519 for key exchange, so this is good news (I don't know anything about Ed448, but Ed25519 is considered secure by nearly all crypto experts).
Due to your hint, I will now research how to configure the server so that it offers ECDHE for key exchange, but only the curve Ed25519 .
But the question remains why FF does not support AES-GCM ciphers with DHE (not ECDHE) key exchange. Is there any chance to get this implemented? It would make life a lot easier.
The web server runs on a standard Linux (Debian jessie), and I doubt that it is easy (or even possible) to configure that system's OpenSSL to support ECDHE but only that certain curve (I may be wrong since I haven't researched yet, though).
Binarus
> For the key exchange there are options like X25519 and X448. As far as I
> know, there is nothing suspicious about them. Firefox offers X25519 as
> the first curve.
> For the authentication there will be Ed25519 and Ed448 in the future.
>
> Disabling ECDSA support is something you might want to do, but you would
> then be unable to talk to people using only an ECDSA certificate.
> [...]
>
> Disabling ECDSA support is something you might want to do, but you would
> then be unable to talk to people using only an ECDSA certificate.
> For the TLS 1.2 ciphers it offers, it has them in this order:
> - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> [...]
>
> It does offer ciphers that support all your requirements by default. It
> will just depend on the server if it's going to use X25519 or not. And
> server support for that will currently be very low.
>
The background of my question is that I am in the process of configuring my web server as secure as possible. Given the problems with ECs, I really would like to disable them on the server for key exchange as well as for authentication (because then I wouldn't have to think about which curves are secure and which are not).
> - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> [...]
>
> It does offer ciphers that support all your requirements by default. It
> will just depend on the server if it's going to use X25519 or not. And
> server support for that will currently be very low.
>
I have done that for testing and noticed that Firefox was not able to connect to that website any more. The website will definitely only offer AESxxx-GCM for encryption (which is supported by all browsers I am interested in). The open question is what methods of key exchange I should offer.
Originally, as said above, I wanted to disable ECs on the server completely, but that will prevent FF and other major browsers from connecting to my website, which was the reason for my initial post.
Until now, I didn't know that Firefox supports Ed25519 for key exchange, so this is good news (I don't know anything about Ed448, but Ed25519 is considered secure by nearly all crypto experts).
Due to your hint, I will now research how to configure the server so that it offers ECDHE for key exchange, but only the curve Ed25519 .
But the question remains why FF does not support AES-GCM ciphers with DHE (not ECDHE) key exchange. Is there any chance to get this implemented? It would make life a lot easier.
The web server runs on a standard Linux (Debian jessie), and I doubt that it is easy (or even possible) to configure that system's OpenSSL to support ECDHE but only that certain curve (I may be wrong since I haven't researched yet, though).
Binarus
in...@binarus.de
Dec 23, 2016, 4:54:00 AM12/23/16
to mozilla-dev-s...@lists.mozilla.org
Eric,
> I don't believe that this claim reflects the consensus of the security
> community.
As far as I have understood, the consensus is that there are bad (insecure) ECs (those from NIST which seem to be intentionally weakened / broken by various tricks) and good (secure) ECs (e.g. Ed25519).
Unfortunately, the bad ones are much more used than the good ones, probably because the latter are younger and possibly not implemented in every crypto library (yet).
I should have mentioned that the reason for my post was that I am trying to configure my web server as secure as possible. Given that, it seems to be very complicated to get information about which ECs are secure and which are not, and it seems overly complicated or even impossible to configure libraries / web servers / [your application here] to offer ECDHE, but to offer only the secure curves.
So I thought it would be a good idea to disable ECs completely, but then FF wouldn't be able to connect to that website any more.
> In any case, as Kurt Roeckx observes, Firefox currently supports the new
> non-NIST CFRG curves.
Yes, and this is good news I didn't know about yet. I now only can hope that I will be able to configure my web server to offer ECDHE, but only the secure curves.
The question remains why FF doesn't offer ciphers like dhe_rsa_aes_256_gcm_sha384. That would indeed allow administrators to turn off EC on their web servers completely. They then could easily configure a very secure web server without thinking about good and bad EC curves (which might be beyond the average part time administrator's knowledge anyway).
Binarus
> I don't believe that this claim reflects the consensus of the security
> community.
Unfortunately, the bad ones are much more used than the good ones, probably because the latter are younger and possibly not implemented in every crypto library (yet).
I should have mentioned that the reason for my post was that I am trying to configure my web server as secure as possible. Given that, it seems to be very complicated to get information about which ECs are secure and which are not, and it seems overly complicated or even impossible to configure libraries / web servers / [your application here] to offer ECDHE, but to offer only the secure curves.
So I thought it would be a good idea to disable ECs completely, but then FF wouldn't be able to connect to that website any more.
> In any case, as Kurt Roeckx observes, Firefox currently supports the new
> non-NIST CFRG curves.
The question remains why FF doesn't offer ciphers like dhe_rsa_aes_256_gcm_sha384. That would indeed allow administrators to turn off EC on their web servers completely. They then could easily configure a very secure web server without thinking about good and bad EC curves (which might be beyond the average part time administrator's knowledge anyway).
Binarus
Kurt Roeckx
Dec 23, 2016, 5:04:20 AM12/23/16
to mozilla-dev-s...@lists.mozilla.org
On 2016-12-23 10:34, in...@binarus.de wrote:
> Until now, I didn't know that Firefox supports Ed25519 for key exchange, so this is good news (I don't know anything about Ed448, but Ed25519 is considered secure by nearly all crypto experts).
Please note that for key exchange it's X25519. Ed25519 is for
> Until now, I didn't know that Firefox supports Ed25519 for key exchange, so this is good news (I don't know anything about Ed448, but Ed25519 is considered secure by nearly all crypto experts).
authentication.
Kurt
Eric Rescorla
Dec 23, 2016, 10:27:31 AM12/23/16
to in...@binarus.de, mozilla-dev-s...@lists.mozilla.org
On Fri, Dec 23, 2016 at 1:53 AM, <in...@binarus.de> wrote:
> Eric,
community, which is why all the major stacks continue to support the major
NIST prime curves (P-256 and P-384). I do think the consensus is that the
new curves are better (faster and easier to implement correctly) which is
why stacks have added them.
> In any case, as Kurt Roeckx observes, Firefox currently supports the new
> > non-NIST CFRG curves.
>
field DH and towards ECDHE, so we're deemphasizing those cipher suites.
Chrome doesn't support them at all. FWIW, in TLS 1.3, group selection and
symmetric cipher are orthogonal so you will be able to use FFDH with any
cipher.
-Ekr
> Eric,
>
> > I don't believe that this claim reflects the consensus of the security
> > community.
>
> > I don't believe that this claim reflects the consensus of the security
> > community.
>
> As far as I have understood, the consensus is that there are bad
> (insecure) ECs (those from NIST which seem to be intentionally weakened /
> broken by various tricks) and good (secure) ECs (e.g. Ed25519).
>
I don't think this really accurately reflects the consensus of the security
> (insecure) ECs (those from NIST which seem to be intentionally weakened /
> broken by various tricks) and good (secure) ECs (e.g. Ed25519).
>
community, which is why all the major stacks continue to support the major
NIST prime curves (P-256 and P-384). I do think the consensus is that the
new curves are better (faster and easier to implement correctly) which is
why stacks have added them.
> In any case, as Kurt Roeckx observes, Firefox currently supports the new
> > non-NIST CFRG curves.
>
> Yes, and this is good news I didn't know about yet. I now only can hope
> that I will be able to configure my web server to offer ECDHE, but only the
> secure curves.
>
> The question remains why FF doesn't offer ciphers like
> dhe_rsa_aes_256_gcm_sha384. That would indeed allow administrators to turn
> off EC on their web servers completely. They then could easily configure a
> very secure web server without thinking about good and bad EC curves (which
> might be beyond the average part time administrator's knowledge anyway).
>
The consensus of the security community is to move people away from finite
> that I will be able to configure my web server to offer ECDHE, but only the
> secure curves.
>
> The question remains why FF doesn't offer ciphers like
> dhe_rsa_aes_256_gcm_sha384. That would indeed allow administrators to turn
> off EC on their web servers completely. They then could easily configure a
> very secure web server without thinking about good and bad EC curves (which
> might be beyond the average part time administrator's knowledge anyway).
>
field DH and towards ECDHE, so we're deemphasizing those cipher suites.
Chrome doesn't support them at all. FWIW, in TLS 1.3, group selection and
symmetric cipher are orthogonal so you will be able to use FFDH with any
cipher.
-Ekr
in...@binarus.de
Dec 23, 2016, 1:03:01 PM12/23/16
to mozilla-dev-s...@lists.mozilla.org
Eric,
thanks for your help again.
> > As far as I have understood, the consensus is that there are bad
> > (insecure) ECs (those from NIST which seem to be intentionally weakened /
> > broken by various tricks) and good (secure) ECs (e.g. Ed25519).
> >
>
> I don't think this really accurately reflects the consensus of the security
> community, which is why all the major stacks continue to support the major
> NIST prime curves (P-256 and P-384). I do think the consensus is that the
> new curves are better (faster and easier to implement correctly) which is
> why stacks have added them.
I am feeling the highest respect towards you because you took the time and know what you are talking about. But in this case, although not having much knowledge in cryptography yet, I have to disagree. I have read about possible side channels and intentional weaknesses of the NIST curves on dozens of trustworthy web sites.
There even is an RFC from the IETF titled "Elliptic Curves for Security" which lists which conditions an EC must fulfill to be secure, and then only recommends curve 25519 and curve 448. I am quite sure that the authors of that RFC also are deep in the matter, so I trust what they are saying.
Here is the link:
https://tools.ietf.org/html/draft-irtf-cfrg-curves-02
If you are interested, I could provide some more links to articles / white papers which clearly state that the NIST curves are probably contaminated and that they shouldn't be used.
Thanks again,
Binarus
thanks for your help again.
> > As far as I have understood, the consensus is that there are bad
> > (insecure) ECs (those from NIST which seem to be intentionally weakened /
> > broken by various tricks) and good (secure) ECs (e.g. Ed25519).
> >
>
> I don't think this really accurately reflects the consensus of the security
> community, which is why all the major stacks continue to support the major
> NIST prime curves (P-256 and P-384). I do think the consensus is that the
> new curves are better (faster and easier to implement correctly) which is
> why stacks have added them.
There even is an RFC from the IETF titled "Elliptic Curves for Security" which lists which conditions an EC must fulfill to be secure, and then only recommends curve 25519 and curve 448. I am quite sure that the authors of that RFC also are deep in the matter, so I trust what they are saying.
Here is the link:
https://tools.ietf.org/html/draft-irtf-cfrg-curves-02
If you are interested, I could provide some more links to articles / white papers which clearly state that the NIST curves are probably contaminated and that they shouldn't be used.
Thanks again,
Binarus
in...@binarus.de
Dec 23, 2016, 1:11:27 PM12/23/16
to mozilla-dev-s...@lists.mozilla.org
Kurt,
> Please note that for key exchange it's X25519. Ed25519 is for
> authentication.
thanks again for the valuable hint.
In the meantime, I have downloaded and compiled OpenSSL 1.1.0c for my web server. According to the following and many other articles, OpenSSL 1.1.x should support ed25519 / x25519:
https://certsimple.com/blog/safe-curves-and-openssl
But if I do ./openssl ecparam -list_curves, I indeed get a long list of supported curves, but no 25519 and no 448 among them. Did they remove it again in the newest version for some reason?
Please apologize if I am going off-topic - this question is probably for the OpenSSL mailing list, but on the other hand, it fits perfectly into the discussion here ...
Regards,
Binarus
> Please note that for key exchange it's X25519. Ed25519 is for
> authentication.
In the meantime, I have downloaded and compiled OpenSSL 1.1.0c for my web server. According to the following and many other articles, OpenSSL 1.1.x should support ed25519 / x25519:
https://certsimple.com/blog/safe-curves-and-openssl
But if I do ./openssl ecparam -list_curves, I indeed get a long list of supported curves, but no 25519 and no 448 among them. Did they remove it again in the newest version for some reason?
Please apologize if I am going off-topic - this question is probably for the OpenSSL mailing list, but on the other hand, it fits perfectly into the discussion here ...
Regards,
Binarus
Eric Rescorla
Dec 23, 2016, 1:40:26 PM12/23/16
to in...@binarus.de, mozilla-dev-s...@lists.mozilla.org
On Fri, Dec 23, 2016 at 10:02 AM, <in...@binarus.de> wrote:
> Eric,
>
> thanks for your help again.
>
> Eric,
>
> thanks for your help again.
>
> > > As far as I have understood, the consensus is that there are bad
> > > (insecure) ECs (those from NIST which seem to be intentionally
> weakened /
> > > broken by various tricks) and good (secure) ECs (e.g. Ed25519).
> > >
> >
> > I don't think this really accurately reflects the consensus of the
> security
> > community, which is why all the major stacks continue to support the
> major
> > NIST prime curves (P-256 and P-384). I do think the consensus is that the
> > new curves are better (faster and easier to implement correctly) which is
> > why stacks have added them.
>
> > > (insecure) ECs (those from NIST which seem to be intentionally
> weakened /
> > > broken by various tricks) and good (secure) ECs (e.g. Ed25519).
> > >
> >
> > I don't think this really accurately reflects the consensus of the
> security
> > community, which is why all the major stacks continue to support the
> major
> > NIST prime curves (P-256 and P-384). I do think the consensus is that the
> > new curves are better (faster and easier to implement correctly) which is
> > why stacks have added them.
>
> I am feeling the highest respect towards you because you took the time and
> know what you are talking about. But in this case, although not having much
> knowledge in cryptography yet, I have to disagree. I have read about
> possible side channels and intentional weaknesses of the NIST curves on
> dozens of trustworthy web sites.
>
> There even is an RFC from the IETF titled "Elliptic Curves for Security"
> which lists which conditions an EC must fulfill to be secure, and then only
> recommends curve 25519 and curve 448. I am quite sure that the authors of
> that RFC also are deep in the matter, so I trust what they are saying.
>
> Here is the link:
> https://tools.ietf.org/html/draft-irtf-cfrg-curves-02
Yes, I'm quite familiar with this document, which was an input to the CFRG
> know what you are talking about. But in this case, although not having much
> knowledge in cryptography yet, I have to disagree. I have read about
> possible side channels and intentional weaknesses of the NIST curves on
> dozens of trustworthy web sites.
>
> There even is an RFC from the IETF titled "Elliptic Curves for Security"
> which lists which conditions an EC must fulfill to be secure, and then only
> recommends curve 25519 and curve 448. I am quite sure that the authors of
> that RFC also are deep in the matter, so I trust what they are saying.
>
> Here is the link:
> https://tools.ietf.org/html/draft-irtf-cfrg-curves-02
process which was selecting a new curve (which resulted in X25519 and
X448). As the NIST curves already existed, it really wouldn't be sensible
to document requirements for selecting them.
As far as the authors of that RFC goes, I agree that they know what they
are talking about, but that's not evidence in favor of your argument.
Specifically:
- They are all members of the TLS WG, which put P-256 and P-384 into TLS
1.3 (Sean is the Chair)
- Adam works on BoringSSL at Google and both Chrome and Google support
P-256 (and disfavor DHE) though they prefer X25519
- Rich works on OpenSSL, which also supports the NIST curves.
Here's what Adam Langley says specifically about P256:
https://www.ietf.org/mail-archive/web/tls/current/msg12967.html
(the quoted section is Mike St Johns).
"> AFACT, one of the main reasons for looking at Curve25519 (possibly more
> important than performance or security) is that there is a fear that the
US
> Government has placed trapdoors in the current set of curves (NIST P256,
> P384, P521 etc).
Although some certainly subscribe to that, my main motivation for
moving away from P-{256,384} is that they simply aren't good curves.
They are difficult to implement correctly and have many pitfalls.
Elliptic curve design has advanced significantly since then."
I don't think anyone is debating that we should prefer X25519 to P256, and
NSS
does so, but that's far from meaning that the world would be a better place
if we
deprecated P256 in favor of FFDHE.
You are of course free to continue to believe whatever you like.
-Ekr
Pascal Ernster
Dec 23, 2016, 1:42:17 PM12/23/16
to dev-secur...@lists.mozilla.org
[2016-12-23 19:11] in...@binarus.de:
X448, and it does not support Ed25519 or Ed448 either (mainly because
EdDSA itself is not a finished standard/RFC yet, and there is no
finished RFC on the usage of that non-existent EdDSA standard in X.509
certificate keys).
Although OpenSSL 1.1.0 at least supports X25519 for ECDH(E), for some
reason unknown to me (although my guess would be that the reason is a
three-letter-work starting with a "B" and ending in a "G"), the "openssl
ecparam -list_curves" command doesn't list that curve. You can, however,
still use X25519 by using the "-name X25519" parameter (be careful about
the letter casing - you need to use a major X in "X25519"!).
regards
Pascal
> In the meantime, I have downloaded and compiled OpenSSL 1.1.0c for my web server. According to the following and many other articles, OpenSSL 1.1.x should support ed25519 / x25519:
>
> https://certsimple.com/blog/safe-curves-and-openssl
>
> But if I do ./openssl ecparam -list_curves, I indeed get a long list of supported curves, but no 25519 and no 448 among them. Did they remove it again in the newest version for some reason?
The 1.1.0 branch of OpenSSL does support X25519, but it does not support
>
> https://certsimple.com/blog/safe-curves-and-openssl
>
> But if I do ./openssl ecparam -list_curves, I indeed get a long list of supported curves, but no 25519 and no 448 among them. Did they remove it again in the newest version for some reason?
X448, and it does not support Ed25519 or Ed448 either (mainly because
EdDSA itself is not a finished standard/RFC yet, and there is no
finished RFC on the usage of that non-existent EdDSA standard in X.509
certificate keys).
Although OpenSSL 1.1.0 at least supports X25519 for ECDH(E), for some
reason unknown to me (although my guess would be that the reason is a
three-letter-work starting with a "B" and ending in a "G"), the "openssl
ecparam -list_curves" command doesn't list that curve. You can, however,
still use X25519 by using the "-name X25519" parameter (be careful about
the letter casing - you need to use a major X in "X25519"!).
regards
Pascal
in...@binarus.de
Dec 23, 2016, 7:41:58 PM12/23/16
to mozilla-dev-s...@lists.mozilla.org
Eric,
Well, I am a little bit stubborn by nature, but not when it comes to learning new facts about technical subjects. Thus, I am saying thanks again for illustrating how everything relates.
So everybody agrees that we should prefer 25519 over the other curves which are currently in use (which, by the way, is a thing I had learned a while ago when securing my SSH daemons - I just didn't know about FF's support for 25519 before opening this discussion). Given that, the reason why somebody prefers 25519 probably is not that important. Not everyone who believes that there are intentional weaknesses in the NIST curves seems to be a paranoid conspiracy theorist who ignores mathematics, and for sure, nobody who claims the opposite intentionally wants to harm security or to support government.
I didn't want to make the impression that the world would be better without elliptic curves. I just still can't understand why FF does not offer DHE with AES-GCM as an alternative. After all, it is supporting DHE with AES-non-GCM, so why not support it with AES-GCM as well? What is the advantage of dropping DHE (which seems to have become the policy)?
Solely from looking at the discussion we now had, IMHO it becomes clear that it is nearly impossible for an average part time administrator even to understand that there are different curves, let alone which of them he should chose, and let alone how he could configure his servers. Don't underestimate the fact that you are an expert, but in the real world, most web servers (nearly all in small organizations) are administered in part time by persons who won't understand anything of the stuff we have discussed here, not because they are stupid, but because their actual job is another one, and thus, they are allowed to dedicate only a few hours per month for checking, upgrading and improving security of the web server.
So, no, the world wouldn't be better without EC, but it perhaps would be somehow easier if we had DHE as an alternative (as a side note, not being totally inexperienced with Debian, I am failing for a complete working day now in making Apache run with OpenSSL and ECDHE in a way that 25519 is used; I think I will be able to solve this, but I don't know how it will take).
But now to something completely different:
Merry XMas and a happy new year!
Regards,
Binarus
So everybody agrees that we should prefer 25519 over the other curves which are currently in use (which, by the way, is a thing I had learned a while ago when securing my SSH daemons - I just didn't know about FF's support for 25519 before opening this discussion). Given that, the reason why somebody prefers 25519 probably is not that important. Not everyone who believes that there are intentional weaknesses in the NIST curves seems to be a paranoid conspiracy theorist who ignores mathematics, and for sure, nobody who claims the opposite intentionally wants to harm security or to support government.
I didn't want to make the impression that the world would be better without elliptic curves. I just still can't understand why FF does not offer DHE with AES-GCM as an alternative. After all, it is supporting DHE with AES-non-GCM, so why not support it with AES-GCM as well? What is the advantage of dropping DHE (which seems to have become the policy)?
Solely from looking at the discussion we now had, IMHO it becomes clear that it is nearly impossible for an average part time administrator even to understand that there are different curves, let alone which of them he should chose, and let alone how he could configure his servers. Don't underestimate the fact that you are an expert, but in the real world, most web servers (nearly all in small organizations) are administered in part time by persons who won't understand anything of the stuff we have discussed here, not because they are stupid, but because their actual job is another one, and thus, they are allowed to dedicate only a few hours per month for checking, upgrading and improving security of the web server.
So, no, the world wouldn't be better without EC, but it perhaps would be somehow easier if we had DHE as an alternative (as a side note, not being totally inexperienced with Debian, I am failing for a complete working day now in making Apache run with OpenSSL and ECDHE in a way that 25519 is used; I think I will be able to solve this, but I don't know how it will take).
But now to something completely different:
Merry XMas and a happy new year!
Regards,
Binarus
Yuhong Bao
Dec 23, 2016, 8:15:35 PM12/23/16
to in...@binarus.de, mozilla-dev-s...@lists.mozilla.org
AFAIK one of the reasons DHE was dropped was that 1024-bit DHE was common. Java used to hardcode 768-bit DHE.
________________________________________
From: dev-security-policy <dev-security-policy-bounces+yuhongbao_386=hotma...@lists.mozilla.org> on behalf of in...@binarus.de <in...@binarus.de>
Sent: Friday, December 23, 2016 4:41:48 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers
Eric,
________________________________________
From: dev-security-policy <dev-security-policy-bounces+yuhongbao_386=hotma...@lists.mozilla.org> on behalf of in...@binarus.de <in...@binarus.de>
Sent: Friday, December 23, 2016 4:41:48 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers
Eric,
Well, I am a little bit stubborn by nature, but not when it comes to learning new facts about technical subjects. Thus, I am saying thanks again for illustrating how everything relates.
So everybody agrees that we should prefer 25519 over the other curves which are currently in use (which, by the way, is a thing I had learned a while ago when securing my SSH daemons - I just didn't know about FF's support for 25519 before opening this discussion). Given that, the reason why somebody prefers 25519 probably is not that important. Not everyone who believes that there are intentional weaknesses in the NIST curves seems to be a paranoid conspiracy theorist who ignores mathematics, and for sure, nobody who claims the opposite intentionally wants to harm security or to support government.
I didn't want to make the impression that the world would be better without elliptic curves. I just still can't understand why FF does not offer DHE with AES-GCM as an alternative. After all, it is supporting DHE with AES-non-GCM, so why not support it with AES-GCM as well? What is the advantage of dropping DHE (which seems to have become the policy)?
Solely from looking at the discussion we now had, IMHO it becomes clear that it is nearly impossible for an average part time administrator even to understand that there are different curves, let alone which of them he should chose, and let alone how he could configure his servers. Don't underestimate the fact that you are an expert, but in the real world, most web servers (nearly all in small organizations) are administered in part time by persons who won't understand anything of the stuff we have discussed here, not because they are stupid, but because their actual job is another one, and thus, they are allowed to dedicate only a few hours per month for checking, upgrading and improving security of the web server.
So, no, the world wouldn't be better without EC, but it perhaps would be somehow easier if we had DHE as an alternative (as a side note, not being totally inexperienced with Debian, I am failing for a complete working day now in making Apache run with OpenSSL and ECDHE in a way that 25519 is used; I think I will be able to solve this, but I don't know how it will take).
But now to something completely different:
Merry XMas and a happy new year!
Regards,
So everybody agrees that we should prefer 25519 over the other curves which are currently in use (which, by the way, is a thing I had learned a while ago when securing my SSH daemons - I just didn't know about FF's support for 25519 before opening this discussion). Given that, the reason why somebody prefers 25519 probably is not that important. Not everyone who believes that there are intentional weaknesses in the NIST curves seems to be a paranoid conspiracy theorist who ignores mathematics, and for sure, nobody who claims the opposite intentionally wants to harm security or to support government.
I didn't want to make the impression that the world would be better without elliptic curves. I just still can't understand why FF does not offer DHE with AES-GCM as an alternative. After all, it is supporting DHE with AES-non-GCM, so why not support it with AES-GCM as well? What is the advantage of dropping DHE (which seems to have become the policy)?
Solely from looking at the discussion we now had, IMHO it becomes clear that it is nearly impossible for an average part time administrator even to understand that there are different curves, let alone which of them he should chose, and let alone how he could configure his servers. Don't underestimate the fact that you are an expert, but in the real world, most web servers (nearly all in small organizations) are administered in part time by persons who won't understand anything of the stuff we have discussed here, not because they are stupid, but because their actual job is another one, and thus, they are allowed to dedicate only a few hours per month for checking, upgrading and improving security of the web server.
So, no, the world wouldn't be better without EC, but it perhaps would be somehow easier if we had DHE as an alternative (as a side note, not being totally inexperienced with Debian, I am failing for a complete working day now in making Apache run with OpenSSL and ECDHE in a way that 25519 is used; I think I will be able to solve this, but I don't know how it will take).
But now to something completely different:
Merry XMas and a happy new year!
Regards,
Peter Gutmann
Dec 23, 2016, 11:21:34 PM12/23/16
to Eric Rescorla, in...@binarus.de, mozilla-dev-s...@lists.mozilla.org
Eric Rescorla <e...@rtfm.com> writes:
>I don't think this really accurately reflects the consensus of the security
>community
Or of any community AFAIK. Perhaps there could be a special version of
Firefox that uses one-time pads for everything, and on startup uses a
cryptographically secure geolocation service to direct you to your nearest
supermarket for a roll of tinfoil, along with folding instructions for the
hat.
For the OP, Google "Shamir's Law". 99.99% of web users could be using single
DES and it'd still be somewhere around the bottom of page 50 of the list of
ways in which they're going to get 0wned.
Peter.
in...@binarus.de
Dec 24, 2016, 8:08:19 AM12/24/16
to mozilla-dev-s...@lists.mozilla.org
Am Samstag, 24. Dezember 2016 05:21:34 UTC+1 schrieb Peter Gutmann:
Although this is correct, it shouldn't keep administrators / companies from desperately trying to offer the most secure encryption, especially if they are located in countries where they are obligated by law to use the best known methods and otherwise are in permanent danger to get sued. Please note that my actual reason for posting was that I am trying to build a secure web site, and thus, I am feeling the strongest personal obligation (besides the obligation by law) to make it as secure as possible.
Furthermore, it is eventually not wise to laugh at all people who believe that governments have the will and the means to poison cryptographic methods and to consider all of them weird conspiracy theorists who ignore maths. There are enough mathematicians who consider this a real danger.
It is my private, political (and thus off-topic) opinion that cryptography should be as secure as possible, so if I have a choice (which is luckily the case here), I am avoiding anything which is suspected to be weakened, even if there is no clear proof yet.
If you are sure, absolutely sure and ready to guarantee with your life for it, that organizations which are backed by hundreds of billions of dollars per year and which have the main aim to break cryptographic methods have not found any means to intentionally weaken the NIST curves given the complexity of their implementation, i.e. that your knowledge is higher than or at least equal to the sum of the knowledge of all the scientists and mathematicians who work for these organizations and who dedicate their whole life, every minute, every day to misleading, weakening and breaking cryptography, then (and only then) you may laugh at me and all the others who are concerned. In that case, we probably deserve a big roll of tin foil.
Otherwise, you eventually should respect that there are a lot of people who are not overly stupid or paranoid and who are concerned about the issue. For sure, there is a reason for the fact that nearly all websites which come up when you do a search for cryptographic curves strongly discourage the usage of the NIST curves. Are they all paranoid idiots ignoring mathematics? Or is it just a temporary fashion to warn about NIST curves?
And by the way, the law you mentioned exactly is one the things which can't serve as an argument here. Statistics say that one day I will probably die because of a heart problem (I'm located in Germany) and nearly sure not in a car crash which happens because of a defective car. But this is absolutely no reason to stop the yearly inspections of my car, even less if I regularly take other persons with me. YMMV ...
Regards and thank you very much for your comments (indeed, didn't know about Shamir's Law yet),
Binarus
Furthermore, it is eventually not wise to laugh at all people who believe that governments have the will and the means to poison cryptographic methods and to consider all of them weird conspiracy theorists who ignore maths. There are enough mathematicians who consider this a real danger.
It is my private, political (and thus off-topic) opinion that cryptography should be as secure as possible, so if I have a choice (which is luckily the case here), I am avoiding anything which is suspected to be weakened, even if there is no clear proof yet.
If you are sure, absolutely sure and ready to guarantee with your life for it, that organizations which are backed by hundreds of billions of dollars per year and which have the main aim to break cryptographic methods have not found any means to intentionally weaken the NIST curves given the complexity of their implementation, i.e. that your knowledge is higher than or at least equal to the sum of the knowledge of all the scientists and mathematicians who work for these organizations and who dedicate their whole life, every minute, every day to misleading, weakening and breaking cryptography, then (and only then) you may laugh at me and all the others who are concerned. In that case, we probably deserve a big roll of tin foil.
Otherwise, you eventually should respect that there are a lot of people who are not overly stupid or paranoid and who are concerned about the issue. For sure, there is a reason for the fact that nearly all websites which come up when you do a search for cryptographic curves strongly discourage the usage of the NIST curves. Are they all paranoid idiots ignoring mathematics? Or is it just a temporary fashion to warn about NIST curves?
And by the way, the law you mentioned exactly is one the things which can't serve as an argument here. Statistics say that one day I will probably die because of a heart problem (I'm located in Germany) and nearly sure not in a car crash which happens because of a defective car. But this is absolutely no reason to stop the yearly inspections of my car, even less if I regularly take other persons with me. YMMV ...
Regards and thank you very much for your comments (indeed, didn't know about Shamir's Law yet),
Binarus
in...@binarus.de
Dec 24, 2016, 8:33:29 AM12/24/16
to mozilla-dev-s...@lists.mozilla.org
Am Samstag, 24. Dezember 2016 02:15:35 UTC+1 schrieb Yuhong Bao:
> AFAIK one of the reasons DHE was dropped was that 1024-bit DHE was common. Java used to hardcode 768-bit DHE.
This is a good point.
> AFAIK one of the reasons DHE was dropped was that 1024-bit DHE was common. Java used to hardcode 768-bit DHE.
Nevertheless, when using DHE, I always have been doing so with DH params I have generated myself with sufficient key length. It didn't take much time to find out how to do that and how to make Apache use these params. No modifications of my favorite Linux distribution's Apache or OpenSSL were needed to do that.
In contrast, I am trying to make Apache and OpenSSL run with ECDHE and curve 25519 for nearly two days now without success. I have to modify a central, security critical component of the system in question (OpenSSL) by downloading the sources, compiling myself and replacing my system's OpenSSL (or possibly I have to run both versions in parallel due to some weird dependencies).
Consequently, in the next future, I can't rely on the security updates for my distribution, but will have to monitor OpenSSL advisories myself, and if there is a problem, I will have to fix it myself - redownload, reconfigure, recompile, reinstall, possibly fight with the dependencies again, and so on. No, I really didn't want to become the maintainer of my own OpenSSL package ...
I had some private communication with a very helpful and experienced person in the meantime, and he detailed to me that no Linux Distribution (possibly with one exception) uses an OpenSSL version which supports X25519. Furthermore, the OpenSSL versions which claim to support 25519 seem to be buggy / broken (openssl ecparam -list_curves does not show 25519 although it is claimed to be there; tested with OpenSSL 1.1.0c yesterday).
So, comparing the hassle with ECs to the hassle I had with generating safe DH params, the latter one has been ridiculously easy. Therefore, I regret the communities policy of giving up DHE.
But I have understood that I have to accept that policy, and I won't complain any more. The only thing I now can do is trying to make 25519 work.
Thank you very much,
Binarus
Jakob Bohm
Dec 27, 2016, 12:06:03 PM12/27/16
to mozilla-dev-s...@lists.mozilla.org
On 24/12/2016 14:33, in...@binarus.de wrote:
>
> ...
>
> I had some private communication with a very helpful and experienced
> person in the meantime, and he detailed to me that no Linux
> Distribution (possibly with one exception) uses an OpenSSL version
> which supports X25519. Furthermore, the OpenSSL versions which claim
> to support 25519 seem to be buggy / broken (openssl ecparam -list_curves
> does not show 25519 although it is claimed to be there; tested with
> OpenSSL 1.1.0c yesterday).
>
I believe this may be because Ed25519 and X25519 use slightly different
>
> ...
>
> I had some private communication with a very helpful and experienced
> person in the meantime, and he detailed to me that no Linux
> Distribution (possibly with one exception) uses an OpenSSL version
> which supports X25519. Furthermore, the OpenSSL versions which claim
> to support 25519 seem to be buggy / broken (openssl ecparam -list_curves
> does not show 25519 although it is claimed to be there; tested with
> OpenSSL 1.1.0c yesterday).
>
operations than the standard curves and thus cannot simply be popped
into the generic functions that handle the NIST, BrainPool etc. curves
with common code for e.g. ECDSA, ECDHE etc.
Because the -list_curves command line option is a wrapper around
functions that map strings to arguments for those generic EC functions,
it doesn't list curves that won't work in that particular context.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
0 new messages