You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Reindl Harald <h....@thelounge.net> on 2015/04/01 12:04:59 UTC
5.2.1: DHE ciphers gone?
Hi
why are DHE ciphers no longer available after update to 5.2.1?
the crtificate files are PEM with
* intermediate CA
* private key
* certificate
* ec params
* dh params
in a single file which is supported for a long time by httpd and worked
with the previous ATS release too (which introduced DHE at all)
Re: 5.2.1: DHE ciphers gone?
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.04.2015 um 19:45 schrieb David Boreham:
> Quick comment in case you weren't already aware of this:
>
> I don't know anything about the specific problems Leif mentioned (but
> they would be related if the issue was with configuring DHE parameter
> values), but I have spent some time looking into DHE recently:
>
> There are concerns that the parameter size should now be larger than was
> historically typical (2048-bit vs 1024-bit). However, there is no
> mechanism in the protocol to negotiate the DHE parameter size.
> Furthermore there are clients fairly commonly encountered (e.g. Java
> JSSE older than very recent releases) that do not accept a 2048-bit DHE
> parameter from a server, and do not act gracefully as a result. For
> these reasons it seems that DHE is normally best disabled on the server
> (the problematic clients do mostly have support for ECDHE so they work
> with ECDHE if DHE is not a supported server cipher) because the
> alternatives are either (a) become incompatible with some clients or (b)
> allow less than best-practice protection from brute-force attacks
nope - fact is that without offer DHE you are incompatible with older
clients which would support forward secrecy with DHE but not ECDHE and
because the problem with the keysizes
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile and
"Additional optional elements are DH parameters and/or an EC curve name
for ephemeral keys, as generated by openssl dhparam and openssl ecparam,
respectively (supported in version 2.4.7 or later) and finally, the
end-entity certificate's private key. If the private key is encrypted,
the pass phrase dialog is forced at startup time"
ssllabs reflected this not so long ago very goody by "handshake failed"
or a client supporting DHE just use a different cipher suite and no
forward secrecy
Re: 5.2.1: DHE ciphers gone?
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.04.2015 um 03:25 schrieb Leif Hedstrom:
>> On Apr 5, 2015, at 11:54 AM, Reindl Harald <h....@thelounge.net> wrote:
>>
>> Am 01.04.2015 um 19:45 schrieb David Boreham:
>>> There are concerns that the parameter size should now be larger than was
>>> historically typical (2048-bit vs 1024-bit). However, there is no
>>> mechanism in the protocol to negotiate the DHE parameter size.
>>> Furthermore there are clients fairly commonly encountered (e.g. Java
>>> JSSE older than very recent releases) that do not accept a 2048-bit DHE
>>> parameter from a server, and do not act gracefully as a result. For
>>> these reasons it seems that DHE is normally best disabled on the server
>>
>> wrong justification, that affects Java6 which don't support SNI and hence is anyways out of the game when it comes to ATS, all other known clients supporting DHE while not ECDHE are happy with a 2048 prime
>
> Besides the other stuff, what does not having SNI in Java6 and ATS have to do with each other? ATS most certainly supports setup which do not require SNI. You can configure certificates based on the server IP in the configuration.
interesting but not expected from a enduser like me but to be honest the
whole issue and discussions would not exist if ATS would handle a
certfile identical to httpd because with a PEM file strcutucre below it
would contain the whole chain as well as ECDHE and DHE params
if it then would read the certificates as root before drop privileges
(like httpd) you could even re-use the same wildcard-certificates
without make a copy with wide open permissions
that would make "dhparams_file" obsolete or at least optional for DHE
usage while not present as now could disable them completly
-----BEGIN CERTIFICATE-----
certificate
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
key
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
intermediate CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
intermediate CA
-----END CERTIFICATE-----
-----BEGIN EC PARAMETERS-----
BggqhkjOPQMBBw==
-----END EC PARAMETERS-----
-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEAsac1gnF4WOUXc54XNc/JiEdgPzF9vYroubsPTx3eFQoyW1MUUXmj
b65ATEwn4iMkQvee7GEiuWsr1kM5FUeoggYs7LV9asKjvhvMuvNkonmPh4zxvuNR
m8dV7wy9N+UnIR02vxKwWNCGroQAu1Glj+kI1dfTMcJbBy9RLVnfGIx/2wnBkZ+W
Rk5+RrMZfl9JKWq1k2yaZ1TM2arGQ0vQCOZwi8szYwAgBwOYTl0qZbr02qqFww89
Yn0CfMOpjzRsrw3Md+miJWPxhPUcGQKcJ6aW979lYHqX8YY46M2wardjqZhpJric
l52c11s3i39YM75txNrQeW4gXtlMfV6NgwIBAg==
-----END DH PARAMETERS-----
Re: 5.2.1: DHE ciphers gone?
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 5, 2015, at 11:54 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 01.04.2015 um 19:45 schrieb David Boreham:
>> There are concerns that the parameter size should now be larger than was
>> historically typical (2048-bit vs 1024-bit). However, there is no
>> mechanism in the protocol to negotiate the DHE parameter size.
>> Furthermore there are clients fairly commonly encountered (e.g. Java
>> JSSE older than very recent releases) that do not accept a 2048-bit DHE
>> parameter from a server, and do not act gracefully as a result. For
>> these reasons it seems that DHE is normally best disabled on the server
>
> wrong justification, that affects Java6 which don't support SNI and hence is anyways out of the game when it comes to ATS, all other known clients supporting DHE while not ECDHE are happy with a 2048 prime
Besides the other stuff, what does not having SNI in Java6 and ATS have to do with each other? ATS most certainly supports setup which do not require SNI. You can configure certificates based on the server IP in the configuration.
— leif
Re: 5.2.1: DHE ciphers gone?
Posted by David Boreham <da...@bozemanpass.com>.
fwiw IME Java 1.7 prior to very recent updates is similarly affected,
but you seem to have a good gasp of this issue so I will defer to your
superior knowledge here..
On 4/5/2015 11:54 AM, Reindl Harald wrote:
>
> Am 01.04.2015 um 19:45 schrieb David Boreham:
>> There are concerns that the parameter size should now be larger than was
>> historically typical (2048-bit vs 1024-bit). However, there is no
>> mechanism in the protocol to negotiate the DHE parameter size.
>> Furthermore there are clients fairly commonly encountered (e.g. Java
>> JSSE older than very recent releases) that do not accept a 2048-bit DHE
>> parameter from a server, and do not act gracefully as a result. For
>> these reasons it seems that DHE is normally best disabled on the server
>
> wrong justification, that affects Java6 which don't support SNI and
> hence is anyways out of the game when it comes to ATS, all other known
> clients supporting DHE while not ECDHE are happy with a 2048 prime
>
> Java 6u45 No SNI 2 Client does not support DH parameters > 1024 bits
>
Re: 5.2.1: DHE ciphers gone?
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.04.2015 um 19:45 schrieb David Boreham:
> There are concerns that the parameter size should now be larger than was
> historically typical (2048-bit vs 1024-bit). However, there is no
> mechanism in the protocol to negotiate the DHE parameter size.
> Furthermore there are clients fairly commonly encountered (e.g. Java
> JSSE older than very recent releases) that do not accept a 2048-bit DHE
> parameter from a server, and do not act gracefully as a result. For
> these reasons it seems that DHE is normally best disabled on the server
wrong justification, that affects Java6 which don't support SNI and
hence is anyways out of the game when it comes to ATS, all other known
clients supporting DHE while not ECDHE are happy with a 2048 prime
Java 6u45 No SNI 2 Client does not support DH parameters > 1024 bits
Re: 5.2.1: DHE ciphers gone?
Posted by David Boreham <da...@bozemanpass.com>.
Quick comment in case you weren't already aware of this:
I don't know anything about the specific problems Leif mentioned (but
they would be related if the issue was with configuring DHE parameter
values), but I have spent some time looking into DHE recently:
There are concerns that the parameter size should now be larger than was
historically typical (2048-bit vs 1024-bit). However, there is no
mechanism in the protocol to negotiate the DHE parameter size.
Furthermore there are clients fairly commonly encountered (e.g. Java
JSSE older than very recent releases) that do not accept a 2048-bit DHE
parameter from a server, and do not act gracefully as a result. For
these reasons it seems that DHE is normally best disabled on the server
(the problematic clients do mostly have support for ECDHE so they work
with ECDHE if DHE is not a supported server cipher) because the
alternatives are either (a) become incompatible with some clients or (b)
allow less than best-practice protection from brute-force attacks.
Re: 5.2.1: DHE ciphers gone?
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.04.2015 um 19:05 schrieb James Peach:
>
>> On Apr 1, 2015, at 9:56 AM, Reindl Harald <h....@thelounge.net> wrote:
>>
>>
>>
>> Am 01.04.2015 um 15:30 schrieb Leif Hedstrom:
>>> It was decided from experiences at LinkedIn that DHE was unstable and/or causing problems in general. It was deemed an incompatible change that should not have happened in the 5.x cycle, so we restored defaults to a state as it was in 5.1. I'll let Thomas and Brian give more details on the issues with DHE.
>>>
>>> You can still use DHE but you would have to move the params into a file and explicitly tell ATS to use those params.
>>
>> but in which file and how to configure - the docs don't mention it?
>>
>> IMHO the certs file containing the DHE as well as EC params should be enough
>
> Yes I agree. However, I don't remember the previous support looking in the cert file for params; is it possible that it ended up silently using the defaults?
DUNNO - however, the behavior of httpd above 2.4.7/2.4.8 is desireable
especially when wildcard certificates are used on several services (ATS,
httpd, email...)
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile
Re: 5.2.1: DHE ciphers gone?
Posted by James Peach <jp...@apache.org>.
> On Apr 1, 2015, at 9:56 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
>
> Am 01.04.2015 um 15:30 schrieb Leif Hedstrom:
>> It was decided from experiences at LinkedIn that DHE was unstable and/or causing problems in general. It was deemed an incompatible change that should not have happened in the 5.x cycle, so we restored defaults to a state as it was in 5.1. I'll let Thomas and Brian give more details on the issues with DHE.
>>
>> You can still use DHE but you would have to move the params into a file and explicitly tell ATS to use those params.
>
> but in which file and how to configure - the docs don't mention it?
>
> IMHO the certs file containing the DHE as well as EC params should be enough
Yes I agree. However, I don't remember the previous support looking in the cert file for params; is it possible that it ended up silently using the defaults?
J
Re: 5.2.1: DHE ciphers gone?
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 5, 2015, at 11:37 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 05.04.2015 um 18:39 schrieb Leif Hedstrom:
>>> thanks, that does the trick and MSIE11 is using AES-GCM now
>>> that information *really* belongs to the TLS manpages not just records.config
>>>
>>> IE 11 / Win 7 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS
>>> IE 11 / Win 8.1 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS
>>
>> Reindl,
>>
>> I think you know more about this than most of us, if you have the cycles to update the docs, that’d be great :) I’ll commit any github pull requests for the docs that you can muster up.
>>
>> Cheers,
>>
>> — Leif
>
> thanks for your feedback (docs.trafficserver.apache.org seems to be down BTW) - while i am not that good in using git/github it would be great to make a refercence to "proxy.config.ssl.server.dhparams_file" on the "ssl_multicert.config" page to make clear the needed step as well as how to create the file
Yeah, I’ve been fiddling / testing HTTP/2 patches on it :). If you are not comfortable with github, any sort of diff on the docs file will suffice. Heck, even just attaching an updated file to a Jira will suffice, although diffs are preferred.
— Leif
Re: 5.2.1: DHE ciphers gone?
Posted by Reindl Harald <h....@thelounge.net>.
Am 05.04.2015 um 18:39 schrieb Leif Hedstrom:
>> thanks, that does the trick and MSIE11 is using AES-GCM now
>> that information *really* belongs to the TLS manpages not just records.config
>>
>> IE 11 / Win 7 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS
>> IE 11 / Win 8.1 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS
>
> Reindl,
>
> I think you know more about this than most of us, if you have the cycles to update the docs, that’d be great :) I’ll commit any github pull requests for the docs that you can muster up.
>
> Cheers,
>
> — Leif
thanks for your feedback (docs.trafficserver.apache.org seems to be down
BTW) - while i am not that good in using git/github it would be great to
make a refercence to "proxy.config.ssl.server.dhparams_file" on the
"ssl_multicert.config" page to make clear the needed step as well as how
to create the file
the intention of the 2048 prime while using a RSA4096 certificate is to
avoid troubles with older browsers like Firefox on some Linux
distributions before allow use of ECDHE (Redhat/Fedora not so long ago)
and works with FF 2.0 recently tested again
newer browsers would use anyways ECDHE with the config below
https://www.ssllabs.com/ssltest/ is currently the best known tool for
testing (hopefully the screenshot makes it through the list) while
"Session resumption (tickets) Yes" makes me still wondering given
"ssl_ticket_enabled=0" is in use
______________________________________________________________
openssl gendh -out /etc/trafficserver/ssl/dhparams.pem -2 2048
chmod 0644 /etc/trafficserver/ssl/dhparams.pem
CONFIG proxy.config.ssl.server.dhparams_file STRING
/etc/trafficserver/ssl/dhparams.pem
______________________________________________________________
additionally there should be a serverside cipher-ordering preferring
ECDHE AES-GCM followed by DHE AES-GCM, AES128 preferred according to
https://www.schneier.com/blog/archives/2009/07/another_new_aes.html
the cipher suites are more or less current mozilla recommendations while
i played around over weeks with tuning them and test aginst ssl-labs
coming to the same conclusion (ignoring ECDSA for now) with the goal to
support as much as possible clients with their best supported ciphers
preferred
CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
CONFIG proxy.config.ssl.server.cipher_suite STRING
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!LOW:!MEDIUM
______________________________________________________________
that would be the httpd config for the same results while the dhparams
in that case can be just included in the "SSLCertificateFile"
SSLProtocol All -SSLv2 -SSLv3
SSLFIPS Off
SSLCompression Off
SSLInsecureRenegotiation Off
SSLSessionTickets Off
SSLVerifyClient none
SSLHonorCipherOrder On
SSLCipherSuite
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!LOW:!MEDIUM
Re: 5.2.1: DHE ciphers gone?
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 5, 2015, at 9:10 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
>
> Am 01.04.2015 um 20:11 schrieb Susan Hinrichs:
>> On 4/1/2015 11:56 AM, Reindl Harald wrote:
>>>
>>>
>>> Am 01.04.2015 um 15:30 schrieb Leif Hedstrom:
>>>> It was decided from experiences at LinkedIn that DHE was unstable
>>>> and/or causing problems in general. It was deemed an incompatible
>>>> change that should not have happened in the 5.x cycle, so we restored
>>>> defaults to a state as it was in 5.1. I'll let Thomas and Brian give
>>>> more details on the issues with DHE.
>>>>
>>>> You can still use DHE but you would have to move the params into a
>>>> file and explicitly tell ATS to use those params.
>>>
>>> but in which file and how to configure - the docs don't mention it?
>>>
>>> IMHO the certs file containing the DHE as well as EC params should be
>>> enough
>>
>> You can define a dhparams file in records.config
>>
>> proxy.config.ssl.server.dhparams_file
>>
>> The 5.2.0 version would use a 2048 bit prime group defined in RFC 5114
>> if no dhparams file is defined.
>>
>> For 5.2.1, it was changed so no default prime group is used. You must
>> specify your prime group in a file
>
> thanks, that does the trick and MSIE11 is using AES-GCM now
> that information *really* belongs to the TLS manpages not just recods.config
>
>
> IE 11 / Win 7 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS
>
> IE 11 / Win 8.1 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS
Reindl,
I think you know more about this than most of us, if you have the cycles to update the docs, that’d be great :) I’ll commit any github pull requests for the docs that you can muster up.
Cheers,
— Leif
Re: 5.2.1: DHE ciphers gone?
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.04.2015 um 20:11 schrieb Susan Hinrichs:
> On 4/1/2015 11:56 AM, Reindl Harald wrote:
>>
>>
>> Am 01.04.2015 um 15:30 schrieb Leif Hedstrom:
>>> It was decided from experiences at LinkedIn that DHE was unstable
>>> and/or causing problems in general. It was deemed an incompatible
>>> change that should not have happened in the 5.x cycle, so we restored
>>> defaults to a state as it was in 5.1. I'll let Thomas and Brian give
>>> more details on the issues with DHE.
>>>
>>> You can still use DHE but you would have to move the params into a
>>> file and explicitly tell ATS to use those params.
>>
>> but in which file and how to configure - the docs don't mention it?
>>
>> IMHO the certs file containing the DHE as well as EC params should be
>> enough
>
> You can define a dhparams file in records.config
>
> proxy.config.ssl.server.dhparams_file
>
> The 5.2.0 version would use a 2048 bit prime group defined in RFC 5114
> if no dhparams file is defined.
>
> For 5.2.1, it was changed so no default prime group is used. You must
> specify your prime group in a file
thanks, that does the trick and MSIE11 is using AES-GCM now
that information *really* belongs to the TLS manpages not just recods.config
IE 11 / Win 7 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS
IE 11 / Win 8.1 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
FS
Re: 5.2.1: DHE ciphers gone?
Posted by Susan Hinrichs <sh...@network-geographics.com>.
On 4/1/2015 11:56 AM, Reindl Harald wrote:
>
>
> Am 01.04.2015 um 15:30 schrieb Leif Hedstrom:
>> It was decided from experiences at LinkedIn that DHE was unstable
>> and/or causing problems in general. It was deemed an incompatible
>> change that should not have happened in the 5.x cycle, so we restored
>> defaults to a state as it was in 5.1. I'll let Thomas and Brian give
>> more details on the issues with DHE.
>>
>> You can still use DHE but you would have to move the params into a
>> file and explicitly tell ATS to use those params.
>
> but in which file and how to configure - the docs don't mention it?
>
> IMHO the certs file containing the DHE as well as EC params should be
> enough
You can define a dhparams file in records.config
proxy.config.ssl.server.dhparams_file
The 5.2.0 version would use a 2048 bit prime group defined in RFC 5114 if no dhparams file is defined.
For 5.2.1, it was changed so no default prime group is used. You must specify your prime group in a file.
>
>>> On Apr 1, 2015, at 4:04 AM, Reindl Harald <h....@thelounge.net>
>>> wrote:
>>>
>>> Hi
>>>
>>> why are DHE ciphers no longer available after update to 5.2.1?
>>>
>>> the crtificate files are PEM with
>>>
>>> * intermediate CA
>>> * private key
>>> * certificate
>>> * ec params
>>> * dh params
>>>
>>> in a single file which is supported for a long time by httpd and
>>> worked with the previous ATS release too (which introduced DHE at all)
>
>
Re: 5.2.1: DHE ciphers gone?
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.04.2015 um 15:30 schrieb Leif Hedstrom:
> It was decided from experiences at LinkedIn that DHE was unstable and/or causing problems in general. It was deemed an incompatible change that should not have happened in the 5.x cycle, so we restored defaults to a state as it was in 5.1. I'll let Thomas and Brian give more details on the issues with DHE.
>
> You can still use DHE but you would have to move the params into a file and explicitly tell ATS to use those params.
but in which file and how to configure - the docs don't mention it?
IMHO the certs file containing the DHE as well as EC params should be enough
>> On Apr 1, 2015, at 4:04 AM, Reindl Harald <h....@thelounge.net> wrote:
>>
>> Hi
>>
>> why are DHE ciphers no longer available after update to 5.2.1?
>>
>> the crtificate files are PEM with
>>
>> * intermediate CA
>> * private key
>> * certificate
>> * ec params
>> * dh params
>>
>> in a single file which is supported for a long time by httpd and worked with the previous ATS release too (which introduced DHE at all)
Re: 5.2.1: DHE ciphers gone?
Posted by Leif Hedstrom <zw...@apache.org>.
It was decided from experiences at LinkedIn that DHE was unstable and/or causing problems in general. It was deemed an incompatible change that should not have happened in the 5.x cycle, so we restored defaults to a state as it was in 5.1. I'll let Thomas and Brian give more details on the issues with DHE.
You can still use DHE but you would have to move the params into a file and explicitly tell ATS to use those params.
-- Leif
> On Apr 1, 2015, at 4:04 AM, Reindl Harald <h....@thelounge.net> wrote:
>
> Hi
>
> why are DHE ciphers no longer available after update to 5.2.1?
>
> the crtificate files are PEM with
>
> * intermediate CA
> * private key
> * certificate
> * ec params
> * dh params
>
> in a single file which is supported for a long time by httpd and worked with the previous ATS release too (which introduced DHE at all)
>