Re: [FORGED] Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[Peter Gutmann]

Eric Rescorla  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[Yuhong Bao]

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 
 on 
behalf of i...@binarus.de 
Sent: Friday, December 23, 2016 4:41:48 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

Eric,

> Yes, I'm quite familiar with this document, which was an input to the CFRG
> 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.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[info]

Eric,

> Yes, I'm quite familiar with this document, which was an input to the CFRG
> 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.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[Pascal Ernster]

[2016-12-23 19:11] i...@binarus.de:

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 
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[Eric Rescorla]

On Fri, Dec 23, 2016 at 10:02 AM,  wrote:

> 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


Yes, I'm quite familiar with this document, which was an input to the CFRG
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[info]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[info]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[Eric Rescorla]

On Fri, Dec 23, 2016 at 1:53 AM,  wrote:

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

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.


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




>
> Binarus
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

[Gervase Markham]

On 22/12/16 14:30, Tom Delmas wrote:
> There are other mechanisms. But hard to use, especially between
> countries. As a Firefox user,
> I expect that CA trusted by Firefox are clearly identifiable and
> distinguishable from each others.

If CAs ever did something specific to Firefox or the root program, such
as submitting a root cert for inclusion whose common name was
misleading, we may well take action on that.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[info]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

[info]

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.
> [...]
> 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.
> [...]
> 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).

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy