You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Jan-Frode Myklebust <ja...@tanso.net> on 2013/11/24 15:47:49 UTC
Forward Secrecy ?
Is it possible to configure ATS for forward secrecy? I've tried using
the same cipher suites as we use for apache httpd, but don't seem to get
the DHE or ECDHE cipher suites enabled with ATS..
-jf
Re: Forward Secrecy ?
Posted by James Peach <jp...@apache.org>.
On Nov 25, 2013, at 12:22 AM, Igor Galić <i....@brainsware.org> wrote:
>
>
> ----- Original Message -----
>> Here's the commit adding ECDHE support to apache httpd:
>>
>> http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3C20091110075514.166A6238890A@eris.apache.org%3E
>
> What this code does is more than just an initial throw, it enables to use
> ECC /keys/ all we need to start using ECDHE is the initialization.
>
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?rev=834378&r1=834377&r2=834378&view=diff
>
>> and for stud:
>>
>> https://github.com/bumptech/stud/pull/61/files
>
> Wow. That's bad. That looks specifically for the *bad* NSA curve constants
> before initializing the ec code. That's not something I'd rely on, since
> not even NIST is any more.
I believe that this code originates from an OpenSSL mailing list recommendation from the OpenSSL devs. Do you have the list of "bad" NIST curves?
J
Re: Forward Secrecy ?
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On Mon, Nov 25, 2013 at 08:22:35AM +0000, Igor Galić wrote:
> >
> > > and for stud:
> > >
> > > https://github.com/bumptech/stud/pull/61/files
> >
> > Wow. That's bad. That looks specifically for the *bad* NSA curve constants
> > before initializing the ec code. That's not something I'd rely on, since
> > not even NIST is any more.
>
> Are there any other relevant curve constants that's usable? Looks to me
> like everyone is using NIST P-384 or NIST P-256, and these are the only
> once available as named curves in my openssl library.
>
> $ openssl ecparam -list_curves
> secp384r1 : NIST/SECG curve over a 384 bit prime field
> prime256v1: X9.62/SECG curve over a 256 bit prime field
igalic@levix ~ % openssl ecparam -list_curves | grep -c :
67
igalic@levix ~ % openssl version
OpenSSL 1.0.1e 11 Feb 2013
igalic@levix ~ %
> BTW: James Peach has already come up with a patch implementing the ECDHE
> ciphers using NIST P-256, so now my test server is forward secret for
> most clients:
>
> https://www.ssllabs.com/ssltest/analyze.html?d=dibs.tanso.net
>
>
> -jf
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: Forward Secrecy ?
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On Mon, Nov 25, 2013 at 10:47:42PM +0000, Igor Galić wrote:
> >
> > Every curve that comes from J. A. Solinas I would declare on the simple
> > basis that they work for the NSA as untrustworthy, no matter whether
> > these constants are good or bad or NIST recommended and in an RFC simply
> > for having all together produced and standardized DUAL_EC_DRBG.
> >
> > Frankly, I think we should prepare the code, but wait out the storm as
> > to which algorithms to chose.
>
> But can the server dictate any other curves than what the browsers
> support ? As far as I understand NIST P-256 and P-384 are the only
> curves widely supported by browsers..
>
> http://security.stackexchange.com/questions/31772/what-elliptic-curves-are-supported-by-browsers
> http://security.stackexchange.com/questions/42088/can-custom-elliptic-curves-be-used-in-common-tls-implementations
> http://www.carbonwind.net/blog/post/A-quick-look-over-some-browsers-and-their-SSLTLS-implementations.aspx
>
> plus I suspect curve25519 might soon be available in chrome, and others
> might follow:
>
> http://www.ietf.org/mail-archive/web/tls/current/msg05852.html
> (interesting thread, and it casts some doubt to if the NIST curves can be
> backdoored..)
With my tin-foil hat on, I'd like to say that it doesn't matter whether
they technically can, or cannot be backdoored. It is still questionable.
The trust in NIST and the standardization process is broken. That trust
needs to be rebuild.
> -jf
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: Forward Secrecy ?
Posted by Jan-Frode Myklebust <ja...@tanso.net>.
On Mon, Nov 25, 2013 at 10:47:42PM +0000, Igor Galić wrote:
>
> Every curve that comes from J. A. Solinas I would declare on the simple
> basis that they work for the NSA as untrustworthy, no matter whether
> these constants are good or bad or NIST recommended and in an RFC simply
> for having all together produced and standardized DUAL_EC_DRBG.
>
> Frankly, I think we should prepare the code, but wait out the storm as
> to which algorithms to chose.
But can the server dictate any other curves than what the browsers
support ? As far as I understand NIST P-256 and P-384 are the only
curves widely supported by browsers..
http://security.stackexchange.com/questions/31772/what-elliptic-curves-are-supported-by-browsers
http://security.stackexchange.com/questions/42088/can-custom-elliptic-curves-be-used-in-common-tls-implementations
http://www.carbonwind.net/blog/post/A-quick-look-over-some-browsers-and-their-SSLTLS-implementations.aspx
plus I suspect curve25519 might soon be available in chrome, and others
might follow:
http://www.ietf.org/mail-archive/web/tls/current/msg05852.html
(interesting thread, and it casts some doubt to if the NIST curves can be backdoored..)
-jf
Re: Forward Secrecy ?
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On Nov 25, 2013, at 1:02 AM, Jan-Frode Myklebust <ja...@tanso.net> wrote:
>
> > On Mon, Nov 25, 2013 at 08:22:35AM +0000, Igor Galić wrote:
> >>
> >>> and for stud:
> >>>
> >>> https://github.com/bumptech/stud/pull/61/files
> >>
> >> Wow. That's bad. That looks specifically for the *bad* NSA curve constants
> >> before initializing the ec code. That's not something I'd rely on, since
> >> not even NIST is any more.
> >
> > Are there any other relevant curve constants that's usable? Looks to me
> > like everyone is using NIST P-384 or NIST P-256, and these are the only
> > once available as named curves in my openssl library.
>
> P-256 is also recommended here,
> https://www.imperialviolet.org/2011/11/22/forwardsecret.html
That's from 2010, a long time ago ;)
To quote Bruce Schneier,
"I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry."
- https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929
Every curve that comes from J. A. Solinas I would declare on the simple
basis that they work for the NSA as untrustworthy, no matter whether
these constants are good or bad or NIST recommended and in an RFC simply
for having all together produced and standardized DUAL_EC_DRBG.
Frankly, I think we should prepare the code, but wait out the storm as
to which algorithms to chose.
> J
++ i
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: Forward Secrecy ?
Posted by James Peach <jp...@apache.org>.
On Nov 25, 2013, at 1:02 AM, Jan-Frode Myklebust <ja...@tanso.net> wrote:
> On Mon, Nov 25, 2013 at 08:22:35AM +0000, Igor Galić wrote:
>>
>>> and for stud:
>>>
>>> https://github.com/bumptech/stud/pull/61/files
>>
>> Wow. That's bad. That looks specifically for the *bad* NSA curve constants
>> before initializing the ec code. That's not something I'd rely on, since
>> not even NIST is any more.
>
> Are there any other relevant curve constants that's usable? Looks to me
> like everyone is using NIST P-384 or NIST P-256, and these are the only
> once available as named curves in my openssl library.
P-256 is also recommended here, https://www.imperialviolet.org/2011/11/22/forwardsecret.html
J
Re: Forward Secrecy ?
Posted by Jan-Frode Myklebust <ja...@tanso.net>.
On Mon, Nov 25, 2013 at 08:22:35AM +0000, Igor Galić wrote:
>
> > and for stud:
> >
> > https://github.com/bumptech/stud/pull/61/files
>
> Wow. That's bad. That looks specifically for the *bad* NSA curve constants
> before initializing the ec code. That's not something I'd rely on, since
> not even NIST is any more.
Are there any other relevant curve constants that's usable? Looks to me
like everyone is using NIST P-384 or NIST P-256, and these are the only
once available as named curves in my openssl library.
$ openssl ecparam -list_curves
secp384r1 : NIST/SECG curve over a 384 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
BTW: James Peach has already come up with a patch implementing the ECDHE
ciphers using NIST P-256, so now my test server is forward secret for
most clients:
https://www.ssllabs.com/ssltest/analyze.html?d=dibs.tanso.net
-jf
Re: Forward Secrecy ?
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> Here's the commit adding ECDHE support to apache httpd:
>
> http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3C20091110075514.166A6238890A@eris.apache.org%3E
What this code does is more than just an initial throw, it enables to use
ECC /keys/ all we need to start using ECDHE is the initialization.
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?rev=834378&r1=834377&r2=834378&view=diff
> and for stud:
>
> https://github.com/bumptech/stud/pull/61/files
Wow. That's bad. That looks specifically for the *bad* NSA curve constants
before initializing the ec code. That's not something I'd rely on, since
not even NIST is any more.
> I created jira ticket TS-2392 for this.
>
>
> -jf
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: Forward Secrecy ?
Posted by Jan-Frode Myklebust <ja...@tanso.net>.
Here's the commit adding ECDHE support to apache httpd:
http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3C20091110075514.166A6238890A@eris.apache.org%3E
and for stud:
https://github.com/bumptech/stud/pull/61/files
I created jira ticket TS-2392 for this.
-jf
Re: Forward Secrecy ?
Posted by Jan-Frode Myklebust <ja...@tanso.net>.
On Sun, Nov 24, 2013 at 08:56:30AM -0800, James Peach wrote:
> On Nov 24, 2013, at 6:47 AM, Jan-Frode Myklebust <ja...@tanso.net> wrote:
>
> > Is it possible to configure ATS for forward secrecy? I've tried using
> > the same cipher suites as we use for apache httpd,
>
> Since it works in httpd, I assume that your OpenSSL supports the right set of cipher suites?
Yes, it should. Here's a httpd/mod_ssl/openssl-1.0.1e-16.el6_5.x86_64 report:
SSLCipherSuite EECDH+AES:EECDH+RC4:EECDH+AES256:EDH+AES:EDH+RC4:EDH+AES256:RC4-SHA:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
https://www.ssllabs.com/ssltest/analyze.html?d=altibetamail.altibox.net
and ATS 4.0.2/openssl-1.0.1e-16.el6_5.x86_64 using same cipher list:
CONFIG proxy.config.ssl.server.cipher_suite STRING EECDH+AES:EECDH+RC4:EECDH+AES256:EDH+AES:EDH+RC4:EDH+AES256:RC4-SHA:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
https://www.ssllabs.com/ssltest/analyze.html?d=dibs.tanso.net
Of the cipher list, only these are offered with ATS:
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
httpd/mod_ssl additionally offers:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) FS
-jf
Re: Forward Secrecy ?
Posted by James Peach <jp...@apache.org>.
On Nov 24, 2013, at 6:47 AM, Jan-Frode Myklebust <ja...@tanso.net> wrote:
> Is it possible to configure ATS for forward secrecy? I've tried using
> the same cipher suites as we use for apache httpd,
Since it works in httpd, I assume that your OpenSSL supports the right set of cipher suites?
> but don't seem to get
> the DHE or ECDHE cipher suites enabled with ATS..
Bryan was looking at this recently, maybe he found something ...
J