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 2014/01/30 14:47:10 UTC
Re: ssl termination again (and no support for DHE/ECDHE)
Am 30.01.2014 13:30, schrieb Uri Shachar:
> On Thu, 30 Jan 2014 12:48:33 +0100 Reindl Harald wrote:
>> somehow ATS does not listen on 8443
>> with out the "ssl=" it does but not accept https connections
>>
>> what i don't understand is why i need "server.cert.path" and "server.private_key.path"
>> at all additionally to "ssl_multicert.config" and which cert this should be in
>> production, but that's a leter problem after it accepts ssl-connections at all
>>
>> /etc/trafficserver/records.config:
>> CONFIG proxy.config.http.server_ports STRING 8080,ssl=8443
>
> Your config is wrong - try:
> CONFIG proxy.config.http.server_ports STRING 8080 8443:ssl
>
> Also, proxy.config.ssl.cert.path and proxy.config.ssl.server.private_key.path should be paths, not specific certs:
> # This is the path that SSL certificates files are relative to. Certificate
> # names specified in ssl_multicert.config will be located relative to this path.
> CONFIG proxy.config.ssl.server.cert.path STRING config
> # If any private key is not contained in the certificate file, you must
> # fill in the private key path. Private key names specified in
> # ssl_multicert.config will be located relative to this path.
> CONFIG proxy.config.ssl.server.private_key.path STRING config
indeed - thanks for helping the blind man
"CONFIG proxy.config.http.server_ports STRING 8080 8443:ssl" does the trick
one remaining issue currently is that DHE/ECDHE seems not to be supported
while httpd/openssl with the same environment do
[harry@rh:~]$ sslscan rhsoft.testserver.rhsoft.net:8443 | grep Accepted
Accepted TLSv1 256 bits AES256-SHA
Accepted TLSv1 256 bits CAMELLIA256-SHA
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits AES128-SHA
Accepted TLSv1 128 bits CAMELLIA128-SHA
Accepted TLS11 256 bits AES256-SHA
Accepted TLS11 256 bits CAMELLIA256-SHA
Accepted TLS11 168 bits DES-CBC3-SHA
Accepted TLS11 128 bits AES128-SHA
Accepted TLS11 128 bits CAMELLIA128-SHA
Accepted TLS12 256 bits AES256-GCM-SHA384
Accepted TLS12 256 bits AES256-SHA
Accepted TLS12 256 bits CAMELLIA256-SHA
Accepted TLS12 168 bits DES-CBC3-SHA
Accepted TLS12 128 bits AES128-GCM-SHA256
Accepted TLS12 128 bits AES128-SHA
Accepted TLS12 128 bits CAMELLIA128-SHA
_________________________________________________
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 cipher suite should result in the following server-preferred order
verified with https://www.ssllabs.com/ssltest/index.html and httpd
Cipher Suites (SSL 3+ suites in server-preferred order, then SSL 2 suites where used)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 256 bits (eq. 3072 bits RSA) FS
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 256 bits (eq. 3072 bits RSA) FS
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 3072 bits (p: 512, g: 1, Ys: 512) FS
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 3072 bits (p: 512, g: 1, Ys: 512) FS
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 3072 bits (p: 512, g: 1, Ys: 512) FS
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 3072 bits (p: 512, g: 1, Ys: 512) FS
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 3072 bits (p: 512, g: 1, Ys: 512) FS
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 3072 bits (p: 512, g: 1, Ys: 512) FS
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 3072 bits (p: 512, g: 1, Ys: 512) FS
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 3072 bits (p: 512, g: 1, Ys: 512) FS
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) FS
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by Reindl Harald <h....@thelounge.net>.
thanks, applied to my rpmbuild and verified with ECDHE
calomel ssl validation in Firefox is happy with that
and 88% (until FF27 enables AES-GCM which leads to 100%)
without PFS it classifies the security with a red "weak"
Am 30.01.2014 16:59, schrieb Thomas Berger:
> Here is a working Patch against 4.1.2, should also work on 4.1.3.
>
> Backportet from the 4.2.0 tree.
>
> Am Donnerstag, 30. Januar 2014, 15:38:07 schrieb Reindl Harald:
>> Am 30.01.2014 15:19, schrieb Uri Shachar:
>>> On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
>>> snip...
>>>
>>>> one remaining issue currently is that DHE/ECDHE seems not to be supported
>>>> while httpd/openssl with the same environment do
>>>
>>> snip...
>>>
>>> Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
>>
>> cool - thanks!
>>
>> hopefully the same way as httpd starting with 2.4.7
>> http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile
>>
>>> DH parameter interoperability with primes > 1024 bit
>>> Beginning with version 2.4.7, mod_ssl makes use of standardized DH
>>> parameters with prime lengths of 2048, 3072 and 4096 bits (from RFC
>>> 3526), and hands them out to clients based on the length of the
>>> certificate's RSA/DSA key. With Java-based clients in particular (Java 7
>>> or earlier), this may lead to handshake failures - see this FAQ answer
>>> for working around such issues.
>>
>> means that if you have a RSA3072 DH-params are 3072, the same for 4096 etc.
>> and if someone want to control that he can add params to the used PEM file
>> and it could look like below containg all TSL relevant params/keys/certs
>>
>> [root@testserver:~]$ cat conf/ssl/testserver.rhsoft.net.pem
>> -----BEGIN CERTIFICATE-----
>> *snip*
>> -----END CERTIFICATE-----
>> -----BEGIN PRIVATE KEY-----
>> *snip*
>> -----END PRIVATE KEY-----
>> -----BEGIN DH PARAMETERS-----
>> MIIBiAKCAYEAsprp4BdLI4Vo8JcsJbu6/UJK+udAl3C1sHrBahXXdVxt6ArjbktI
>> up5BfGoiBfj28K0DiGSdXvnpDemaiJd29X+M7+XvJN6px0EP54aU+2Y+LeceI5WK
>> FBokp1wQFVG0f6ccNlXvoLec1iQLog+ygDT5m25yGKjfHTpRgJovoi5Jwoqtl0H+
>> XQ32oHh3/8IA1CjoWDkuHJGEWX6z26W9dTn9U4t9e0dIL+ulX6cQfkkJDSzwBgEs
>> y9jimihp73zu7hAIu/zNBMFWYswbZ4Z5SA1wENNRsO3nmBCekCjfKp0MuEJGQ/xx
>> U2Hrcd6UAPwTEjuWmBOi/DlAPQyLbTVDinBDfoZHsrl1Je1Hxwix4nsLsml0NoDw
>> i0jzihtOCoKiTuP7BWemZy2eKOqcRnu764bcFp8/l3klKWpuOH6Vd/7rfoe/FzQR
>> 8M8b5lTGTktjVPhZaRLe9lrHkVCa7MnPdHBK/JHvGBHsvGFQur4oQm5culCeQAxq
>> 0C/m6ck3xYTLAgEC
>> -----END DH PARAMETERS-----
>> -----BEGIN EC PARAMETERS-----
>> BgUrgQQAIg==
>> -----END EC PARAMETERS-----
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.01.2014 17:54, schrieb Igor Galić:
> ----- Original Message -----
>> Here is a working Patch against 4.1.2, should also work on 4.1.3.
>>
>> Backportet from the 4.2.0 tree.
>>
>
> Is there general interest to include this in 4.1.3?
> Please note that 4.1.3 and 4.2.0 will be released at the same time
good question
depends on the amount of incomaptible changes in 4.2.0 if at all
and maybe how distributions handle a 4.x change different than
a 4.1.x
without forward secrecy you get a serious problem if it comes
to SSL and external security audits these days or at least
it's likely that it goes fast in that direction
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> Here is a working Patch against 4.1.2, should also work on 4.1.3.
>
> Backportet from the 4.2.0 tree.
>
Is there general interest to include this in 4.1.3?
Please note that 4.1.3 and 4.2.0 will be released at the same time.
-- 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: ssl termination again (and no support for DHE/ECDHE)
Posted by Thomas Berger <th...@it.piratenpartei.de>.
Here is a working Patch against 4.1.2, should also work on 4.1.3.
Backportet from the 4.2.0 tree.
Am Donnerstag, 30. Januar 2014, 15:38:07 schrieb Reindl Harald:
> Am 30.01.2014 15:19, schrieb Uri Shachar:
> > On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
> > snip...
> >
> >> one remaining issue currently is that DHE/ECDHE seems not to be supported
> >> while httpd/openssl with the same environment do
> >
> > snip...
> >
> > Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
>
> cool - thanks!
>
> hopefully the same way as httpd starting with 2.4.7
> http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile
>
> > DH parameter interoperability with primes > 1024 bit
> > Beginning with version 2.4.7, mod_ssl makes use of standardized DH
> > parameters with prime lengths of 2048, 3072 and 4096 bits (from RFC
> > 3526), and hands them out to clients based on the length of the
> > certificate's RSA/DSA key. With Java-based clients in particular (Java 7
> > or earlier), this may lead to handshake failures - see this FAQ answer
> > for working around such issues.
>
> means that if you have a RSA3072 DH-params are 3072, the same for 4096 etc.
> and if someone want to control that he can add params to the used PEM file
> and it could look like below containg all TSL relevant params/keys/certs
>
> [root@testserver:~]$ cat conf/ssl/testserver.rhsoft.net.pem
> -----BEGIN CERTIFICATE-----
> *snip*
> -----END CERTIFICATE-----
> -----BEGIN PRIVATE KEY-----
> *snip*
> -----END PRIVATE KEY-----
> -----BEGIN DH PARAMETERS-----
> MIIBiAKCAYEAsprp4BdLI4Vo8JcsJbu6/UJK+udAl3C1sHrBahXXdVxt6ArjbktI
> up5BfGoiBfj28K0DiGSdXvnpDemaiJd29X+M7+XvJN6px0EP54aU+2Y+LeceI5WK
> FBokp1wQFVG0f6ccNlXvoLec1iQLog+ygDT5m25yGKjfHTpRgJovoi5Jwoqtl0H+
> XQ32oHh3/8IA1CjoWDkuHJGEWX6z26W9dTn9U4t9e0dIL+ulX6cQfkkJDSzwBgEs
> y9jimihp73zu7hAIu/zNBMFWYswbZ4Z5SA1wENNRsO3nmBCekCjfKp0MuEJGQ/xx
> U2Hrcd6UAPwTEjuWmBOi/DlAPQyLbTVDinBDfoZHsrl1Je1Hxwix4nsLsml0NoDw
> i0jzihtOCoKiTuP7BWemZy2eKOqcRnu764bcFp8/l3klKWpuOH6Vd/7rfoe/FzQR
> 8M8b5lTGTktjVPhZaRLe9lrHkVCa7MnPdHBK/JHvGBHsvGFQur4oQm5culCeQAxq
> 0C/m6ck3xYTLAgEC
> -----END DH PARAMETERS-----
> -----BEGIN EC PARAMETERS-----
> BgUrgQQAIg==
> -----END EC PARAMETERS-----
--
Mit freundlichen Grüßen,
Thomas Berger
Piraten IT
--
Piratenpartei Deutschland - Pirate Party of Germany
Pflugstraße 9a, D-10115 Berlin, Germany
Vorstand: Thorsten Wirth, Carolin Mahn-Gauseweg,
Stefan Bartels, Stephanie Schmiedke, Veronique Schmitz,
Gefion Thürmer, Björn Niklas Semrau
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by Reindl Harald <h....@thelounge.net>.
Am 31.01.2014 17:24, schrieb Reindl Harald:
>>> order of cipher-suite above ignored - actually bad
>> CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
>>
>> Also see https://issues.apache.org/jira/browse/TS-2370, which fixes the setting logic in 4.2.
>
> cool, i give that a try and happily look forward to 4.2
> my configs are that simple and without plugins that i can upgrade without issues
unverified - there was a hard restart between change and test
*maybe* caused by the patch from yesterday, see message at bottom
but even if, the patch makes things better because ome browsers
using ECDHE with it (MSIE does not and rely on server-preferred)
BTW: maybe someone is interested in my httpd-bugreport in context
of httpd / TLS / mod_rewrite / mod_remoteip (part of my get a big
picture about capabilities in complexer setups)
https://issues.apache.org/bugzilla/show_bug.cgi?id=56094
_________________________________________________________
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-SHA256CONFIG
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
CONFIG proxy.config.ssl.server.honor_cipher_order INT
1: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
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) FS 112
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 256 bits (eq. 3072 bits RSA) FS 256
_________________________________________________________
-------- Original-Nachricht --------
Betreff: Re: ssl termination again (and no support for DHE/ECDHE)
Datum: Thu, 30 Jan 2014 16:59:34 +0100
Von: Thomas Berger <th...@it.piratenpartei.de>
Antwort an: users@trafficserver.apache.org
Organisation: Piratenpartei IT
An: users@trafficserver.apache.org
Here is a working Patch against 4.1.2, should also work on 4.1.3.
Backportet from the 4.2.0 tree.
Am Donnerstag, 30. Januar 2014, 15:38:07 schrieb Reindl Harald:
> Am 30.01.2014 15:19, schrieb Uri Shachar:
> > On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
> > snip...
> >
> >> one remaining issue currently is that DHE/ECDHE seems not to be supported
> >> while httpd/openssl with the same environment do
> >
> > snip...
> >
> > Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
>
> cool - thanks!
>
> hopefully the same way as httpd starting with 2.4.7
> http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile
>
> > DH parameter interoperability with primes > 1024 bit
> > Beginning with version 2.4.7, mod_ssl makes use of standardized DH
> > parameters with prime lengths of 2048, 3072 and 4096 bits (from RFC
> > 3526), and hands them out to clients based on the length of the
> > certificate's RSA/DSA key. With Java-based clients in particular (Java 7
> > or earlier), this may lead to handshake failures - see this FAQ answer
> > for working around such issues.
>
> means that if you have a RSA3072 DH-params are 3072, the same for 4096 etc.
> and if someone want to control that he can add params to the used PEM file
> and it could look like below containg all TSL relevant params/keys/certs
--
Mit freundlichen Grüßen,
Thomas Berger
Piraten IT
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by Reindl Harald <h....@thelounge.net>.
Am 31.01.2014 17:14, schrieb James Peach:
> On Jan 31, 2014, at 7:00 AM, Reindl Harald <h....@thelounge.net> wrote:
>> https://www.ssllabs.com/ssltest/
>> ___________________________________________________
>>
>> Secure Client-Initiated Renegotiation Supported DoS DANGER
>> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
>
> This is fixed in 4.2. https://issues.apache.org/jira/browse/TS-1467
cool, thanks
>> OCSP stapling No
>
> This needs a contributor. https://issues.apache.org/jira/browse/TS-2367
ok, not that important, i am only about verify ATS / httpd and for now
there are no websites which needs ATS for load-reduction and TLS
what i currently try to achive is find out capabilities of our infrastrcuture
looking at the big picture to know what is possible before things are asked
to implement or hardly needed for a project in the future
>> The server does not support Forward Secrecy with the reference browsers
>
> Not sure what this one means. Do you need to use and EC key to get ECDHE?
no, but not all clients support ECDHE, short ago Firefox on Fedora as example
OpenSSL 0.9.8y TLS 1.0 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) FS
BingPreview Dec 2013 TLS 1.0 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) FS
Java 6u45 No SNI 2 Client does not support DH parameters > 1024 bits
Java 6 would chose DHE if the DHE params are not bigger than 1024 Bit
the warning appears if there are clients known to support PFS with DHE but not ECDHE
OpenSSl 0.9.8 is in that context interesting because it's widely used in LTS distributions
>> order of cipher-suite above ignored - actually bad
> CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
>
> Also see https://issues.apache.org/jira/browse/TS-2370, which fixes the setting logic in 4.2.
cool, i give that a try and happily look forward to 4.2
my configs are that simple and without plugins that i can upgrade without issues
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by James Peach <jp...@apache.org>.
On Jan 31, 2014, at 7:00 AM, Reindl Harald <h....@thelounge.net> wrote:
>
> Am 30.01.2014 17:32, schrieb James Peach:
>> On Jan 30, 2014, at 8:29 AM, Reindl Harald <h....@thelounge.net> wrote:
>>>
>>> Am 30.01.2014 17:05, schrieb James Peach:
>>>> On Jan 30, 2014, at 6:38 AM, Reindl Harald <h....@thelounge.net> wrote:
>>>>
>>>>> Am 30.01.2014 15:19, schrieb Uri Shachar:
>>>>>> On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
>>>>>>> one remaining issue currently is that DHE/ECDHE seems not to be supported
>>>>>>> while httpd/openssl with the same environment do
>>>>>>
>>>>>> Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
>>>>>
>>>>> cool - thanks!
>>>>
>>>> Note that 4.3 only support ECDHE, TS-2417 is still open for other key types
>>>
>>> thanks for the information, good to know
>>>
>>> however, i am not sure if it should not simply pass
>>> "proxy.config.ssl.server.cipher_suite" to the underlying
>>> openssl layer and let it do the whole work
>>
>> It does, but that's not all that is needed for DHE to work
>
> OK, good to know
>
> i now have configured one website with optional TLS and checked state of play
> trafficserver-4.1.2 with the ECDHE patch from yesterday
>
> https://www.ssllabs.com/ssltest/
> ___________________________________________________
>
> Secure Client-Initiated Renegotiation Supported DoS DANGER
> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
This is fixed in 4.2. https://issues.apache.org/jira/browse/TS-1467
>
> OCSP stapling No
This needs a contributor. https://issues.apache.org/jira/browse/TS-2367
>
> The server does not support Forward Secrecy with the reference browsers
Not sure what this one means. Do you need to use and EC key to get ECDHE?
> ___________________________________________________
>
> 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
> ___________________________________________________
>
> order of cipher-suite above ignored - actually bad
CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
Also see https://issues.apache.org/jira/browse/TS-2370, which fixes the setting logic in 4.2.
> Cipher Suites (sorted by strength; the server has no preference)
> TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
> TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
> TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 256 bits (eq. 3072 bits RSA) FS 128
> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) FS 112
> TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
> TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
> TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 256 bits (eq. 3072 bits RSA) FS 256
> ___________________________________________________
>
> all in all that looks not too bad with the ECDHE patch, but the issues above should be reviewed
> is there a preferred bugreport where i should add the content of this message?
>
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.01.2014 17:32, schrieb James Peach:
> On Jan 30, 2014, at 8:29 AM, Reindl Harald <h....@thelounge.net> wrote:
>>
>> Am 30.01.2014 17:05, schrieb James Peach:
>>> On Jan 30, 2014, at 6:38 AM, Reindl Harald <h....@thelounge.net> wrote:
>>>
>>>> Am 30.01.2014 15:19, schrieb Uri Shachar:
>>>>> On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
>>>>>> one remaining issue currently is that DHE/ECDHE seems not to be supported
>>>>>> while httpd/openssl with the same environment do
>>>>>
>>>>> Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
>>>>
>>>> cool - thanks!
>>>
>>> Note that 4.3 only support ECDHE, TS-2417 is still open for other key types
>>
>> thanks for the information, good to know
>>
>> however, i am not sure if it should not simply pass
>> "proxy.config.ssl.server.cipher_suite" to the underlying
>> openssl layer and let it do the whole work
>
> It does, but that's not all that is needed for DHE to work
OK, good to know
i now have configured one website with optional TLS and checked state of play
trafficserver-4.1.2 with the ECDHE patch from yesterday
https://www.ssllabs.com/ssltest/
___________________________________________________
Secure Client-Initiated Renegotiation Supported DoS DANGER
https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
OCSP stapling No
The server does not support Forward Secrecy with the reference browsers
___________________________________________________
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
___________________________________________________
order of cipher-suite above ignored - actually bad
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) FS 112
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 256 bits (eq. 3072 bits RSA) FS 256
___________________________________________________
all in all that looks not too bad with the ECDHE patch, but the issues above should be reviewed
is there a preferred bugreport where i should add the content of this message?
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by James Peach <jp...@apache.org>.
On Jan 30, 2014, at 8:29 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 30.01.2014 17:05, schrieb James Peach:
>> On Jan 30, 2014, at 6:38 AM, Reindl Harald <h....@thelounge.net> wrote:
>>
>>> Am 30.01.2014 15:19, schrieb Uri Shachar:
>>>> On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
>>>> snip...
>>>>> one remaining issue currently is that DHE/ECDHE seems not to be supported
>>>>> while httpd/openssl with the same environment do
>>>> snip...
>>>>
>>>> Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
>>>
>>> cool - thanks!
>>
>> Note that 4.3 only support ECDHE, TS-2417 is still open for other key types
>
> thanks for the information, good to know
>
> however, i am not sure if it should not simply pass
> "proxy.config.ssl.server.cipher_suite" to the underlying
> openssl layer and let it do the whole work
It does, but that's not all that is needed for DHE to work.
J
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.01.2014 17:05, schrieb James Peach:
> On Jan 30, 2014, at 6:38 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>> Am 30.01.2014 15:19, schrieb Uri Shachar:
>>> On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
>>> snip...
>>>> one remaining issue currently is that DHE/ECDHE seems not to be supported
>>>> while httpd/openssl with the same environment do
>>> snip...
>>>
>>> Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
>>
>> cool - thanks!
>
> Note that 4.3 only support ECDHE, TS-2417 is still open for other key types
thanks for the information, good to know
however, i am not sure if it should not simply pass
"proxy.config.ssl.server.cipher_suite" to the underlying
openssl layer and let it do the whole work
maybe a naive viewpoint from outside
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by James Peach <jp...@apache.org>.
On Jan 30, 2014, at 6:38 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 30.01.2014 15:19, schrieb Uri Shachar:
>> On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
>> snip...
>>> one remaining issue currently is that DHE/ECDHE seems not to be supported
>>> while httpd/openssl with the same environment do
>> snip...
>>
>> Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
>
> cool - thanks!
Note that 4.3 only support ECDHE, TS-2417 is still open for other key types.
J
Re: ssl termination again (and no support for DHE/ECDHE)
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.01.2014 15:19, schrieb Uri Shachar:
> On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
> snip...
>> one remaining issue currently is that DHE/ECDHE seems not to be supported
>> while httpd/openssl with the same environment do
> snip...
>
> Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
cool - thanks!
hopefully the same way as httpd starting with 2.4.7
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile
> DH parameter interoperability with primes > 1024 bit
> Beginning with version 2.4.7, mod_ssl makes use of standardized DH parameters
> with prime lengths of 2048, 3072 and 4096 bits (from RFC 3526), and hands them
> out to clients based on the length of the certificate's RSA/DSA key. With Java-based
> clients in particular (Java 7 or earlier), this may lead to handshake failures -
> see this FAQ answer for working around such issues.
means that if you have a RSA3072 DH-params are 3072, the same for 4096 etc.
and if someone want to control that he can add params to the used PEM file
and it could look like below containg all TSL relevant params/keys/certs
[root@testserver:~]$ cat conf/ssl/testserver.rhsoft.net.pem
-----BEGIN CERTIFICATE-----
*snip*
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
*snip*
-----END PRIVATE KEY-----
-----BEGIN DH PARAMETERS-----
MIIBiAKCAYEAsprp4BdLI4Vo8JcsJbu6/UJK+udAl3C1sHrBahXXdVxt6ArjbktI
up5BfGoiBfj28K0DiGSdXvnpDemaiJd29X+M7+XvJN6px0EP54aU+2Y+LeceI5WK
FBokp1wQFVG0f6ccNlXvoLec1iQLog+ygDT5m25yGKjfHTpRgJovoi5Jwoqtl0H+
XQ32oHh3/8IA1CjoWDkuHJGEWX6z26W9dTn9U4t9e0dIL+ulX6cQfkkJDSzwBgEs
y9jimihp73zu7hAIu/zNBMFWYswbZ4Z5SA1wENNRsO3nmBCekCjfKp0MuEJGQ/xx
U2Hrcd6UAPwTEjuWmBOi/DlAPQyLbTVDinBDfoZHsrl1Je1Hxwix4nsLsml0NoDw
i0jzihtOCoKiTuP7BWemZy2eKOqcRnu764bcFp8/l3klKWpuOH6Vd/7rfoe/FzQR
8M8b5lTGTktjVPhZaRLe9lrHkVCa7MnPdHBK/JHvGBHsvGFQur4oQm5culCeQAxq
0C/m6ck3xYTLAgEC
-----END DH PARAMETERS-----
-----BEGIN EC PARAMETERS-----
BgUrgQQAIg==
-----END EC PARAMETERS-----
RE: ssl termination again (and no support for DHE/ECDHE)
Posted by Uri Shachar <us...@hotmail.com>.
On Thu, 30 Jan 2014 14:47:10 +0100 Reindl Harald wrote:
snip...
> one remaining issue currently is that DHE/ECDHE seems not to be supported
> while httpd/openssl with the same environment do
snip...
Added in 4.2.0 - Check out https://issues.apache.org/jira/browse/TS-2372
Cheers,
Uri