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

2016-12-27 Thread Jakob Bohm
On 24/12/2016 14:33, i...@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

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

2016-12-24 Thread info
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. Nevertheless, when using DHE, I always have been doing so with DH params I have generated

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

2016-12-24 Thread info
Am Samstag, 24. Dezember 2016 05:21:34 UTC+1 schrieb 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

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

2016-12-23 Thread 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

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

2016-12-23 Thread Yuhong Bao
.de <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 sel

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

2016-12-23 Thread 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

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

2016-12-23 Thread 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

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

2016-12-23 Thread 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

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

2016-12-23 Thread 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

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

2016-12-23 Thread 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

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

2016-12-23 Thread 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

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

2016-12-23 Thread 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.

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

2016-12-23 Thread 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

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

2016-12-22 Thread Eric Rescorla
On Wed, Dec 21, 2016 at 11:58 PM, 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,

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

2016-12-22 Thread Kurt Roeckx
On 2016-12-22 08:58, i...@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

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

2016-12-22 Thread info
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