You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Phil Sorber <so...@apache.org> on 2016/04/10 14:42:41 UTC
Deprecation of SSL v2/3
I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
remove it in 7.0.0.
Currently our defaults do not enable them and have been that way for about
a year now. For 6.2.0 I'd like to mark them deprecated in the
documentation, and then we remove the code for 7.0.0. This will mean that
as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
library supports it.
Appreciate any feedback.
Thanks.
Re: Deprecation of SSL v2/3
Posted by Igor Galić <i....@brainsware.org>.
+1
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: https://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
On Sun, 10 Apr 2016, at 14:42, Phil Sorber wrote:
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for
> about a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean
> that as of 7.0.0 you will not be able to enable SSLv2/3 even if your
> OpenSSL library supports it.
>
> Appreciate any feedback.
>
> Thanks.
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean that
> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> library supports it.
Makes sense to me, +1.
— Leif
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 25, 2016, at 4:23 PM, Phil Sorber <so...@apache.org> wrote:
>
> On Mon, Apr 25, 2016 at 11:01 AM Reindl Harald <h.reindl@thelounge.net <ma...@thelounge.net>> wrote:
>
>
> Am 25.04.2016 um 17:55 schrieb Phil Sorber:
> > On Mon, Apr 25, 2016 at 3:33 AM Reindl Harald
> > just a notice again before i try to build with other flags
> > _____________________________________________
> >
> > https://www.ssllabs.com/ssltest/ <https://www.ssllabs.com/ssltest/>
> >
> > docs.trafficserver.apache.org <http://docs.trafficserver.apache.org/>
> > SSL 2 handshake compatibility Yes
> >
> > I believe what is going on here is that we use SSLv23_server_method()
> > which will negotiate the highest version of TLS supported by both sides,
> > but does so with the SSLv2Hello handshake. This does not mean we
> > necessarily support SSLv2/3.
> >
> > www.thelounge.net <http://www.thelounge.net/>
> > SSL 2 handshake compatibility No
> >
> >
> > It is my understanding that HTTPD matches the server method to only
> > negotiate the version configured. This means it is using something like
> > TLSv1_2_server_method() which only supports the TLS1.2 handshake. What
> > is your HTTPD config?
>
> as strict as the ATS configuration (see below) and so no reason for the
> current "ab" behavior
>
> you can verify with https://www.ssllabs.com/ssltest/ <https://www.ssllabs.com/ssltest/> the following two
> subdomains:
>
> * secure.thelounge.net <http://secure.thelounge.net/> (httpd)
> * www.thelounge.net <http://www.thelounge.net/> (trafficserver)
> _____________________________________
>
> httpd:
>
> SSLSessionCacheTimeout 900
> SSLStaplingStandardCacheTimeout 86400
> SSLStaplingErrorCacheTimeout 300
> SSLStaplingReturnResponderErrors Off
> SSLStaplingFakeTryLater Off
> 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
> _____________________________________
>
> ap_log_error(APLOG_MARK, APLOG_TRACE3, 0, s,
> "Creating new SSL context (protocols: %s)", cp);
>
> Can you turn on TRACE3 level logging in HTTPD and see if you can find the output of that? Trying to trace through the code path in HTTPD to see what they might be doing different than us.
None of this explains why e.g. docs.trafficserver.apache.org nor www.ogre.com have these issues :-/
Can anyone else confirm this failure behavior?
— Leif
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 26.04.2016 um 00:23 schrieb Phil Sorber:
> On Mon, Apr 25, 2016 at 11:01 AM Reindl Harald <h.reindl@thelounge.net
> as strict as the ATS configuration (see below) and so no reason for the
> current "ab" behavior
>
> you can verify with https://www.ssllabs.com/ssltest/ the following two
> subdomains:
>
> * secure.thelounge.net <http://secure.thelounge.net> (httpd)
> * www.thelounge.net <http://www.thelounge.net> (trafficserver)
> _____________________________________
>
> httpd:
>
> SSLSessionCacheTimeout 900
> SSLStaplingStandardCacheTimeout 86400
> SSLStaplingErrorCacheTimeout 300
> SSLStaplingReturnResponderErrors Off
> SSLStaplingFakeTryLater Off
> 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
> _____________________________________
>
>
> ap_log_error(APLOG_MARK, APLOG_TRACE3, 0, s,
> "Creating new SSL context (protocols: %s)", cp);
>
> Can you turn on TRACE3 level logging in HTTPD and see if you can find
> the output of that? Trying to trace through the code path in HTTPD to
> see what they might be doing different than us
sorry - can you elaborate - i am just a sysadmin / web-developer with
apckaging knowledge - that sort of debugging sounds like above my scope
without exact instructions
Re: Deprecation of SSL v2/3
Posted by Phil Sorber <so...@apache.org>.
On Mon, Apr 25, 2016 at 11:01 AM Reindl Harald <h....@thelounge.net>
wrote:
>
>
> Am 25.04.2016 um 17:55 schrieb Phil Sorber:
> > On Mon, Apr 25, 2016 at 3:33 AM Reindl Harald
> > just a notice again before i try to build with other flags
> > _____________________________________________
> >
> > https://www.ssllabs.com/ssltest/
> >
> > docs.trafficserver.apache.org
> > SSL 2 handshake compatibility Yes
> >
> > I believe what is going on here is that we use SSLv23_server_method()
> > which will negotiate the highest version of TLS supported by both sides,
> > but does so with the SSLv2Hello handshake. This does not mean we
> > necessarily support SSLv2/3.
> >
> > www.thelounge.net
> > SSL 2 handshake compatibility No
> >
> >
> > It is my understanding that HTTPD matches the server method to only
> > negotiate the version configured. This means it is using something like
> > TLSv1_2_server_method() which only supports the TLS1.2 handshake. What
> > is your HTTPD config?
>
> as strict as the ATS configuration (see below) and so no reason for the
> current "ab" behavior
>
> you can verify with https://www.ssllabs.com/ssltest/ the following two
> subdomains:
>
> * secure.thelounge.net (httpd)
> * www.thelounge.net (trafficserver)
> _____________________________________
>
> httpd:
>
> SSLSessionCacheTimeout 900
> SSLStaplingStandardCacheTimeout 86400
> SSLStaplingErrorCacheTimeout 300
> SSLStaplingReturnResponderErrors Off
> SSLStaplingFakeTryLater Off
> 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
> _____________________________________
>
ap_log_error(APLOG_MARK, APLOG_TRACE3, 0, s,
"Creating new SSL context (protocols: %s)", cp);
Can you turn on TRACE3 level logging in HTTPD and see if you can find the
output of that? Trying to trace through the code path in HTTPD to see what
they might be doing different than us.
>
> Trafficserver:
>
> CONFIG proxy.config.ssl.SSLv2 INT 0
> CONFIG proxy.config.ssl.SSLv3 INT 0
> CONFIG proxy.config.ssl.TLSv1 INT 1
> CONFIG proxy.config.ssl.TLSv1_1 INT 1
> CONFIG proxy.config.ssl.TLSv1_2 INT 1
> CONFIG proxy.config.ssl.client.SSLv2 INT 1
> CONFIG proxy.config.ssl.client.SSLv3 INT 1
> CONFIG proxy.config.ssl.client.TLSv1 INT 1
> CONFIG proxy.config.ssl.client.TLSv1_1 INT 1
> CONFIG proxy.config.ssl.client.TLSv1_2 INT 1
> CONFIG proxy.config.ssl.client.certification_level INT 0
> CONFIG proxy.config.ssl.server.multicert.filename STRING
> ssl_multicert.config
> CONFIG proxy.config.ssl.server.cert.path STRING /etc/trafficserver/ssl/
> CONFIG proxy.config.ssl.server.private_key.path STRING
> /etc/trafficserver/ssl/
> CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver/ssl/
> 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
> CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
> CONFIG proxy.config.ssl.server.dhparams_file STRING
> /etc/trafficserver/ssl/dhparams.pem
>
>
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.04.2016 um 17:55 schrieb Phil Sorber:
> On Mon, Apr 25, 2016 at 3:33 AM Reindl Harald
> just a notice again before i try to build with other flags
> _____________________________________________
>
> https://www.ssllabs.com/ssltest/
>
> docs.trafficserver.apache.org
> SSL 2 handshake compatibility Yes
>
> I believe what is going on here is that we use SSLv23_server_method()
> which will negotiate the highest version of TLS supported by both sides,
> but does so with the SSLv2Hello handshake. This does not mean we
> necessarily support SSLv2/3.
>
> www.thelounge.net
> SSL 2 handshake compatibility No
>
>
> It is my understanding that HTTPD matches the server method to only
> negotiate the version configured. This means it is using something like
> TLSv1_2_server_method() which only supports the TLS1.2 handshake. What
> is your HTTPD config?
as strict as the ATS configuration (see below) and so no reason for the
current "ab" behavior
you can verify with https://www.ssllabs.com/ssltest/ the following two
subdomains:
* secure.thelounge.net (httpd)
* www.thelounge.net (trafficserver)
_____________________________________
httpd:
SSLSessionCacheTimeout 900
SSLStaplingStandardCacheTimeout 86400
SSLStaplingErrorCacheTimeout 300
SSLStaplingReturnResponderErrors Off
SSLStaplingFakeTryLater Off
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
_____________________________________
Trafficserver:
CONFIG proxy.config.ssl.SSLv2 INT 0
CONFIG proxy.config.ssl.SSLv3 INT 0
CONFIG proxy.config.ssl.TLSv1 INT 1
CONFIG proxy.config.ssl.TLSv1_1 INT 1
CONFIG proxy.config.ssl.TLSv1_2 INT 1
CONFIG proxy.config.ssl.client.SSLv2 INT 1
CONFIG proxy.config.ssl.client.SSLv3 INT 1
CONFIG proxy.config.ssl.client.TLSv1 INT 1
CONFIG proxy.config.ssl.client.TLSv1_1 INT 1
CONFIG proxy.config.ssl.client.TLSv1_2 INT 1
CONFIG proxy.config.ssl.client.certification_level INT 0
CONFIG proxy.config.ssl.server.multicert.filename STRING
ssl_multicert.config
CONFIG proxy.config.ssl.server.cert.path STRING /etc/trafficserver/ssl/
CONFIG proxy.config.ssl.server.private_key.path STRING
/etc/trafficserver/ssl/
CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver/ssl/
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
CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
CONFIG proxy.config.ssl.server.dhparams_file STRING
/etc/trafficserver/ssl/dhparams.pem
Re: Deprecation of SSL v2/3
Posted by Phil Sorber <so...@apache.org>.
On Mon, Apr 25, 2016 at 3:33 AM Reindl Harald <h....@thelounge.net>
wrote:
>
> Am 17.04.2016 um 01:26 schrieb Leif Hedstrom:
> >> On Apr 16, 2016, at 4:56 PM, Reindl Harald <h.reindl@thelounge.net
> >> <ma...@thelounge.net>> wrote:
> >>
> >> Am 17.04.2016 um 00:52 schrieb Leif Hedstrom:
> >>>> On Apr 16, 2016, at 4:44 PM, Reindl Harald <h.reindl@thelounge.net
> >>>> <ma...@thelounge.net>> wrote:
> >>>>
> >>>> Am 17.04.2016 um 00:38 schrieb Leif Hedstrom:
> >>>>>> so what gives you ab -c 5 -n 100https://www.thelounge.net/on
> >>>>>> <http://www.thelounge.net/on> your client?
> >>>>>
> >>>>> It fails too from that CentOS7 box to your box.
> >>>>>>
> >>>>>> [harry@srv-rhsoft:~]$ ab -c 5 -n
> >>>>>> 100https://docs.trafficserver.apache.org/
> >>>>>> <http://docs.trafficserver.apache.org/>
> >>>>>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
> >>>>>> Copyright 1996 Adam Twiss, Zeus Technology
> >>>>>> Ltd,http://www.zeustech.net/
> >>>>>> Licensed to The Apache Software Foundation,http://www.apache.org/
> >>>>>>
> >>>>>> Benchmarkingdocs.trafficserver.apache.org
> >>>>>> <http://benchmarkingdocs.trafficserver.apache.org>
> >>>>>> <http://docs.trafficserver.apache.org/>(be patient)...^C
> >>>>>>
> >>>>>> Server Software: ATS/6.2.0
> >>>>>> Server Hostname: docs.trafficserver.apache.org
> >>>>>> <http://docs.trafficserver.apache.org/>
> >>>>>> Server Port: 443
> >>>>>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
> >>>>>
> >>>>> So it seems your ab works against this CentOS7 box running ATS
> v6.2.0 ?
> >>>>
> >>>> yes
> >>>>
> >>>>> What version of OpenSSL did you build ATS with? I am running
> >>>>> docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest
> stable
> >>>>> release)
> >>>>
> >>>> seems not matter that much since i have this issue for years now and
> >>>> the httpd servers are built in the same environments with the same
> >>>> libraries and don't have that issue
> >>>
> >>> Wonder if it could be one of those -f compiler flags? I’m attaching
> >>> my config.nice that I run on docs.trafficserver, this compiles with
> >>> ASAN though, so you likely want to remove that at least (if you are
> >>> willing to try).
> >>
> >> i will give it a try ASAP, however the whole web and mail stack is
> >> built with that flags (based on the flags below which are %{optflags}
> >> and only ATS has the specific problem
> >
> > Yeah, it seems odd that it’d break like that because of compiler flags.
> > But I honestly have no other ideas as to why it breaks on your system,
> > and not mine :-/. Can anyone else confirm or deny this breakage on their
> > installs?
>
> just a notice again before i try to build with other flags
> _____________________________________________
>
> https://www.ssllabs.com/ssltest/
>
> docs.trafficserver.apache.org:
> SSL 2 handshake compatibility Yes
>
I believe what is going on here is that we use SSLv23_server_method() which
will negotiate the highest version of TLS supported by both sides, but does
so with the SSLv2Hello handshake. This does not mean we necessarily support
SSLv2/3.
>
> www.thelounge.net:
> SSL 2 handshake compatibility No
>
It is my understanding that HTTPD matches the server method to only
negotiate the version configured. This means it is using something like
TLSv1_2_server_method() which only supports the TLS1.2 handshake. What is
your HTTPD config?
> _____________________________________________
>
> CONFIG proxy.config.ssl.SSLv2 INT 0
> CONFIG proxy.config.ssl.SSLv3 INT 0
> CONFIG proxy.config.ssl.TLSv1 INT 1
> CONFIG proxy.config.ssl.TLSv1_1 INT 1
> CONFIG proxy.config.ssl.TLSv1_2 INT 1
> CONFIG proxy.config.ssl.client.certification_level INT 0
> CONFIG proxy.config.ssl.server.multicert.filename STRING
> ssl_multicert.config
> CONFIG proxy.config.ssl.server.cert.path STRING /etc/trafficserver/ssl/
> CONFIG proxy.config.ssl.server.private_key.path STRING
> /etc/trafficserver/ssl/
> CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver/ssl/
> 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:ECD$
> CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
> CONFIG proxy.config.ssl.server.dhparams_file STRING
> /etc/trafficserver/ssl/dhparams.pem
>
>
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
Huh. That doesn't seem right, I'll take a look in a bit. Thanks!
-- Leif
> On Apr 25, 2016, at 3:33 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 17.04.2016 um 01:26 schrieb Leif Hedstrom:
>>> On Apr 16, 2016, at 4:56 PM, Reindl Harald <h.reindl@thelounge.net
>>> <ma...@thelounge.net>> wrote:
>>>
>>> Am 17.04.2016 um 00:52 schrieb Leif Hedstrom:
>>>>> On Apr 16, 2016, at 4:44 PM, Reindl Harald <h.reindl@thelounge.net
>>>>> <ma...@thelounge.net>> wrote:
>>>>>
>>>>> Am 17.04.2016 um 00:38 schrieb Leif Hedstrom:
>>>>>>> so what gives you ab -c 5 -n 100https://www.thelounge.net/on
>>>>>>> <http://www.thelounge.net/on> your client?
>>>>>>
>>>>>> It fails too from that CentOS7 box to your box.
>>>>>>>
>>>>>>> [harry@srv-rhsoft:~]$ ab -c 5 -n
>>>>>>> 100https://docs.trafficserver.apache.org/
>>>>>>> <http://docs.trafficserver.apache.org/>
>>>>>>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
>>>>>>> Copyright 1996 Adam Twiss, Zeus Technology
>>>>>>> Ltd,http://www.zeustech.net/
>>>>>>> Licensed to The Apache Software Foundation,http://www.apache.org/
>>>>>>>
>>>>>>> Benchmarkingdocs.trafficserver.apache.org
>>>>>>> <http://benchmarkingdocs.trafficserver.apache.org>
>>>>>>> <http://docs.trafficserver.apache.org/>(be patient)...^C
>>>>>>>
>>>>>>> Server Software: ATS/6.2.0
>>>>>>> Server Hostname: docs.trafficserver.apache.org
>>>>>>> <http://docs.trafficserver.apache.org/>
>>>>>>> Server Port: 443
>>>>>>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>>>>>>
>>>>>> So it seems your ab works against this CentOS7 box running ATS v6.2.0 ?
>>>>>
>>>>> yes
>>>>>
>>>>>> What version of OpenSSL did you build ATS with? I am running
>>>>>> docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest stable
>>>>>> release)
>>>>>
>>>>> seems not matter that much since i have this issue for years now and
>>>>> the httpd servers are built in the same environments with the same
>>>>> libraries and don't have that issue
>>>>
>>>> Wonder if it could be one of those -f compiler flags? I’m attaching
>>>> my config.nice that I run on docs.trafficserver, this compiles with
>>>> ASAN though, so you likely want to remove that at least (if you are
>>>> willing to try).
>>>
>>> i will give it a try ASAP, however the whole web and mail stack is
>>> built with that flags (based on the flags below which are %{optflags}
>>> and only ATS has the specific problem
>>
>> Yeah, it seems odd that it’d break like that because of compiler flags.
>> But I honestly have no other ideas as to why it breaks on your system,
>> and not mine :-/. Can anyone else confirm or deny this breakage on their
>> installs?
>
> just a notice again before i try to build with other flags
> _____________________________________________
>
> https://www.ssllabs.com/ssltest/
>
> docs.trafficserver.apache.org:
> SSL 2 handshake compatibility Yes
>
> www.thelounge.net:
> SSL 2 handshake compatibility No
> _____________________________________________
>
> CONFIG proxy.config.ssl.SSLv2 INT 0
> CONFIG proxy.config.ssl.SSLv3 INT 0
> CONFIG proxy.config.ssl.TLSv1 INT 1
> CONFIG proxy.config.ssl.TLSv1_1 INT 1
> CONFIG proxy.config.ssl.TLSv1_2 INT 1
> CONFIG proxy.config.ssl.client.certification_level INT 0
> CONFIG proxy.config.ssl.server.multicert.filename STRING ssl_multicert.config
> CONFIG proxy.config.ssl.server.cert.path STRING /etc/trafficserver/ssl/
> CONFIG proxy.config.ssl.server.private_key.path STRING /etc/trafficserver/ssl/
> CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver/ssl/
> 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:ECD$
> CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
> CONFIG proxy.config.ssl.server.dhparams_file STRING /etc/trafficserver/ssl/dhparams.pem
>
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.04.2016 um 16:10 schrieb Phil Sorber:
> On Mon, Apr 25, 2016, 08:05 Reindl Harald <h.reindl@thelounge.net
> <ma...@thelounge.net>> wrote:
>
> Am 25.04.2016 um 15:54 schrieb Leif Hedstrom:
> >> On Apr 25, 2016, at 4:47 AM, Reindl Harald
> <h.reindl@thelounge.net <ma...@thelounge.net>> wrote:
> >>>>> i will give it a try ASAP, however the whole web and mail stack is
> >>>>> built with that flags (based on the flags below which are
> %{optflags}
> >>>>> and only ATS has the specific problem
> >>>>
> >>>> Yeah, it seems odd that it’d break like that because of
> compiler flags.
> >>>> But I honestly have no other ideas as to why it breaks on your
> system,
> >>>> and not mine :-/. Can anyone else confirm or deny this breakage
> on their
> >>>> installs?
> >>>
> >>> just a notice again before i try to build with other flags
> >>> _____________________________________________
> >>>
> >>> https://www.ssllabs.com/ssltest/
> >>>
> >>> docs.trafficserver.apache.org
> <http://docs.trafficserver.apache.org>:
> >>> SSL 2 handshake compatibility Yes
> >>>
> >>> www.thelounge.net <http://www.thelounge.net>:
> >>> SSL 2 handshake compatibility No
> >
> > Double checked the docs.trafficserver configs:
> >
> > [root@docs ~]# traffic_ctl config match proxy.config.ssl.SSLv
> > proxy.config.ssl.SSLv2: 0
> > proxy.config.ssl.SSLv3: 0
> >
> > I have no idea what this means, is there something in here that
> makes it properly detect that we handle V2, but do not negotiate it?
>
> i have both at the same value
>
> since i am not the TLS internals guru i can't say what goes wrong and
> where, my httpd servers have "SSL 2 handshake compatibility Yes" and my
> ATS servers never had
>
> but that pretty sure explains "140575331768288:error:14077410:SSL
> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
> failure:s23_clnt.c:769" which don't happen to my other servers
>
> given that this is for years now, don't happen on identical virtual
> machine clones running httpd instead ATS for me ATS is guilty and not
> any other piece in the stack
>
> not sure what "s23_clnt.c:769" means since there is no "s23_clnt.c" in
> the httpd source tarball from which "ab" at the end is built
>
> I believe that is in OpenSSL
ok, but still don't explain why the same OpenSSL binary in the lcient as
well in the server don't suffer from this issue without ATS
Re: Deprecation of SSL v2/3
Posted by Phil Sorber <so...@apache.org>.
On Mon, Apr 25, 2016, 08:05 Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 25.04.2016 um 15:54 schrieb Leif Hedstrom:
> >> On Apr 25, 2016, at 4:47 AM, Reindl Harald <h....@thelounge.net>
> wrote:
> >>>>> i will give it a try ASAP, however the whole web and mail stack is
> >>>>> built with that flags (based on the flags below which are %{optflags}
> >>>>> and only ATS has the specific problem
> >>>>
> >>>> Yeah, it seems odd that it’d break like that because of compiler
> flags.
> >>>> But I honestly have no other ideas as to why it breaks on your system,
> >>>> and not mine :-/. Can anyone else confirm or deny this breakage on
> their
> >>>> installs?
> >>>
> >>> just a notice again before i try to build with other flags
> >>> _____________________________________________
> >>>
> >>> https://www.ssllabs.com/ssltest/
> >>>
> >>> docs.trafficserver.apache.org:
> >>> SSL 2 handshake compatibility Yes
> >>>
> >>> www.thelounge.net:
> >>> SSL 2 handshake compatibility No
> >
> > Double checked the docs.trafficserver configs:
> >
> > [root@docs ~]# traffic_ctl config match proxy.config.ssl.SSLv
> > proxy.config.ssl.SSLv2: 0
> > proxy.config.ssl.SSLv3: 0
> >
> > I have no idea what this means, is there something in here that makes it
> properly detect that we handle V2, but do not negotiate it?
>
> i have both at the same value
>
> since i am not the TLS internals guru i can't say what goes wrong and
> where, my httpd servers have "SSL 2 handshake compatibility Yes" and my
> ATS servers never had
>
> but that pretty sure explains "140575331768288:error:14077410:SSL
> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
> failure:s23_clnt.c:769" which don't happen to my other servers
>
> given that this is for years now, don't happen on identical virtual
> machine clones running httpd instead ATS for me ATS is guilty and not
> any other piece in the stack
>
> not sure what "s23_clnt.c:769" means since there is no "s23_clnt.c" in
> the httpd source tarball from which "ab" at the end is built
I believe that is in OpenSSL
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.04.2016 um 15:54 schrieb Leif Hedstrom:
>> On Apr 25, 2016, at 4:47 AM, Reindl Harald <h....@thelounge.net> wrote:
>>>>> i will give it a try ASAP, however the whole web and mail stack is
>>>>> built with that flags (based on the flags below which are %{optflags}
>>>>> and only ATS has the specific problem
>>>>
>>>> Yeah, it seems odd that it’d break like that because of compiler flags.
>>>> But I honestly have no other ideas as to why it breaks on your system,
>>>> and not mine :-/. Can anyone else confirm or deny this breakage on their
>>>> installs?
>>>
>>> just a notice again before i try to build with other flags
>>> _____________________________________________
>>>
>>> https://www.ssllabs.com/ssltest/
>>>
>>> docs.trafficserver.apache.org:
>>> SSL 2 handshake compatibility Yes
>>>
>>> www.thelounge.net:
>>> SSL 2 handshake compatibility No
>
> Double checked the docs.trafficserver configs:
>
> [root@docs ~]# traffic_ctl config match proxy.config.ssl.SSLv
> proxy.config.ssl.SSLv2: 0
> proxy.config.ssl.SSLv3: 0
>
> I have no idea what this means, is there something in here that makes it properly detect that we handle V2, but do not negotiate it?
i have both at the same value
since i am not the TLS internals guru i can't say what goes wrong and
where, my httpd servers have "SSL 2 handshake compatibility Yes" and my
ATS servers never had
but that pretty sure explains "140575331768288:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
failure:s23_clnt.c:769" which don't happen to my other servers
given that this is for years now, don't happen on identical virtual
machine clones running httpd instead ATS for me ATS is guilty and not
any other piece in the stack
not sure what "s23_clnt.c:769" means since there is no "s23_clnt.c" in
the httpd source tarball from which "ab" at the end is built
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 25, 2016, at 4:47 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
>
> Am 25.04.2016 um 11:33 schrieb Reindl Harald:
>>
>> Am 17.04.2016 um 01:26 schrieb Leif Hedstrom:
>>>> On Apr 16, 2016, at 4:56 PM, Reindl Harald <h.reindl@thelounge.net
>>>> <ma...@thelounge.net>> wrote:
>>>>
>>>> Am 17.04.2016 um 00:52 schrieb Leif Hedstrom:
>>>>>> On Apr 16, 2016, at 4:44 PM, Reindl Harald <h.reindl@thelounge.net
>>>>>> <ma...@thelounge.net>> wrote:
>>>>>>
>>>>>> Am 17.04.2016 um 00:38 schrieb Leif Hedstrom:
>>>>>>>> so what gives you ab -c 5 -n 100https://www.thelounge.net/on
>>>>>>>> <http://www.thelounge.net/on> your client?
>>>>>>>
>>>>>>> It fails too from that CentOS7 box to your box.
>>>>>>>>
>>>>>>>> [harry@srv-rhsoft:~]$ ab -c 5 -n
>>>>>>>> 100https://docs.trafficserver.apache.org/
>>>>>>>> <http://docs.trafficserver.apache.org/>
>>>>>>>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
>>>>>>>> Copyright 1996 Adam Twiss, Zeus Technology
>>>>>>>> Ltd,http://www.zeustech.net/
>>>>>>>> Licensed to The Apache Software Foundation,http://www.apache.org/
>>>>>>>>
>>>>>>>> Benchmarkingdocs.trafficserver.apache.org
>>>>>>>> <http://benchmarkingdocs.trafficserver.apache.org>
>>>>>>>> <http://docs.trafficserver.apache.org/>(be patient)...^C
>>>>>>>>
>>>>>>>> Server Software: ATS/6.2.0
>>>>>>>> Server Hostname: docs.trafficserver.apache.org
>>>>>>>> <http://docs.trafficserver.apache.org/>
>>>>>>>> Server Port: 443
>>>>>>>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>>>>>>>
>>>>>>> So it seems your ab works against this CentOS7 box running ATS
>>>>>>> v6.2.0 ?
>>>>>>
>>>>>> yes
>>>>>>
>>>>>>> What version of OpenSSL did you build ATS with? I am running
>>>>>>> docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest
>>>>>>> stable
>>>>>>> release)
>>>>>>
>>>>>> seems not matter that much since i have this issue for years now and
>>>>>> the httpd servers are built in the same environments with the same
>>>>>> libraries and don't have that issue
>>>>>
>>>>> Wonder if it could be one of those -f compiler flags? I’m attaching
>>>>> my config.nice that I run on docs.trafficserver, this compiles with
>>>>> ASAN though, so you likely want to remove that at least (if you are
>>>>> willing to try).
>>>>
>>>> i will give it a try ASAP, however the whole web and mail stack is
>>>> built with that flags (based on the flags below which are %{optflags}
>>>> and only ATS has the specific problem
>>>
>>> Yeah, it seems odd that it’d break like that because of compiler flags.
>>> But I honestly have no other ideas as to why it breaks on your system,
>>> and not mine :-/. Can anyone else confirm or deny this breakage on their
>>> installs?
>>
>> just a notice again before i try to build with other flags
>> _____________________________________________
>>
>> https://www.ssllabs.com/ssltest/
>>
>> docs.trafficserver.apache.org:
>> SSL 2 handshake compatibility Yes
>>
>> www.thelounge.net:
>> SSL 2 handshake compatibility No
Double checked the docs.trafficserver configs:
[root@docs ~]# traffic_ctl config match proxy.config.ssl.SSLv
proxy.config.ssl.SSLv2: 0
proxy.config.ssl.SSLv3: 0
I have no idea what this means, is there something in here that makes it properly detect that we handle V2, but do not negotiate it?
— Leif
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.04.2016 um 11:33 schrieb Reindl Harald:
>
> Am 17.04.2016 um 01:26 schrieb Leif Hedstrom:
>>> On Apr 16, 2016, at 4:56 PM, Reindl Harald <h.reindl@thelounge.net
>>> <ma...@thelounge.net>> wrote:
>>>
>>> Am 17.04.2016 um 00:52 schrieb Leif Hedstrom:
>>>>> On Apr 16, 2016, at 4:44 PM, Reindl Harald <h.reindl@thelounge.net
>>>>> <ma...@thelounge.net>> wrote:
>>>>>
>>>>> Am 17.04.2016 um 00:38 schrieb Leif Hedstrom:
>>>>>>> so what gives you ab -c 5 -n 100https://www.thelounge.net/on
>>>>>>> <http://www.thelounge.net/on> your client?
>>>>>>
>>>>>> It fails too from that CentOS7 box to your box.
>>>>>>>
>>>>>>> [harry@srv-rhsoft:~]$ ab -c 5 -n
>>>>>>> 100https://docs.trafficserver.apache.org/
>>>>>>> <http://docs.trafficserver.apache.org/>
>>>>>>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
>>>>>>> Copyright 1996 Adam Twiss, Zeus Technology
>>>>>>> Ltd,http://www.zeustech.net/
>>>>>>> Licensed to The Apache Software Foundation,http://www.apache.org/
>>>>>>>
>>>>>>> Benchmarkingdocs.trafficserver.apache.org
>>>>>>> <http://benchmarkingdocs.trafficserver.apache.org>
>>>>>>> <http://docs.trafficserver.apache.org/>(be patient)...^C
>>>>>>>
>>>>>>> Server Software: ATS/6.2.0
>>>>>>> Server Hostname: docs.trafficserver.apache.org
>>>>>>> <http://docs.trafficserver.apache.org/>
>>>>>>> Server Port: 443
>>>>>>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>>>>>>
>>>>>> So it seems your ab works against this CentOS7 box running ATS
>>>>>> v6.2.0 ?
>>>>>
>>>>> yes
>>>>>
>>>>>> What version of OpenSSL did you build ATS with? I am running
>>>>>> docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest
>>>>>> stable
>>>>>> release)
>>>>>
>>>>> seems not matter that much since i have this issue for years now and
>>>>> the httpd servers are built in the same environments with the same
>>>>> libraries and don't have that issue
>>>>
>>>> Wonder if it could be one of those -f compiler flags? I’m attaching
>>>> my config.nice that I run on docs.trafficserver, this compiles with
>>>> ASAN though, so you likely want to remove that at least (if you are
>>>> willing to try).
>>>
>>> i will give it a try ASAP, however the whole web and mail stack is
>>> built with that flags (based on the flags below which are %{optflags}
>>> and only ATS has the specific problem
>>
>> Yeah, it seems odd that it’d break like that because of compiler flags.
>> But I honestly have no other ideas as to why it breaks on your system,
>> and not mine :-/. Can anyone else confirm or deny this breakage on their
>> installs?
>
> just a notice again before i try to build with other flags
> _____________________________________________
>
> https://www.ssllabs.com/ssltest/
>
> docs.trafficserver.apache.org:
> SSL 2 handshake compatibility Yes
>
> www.thelounge.net:
> SSL 2 handshake compatibility No
> _____________________________________________
>
> CONFIG proxy.config.ssl.SSLv2 INT 0
> CONFIG proxy.config.ssl.SSLv3 INT 0
> CONFIG proxy.config.ssl.TLSv1 INT 1
> CONFIG proxy.config.ssl.TLSv1_1 INT 1
> CONFIG proxy.config.ssl.TLSv1_2 INT 1
> CONFIG proxy.config.ssl.client.certification_level INT 0
> CONFIG proxy.config.ssl.server.multicert.filename STRING
> ssl_multicert.config
> CONFIG proxy.config.ssl.server.cert.path STRING /etc/trafficserver/ssl/
> CONFIG proxy.config.ssl.server.private_key.path STRING
> /etc/trafficserver/ssl/
> CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver/ssl/
> 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:ECD$
>
> CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
> CONFIG proxy.config.ssl.server.dhparams_file STRING
> /etc/trafficserver/ssl/dhparams.pem
no idea - same with the build below - with -fsanitize=address it becomes
fat and unstable (no client connection at all)
#export CFLAGS="-g0 -fstack-protector -fsanitize=address
-fno-omit-frame-pointer"
#export CXXFLAGS="-g0 -fstack-protector -fsanitize=address
-fno-omit-frame-pointer"
#export CPPFLAGS="-D_FORTIFY_SOURCE=2"
#export LDFLAGS="-Wl,-z,relro -Wl,-z,now"
export CFLAGS="-m64 -O2 -g0 -pipe -fstack-protector -fno-strict-aliasing
-fno-omit-frame-pointer -D_FORTIFY_SOURCE=2"
export CXXFLAGS="$CFLAGS"
export CPPFLAGS="-D_FORTIFY_SOURCE=2"
export LDFLAGS="-Wl,-z,relro -Wl,-z,now"
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.04.2016 um 01:26 schrieb Leif Hedstrom:
>> On Apr 16, 2016, at 4:56 PM, Reindl Harald <h.reindl@thelounge.net
>> <ma...@thelounge.net>> wrote:
>>
>> Am 17.04.2016 um 00:52 schrieb Leif Hedstrom:
>>>> On Apr 16, 2016, at 4:44 PM, Reindl Harald <h.reindl@thelounge.net
>>>> <ma...@thelounge.net>> wrote:
>>>>
>>>> Am 17.04.2016 um 00:38 schrieb Leif Hedstrom:
>>>>>> so what gives you ab -c 5 -n 100https://www.thelounge.net/on
>>>>>> <http://www.thelounge.net/on> your client?
>>>>>
>>>>> It fails too from that CentOS7 box to your box.
>>>>>>
>>>>>> [harry@srv-rhsoft:~]$ ab -c 5 -n
>>>>>> 100https://docs.trafficserver.apache.org/
>>>>>> <http://docs.trafficserver.apache.org/>
>>>>>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
>>>>>> Copyright 1996 Adam Twiss, Zeus Technology
>>>>>> Ltd,http://www.zeustech.net/
>>>>>> Licensed to The Apache Software Foundation,http://www.apache.org/
>>>>>>
>>>>>> Benchmarkingdocs.trafficserver.apache.org
>>>>>> <http://benchmarkingdocs.trafficserver.apache.org>
>>>>>> <http://docs.trafficserver.apache.org/>(be patient)...^C
>>>>>>
>>>>>> Server Software: ATS/6.2.0
>>>>>> Server Hostname: docs.trafficserver.apache.org
>>>>>> <http://docs.trafficserver.apache.org/>
>>>>>> Server Port: 443
>>>>>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>>>>>
>>>>> So it seems your ab works against this CentOS7 box running ATS v6.2.0 ?
>>>>
>>>> yes
>>>>
>>>>> What version of OpenSSL did you build ATS with? I am running
>>>>> docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest stable
>>>>> release)
>>>>
>>>> seems not matter that much since i have this issue for years now and
>>>> the httpd servers are built in the same environments with the same
>>>> libraries and don't have that issue
>>>
>>> Wonder if it could be one of those -f compiler flags? I’m attaching
>>> my config.nice that I run on docs.trafficserver, this compiles with
>>> ASAN though, so you likely want to remove that at least (if you are
>>> willing to try).
>>
>> i will give it a try ASAP, however the whole web and mail stack is
>> built with that flags (based on the flags below which are %{optflags}
>> and only ATS has the specific problem
>
> Yeah, it seems odd that it’d break like that because of compiler flags.
> But I honestly have no other ideas as to why it breaks on your system,
> and not mine :-/. Can anyone else confirm or deny this breakage on their
> installs?
just a notice again before i try to build with other flags
_____________________________________________
https://www.ssllabs.com/ssltest/
docs.trafficserver.apache.org:
SSL 2 handshake compatibility Yes
www.thelounge.net:
SSL 2 handshake compatibility No
_____________________________________________
CONFIG proxy.config.ssl.SSLv2 INT 0
CONFIG proxy.config.ssl.SSLv3 INT 0
CONFIG proxy.config.ssl.TLSv1 INT 1
CONFIG proxy.config.ssl.TLSv1_1 INT 1
CONFIG proxy.config.ssl.TLSv1_2 INT 1
CONFIG proxy.config.ssl.client.certification_level INT 0
CONFIG proxy.config.ssl.server.multicert.filename STRING
ssl_multicert.config
CONFIG proxy.config.ssl.server.cert.path STRING /etc/trafficserver/ssl/
CONFIG proxy.config.ssl.server.private_key.path STRING
/etc/trafficserver/ssl/
CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver/ssl/
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:ECD$
CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
CONFIG proxy.config.ssl.server.dhparams_file STRING
/etc/trafficserver/ssl/dhparams.pem
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 16, 2016, at 4:56 PM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 17.04.2016 um 00:52 schrieb Leif Hedstrom:
>>> On Apr 16, 2016, at 4:44 PM, Reindl Harald <h....@thelounge.net> wrote:
>>>
>>> Am 17.04.2016 um 00:38 schrieb Leif Hedstrom:
>>>>> so what gives you ab -c 5 -n 100https://www.thelounge.net/on your client?
>>>>
>>>> It fails too from that CentOS7 box to your box.
>>>>>
>>>>> [harry@srv-rhsoft:~]$ ab -c 5 -n 100https://docs.trafficserver.apache.org/
>>>>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
>>>>> Copyright 1996 Adam Twiss, Zeus Technology Ltd,http://www.zeustech.net/
>>>>> Licensed to The Apache Software Foundation,http://www.apache.org/
>>>>>
>>>>> Benchmarkingdocs.trafficserver.apache.org
>>>>> <http://docs.trafficserver.apache.org/>(be patient)...^C
>>>>>
>>>>> Server Software: ATS/6.2.0
>>>>> Server Hostname: docs.trafficserver.apache.org
>>>>> <http://docs.trafficserver.apache.org/>
>>>>> Server Port: 443
>>>>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>>>>
>>>> So it seems your ab works against this CentOS7 box running ATS v6.2.0 ?
>>>
>>> yes
>>>
>>>> What version of OpenSSL did you build ATS with? I am running
>>>> docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest stable
>>>> release)
>>>
>>> seems not matter that much since i have this issue for years now and the httpd servers are built in the same environments with the same libraries and don't have that issue
>>
>> Wonder if it could be one of those -f compiler flags? I’m attaching my config.nice that I run on docs.trafficserver, this compiles with ASAN though, so you likely want to remove that at least (if you are willing to try).
>
>
> i will give it a try ASAP, however the whole web and mail stack is built with that flags (based on the flags below which are %{optflags} and only ATS has the specific problem
Yeah, it seems odd that it’d break like that because of compiler flags. But I honestly have no other ideas as to why it breaks on your system, and not mine :-/. Can anyone else confirm or deny this breakage on their installs?
Cheers,
— Leif
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.04.2016 um 00:52 schrieb Leif Hedstrom:
>> On Apr 16, 2016, at 4:44 PM, Reindl Harald <h....@thelounge.net> wrote:
>>
>> Am 17.04.2016 um 00:38 schrieb Leif Hedstrom:
>>>> so what gives you ab -c 5 -n 100https://www.thelounge.net/on your client?
>>>
>>> It fails too from that CentOS7 box to your box.
>>>>
>>>> [harry@srv-rhsoft:~]$ ab -c 5 -n 100https://docs.trafficserver.apache.org/
>>>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
>>>> Copyright 1996 Adam Twiss, Zeus Technology Ltd,http://www.zeustech.net/
>>>> Licensed to The Apache Software Foundation,http://www.apache.org/
>>>>
>>>> Benchmarkingdocs.trafficserver.apache.org
>>>> <http://docs.trafficserver.apache.org/>(be patient)...^C
>>>>
>>>> Server Software: ATS/6.2.0
>>>> Server Hostname: docs.trafficserver.apache.org
>>>> <http://docs.trafficserver.apache.org/>
>>>> Server Port: 443
>>>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>>>
>>> So it seems your ab works against this CentOS7 box running ATS v6.2.0 ?
>>
>> yes
>>
>>> What version of OpenSSL did you build ATS with? I am running
>>> docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest stable
>>> release)
>>
>> seems not matter that much since i have this issue for years now and the httpd servers are built in the same environments with the same libraries and don't have that issue
>
> Wonder if it could be one of those -f compiler flags? I’m attaching my config.nice that I run on docs.trafficserver, this compiles with ASAN though, so you likely want to remove that at least (if you are willing to try).
i will give it a try ASAP, however the whole web and mail stack is built
with that flags (based on the flags below which are %{optflags} and only
ATS has the specific problem
__________________________________
[root@buildserver:~]$ cat /home/builduser/.rpmrc
optflags: x86_64 -m64 -O2 -g0 -march=sandybridge -mtune=sandybridge
-fopenmp -mfpmath=sse -pipe -fno-strict-aliasing -fomit-frame-pointer
-finline-functions -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=6 -D_FORTIFY_SOURCE=2 -Wstack-protector -Wformat
-Werror=format-security
__________________________________
[root@buildserver:~]$ cat /home/builduser/.rpmmacros
%_topdir %(echo $HOME)/rpmbuild
%__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
%fedora 23
%dist .fc%fedora.%(echo $(/bin/date +%Y%m%d)).rh
%packager Reindl Harald
%vendor thelounge interactive design
%php_api .php56
%_smp_mflags -j10
%_include_minidebuginfo 0
%_binary_payload w1.gzdio
%_source_payload w1.gzdio
%__global_ldflags -Wl,-z,now -Wl,-z,relro,-z,noexecstack
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
%configure \
CFLAGS="${CFLAGS:-%optflags}"; export CFLAGS; \
CXXFLAGS="${CXXFLAGS:-%optflags}"; export CXXFLAGS; \
FFLAGS="${FFLAGS:-%optflags -I%_fmoddir}"; export FFLAGS; \
FCFLAGS="${FCFLAGS:-%optflags -I%_fmoddir}"; export FCFLAGS; \
LDFLAGS="${LDFLAGS:-%__global_ldflags}"; export LDFLAGS; \
./configure \\\
--host=x86_64-redhat-linux \\\
--build=x86_64-redhat-linux \\\
--target=x86_64-redhat-linux \\\
--program-prefix=%{?_program_prefix} \\\
--disable-dependency-tracking \\\
--prefix=%{_prefix} \\\
--exec-prefix=%{_exec_prefix} \\\
--bindir=%{_bindir} \\\
--sbindir=%{_sbindir} \\\
--sysconfdir=%{_sysconfdir} \\\
--datadir=%{_datadir} \\\
--includedir=%{_includedir} \\\
--libdir=%{_libdir} \\\
--libexecdir=%{_libexecdir} \\\
--localstatedir=%{_localstatedir} \\\
--sharedstatedir=%{_sharedstatedir} \\\
--mandir=%{_mandir} \\\
--infodir=%{_infodir}
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 16, 2016, at 4:44 PM, Reindl Harald <h....@thelounge.net> wrote:
>
>
>
> Am 17.04.2016 um 00:38 schrieb Leif Hedstrom:
>>> so what gives you ab -c 5 -n 100https://www.thelounge.net/on your client?
>>
>> It fails too from that CentOS7 box to your box.
>>
>>>
>>> [harry@srv-rhsoft:~]$ ab -c 5 -n 100https://docs.trafficserver.apache.org/
>>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
>>> Copyright 1996 Adam Twiss, Zeus Technology Ltd,http://www.zeustech.net/
>>> Licensed to The Apache Software Foundation,http://www.apache.org/
>>>
>>> Benchmarkingdocs.trafficserver.apache.org
>>> <http://docs.trafficserver.apache.org/>(be patient)...^C
>>>
>>> Server Software: ATS/6.2.0
>>> Server Hostname: docs.trafficserver.apache.org
>>> <http://docs.trafficserver.apache.org/>
>>> Server Port: 443
>>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>>
>> So it seems your ab works against this CentOS7 box running ATS v6.2.0 ?
>
> yes
>
>> What version of OpenSSL did you build ATS with? I am running
>> docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest stable
>> release)
>
> seems not matter that much since i have this issue for years now and the httpd servers are built in the same environments with the same libraries and don't have that issue
Wonder if it could be one of those -f compiler flags? I’m attaching my config.nice that I run on docs.trafficserver, this compiles with ASAN though, so you likely want to remove that at least (if you are willing to try).
— leif
#! /bin/sh
#
# Created by configure
CC="/opt/gcc5/bin/gcc"; export CC
CXX="/opt/gcc5/bin/g++"; export CXX
CFLAGS="-fstack-protector -fsanitize=address -fno-omit-frame-pointer"; export CFLAGS
CXXFLAGS="-fstack-protector -fsanitize=address -fno-omit-frame-pointer"; export CXXFLAGS
CPPFLAGS="-D_FORTIFY_SOURCE=2"; export CPPFLAGS
LDFLAGS="-Wl,-z,relro -Wl,-z,now"; export LDFLAGS
"./configure" \
"--enable-experimental-plugins" \
"--disable-luajit" \
"--disable-freelist" \
"--enable-ccache" \
"--prefix=/opt/ats" \
"--with-jemalloc" \
"--with-openssl=/opt/openssl" \
"CC=/opt/gcc5/bin/gcc" \
"CXX=/opt/gcc5/bin/g++" \
"CFLAGS=-fstack-protector -fsanitize=address -fno-omit-frame-pointer" \
"CXXFLAGS=-fstack-protector -fsanitize=address -fno-omit-frame-pointer" \
"CPPFLAGS=-D_FORTIFY_SOURCE=2" \
"LDFLAGS=-Wl,-z,relro -Wl,-z,now" \
"$@“
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.04.2016 um 00:38 schrieb Leif Hedstrom:
>> so what gives you ab -c 5 -n 100https://www.thelounge.net/on your client?
>
> It fails too from that CentOS7 box to your box.
>
>>
>> [harry@srv-rhsoft:~]$ ab -c 5 -n 100https://docs.trafficserver.apache.org/
>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
>> Copyright 1996 Adam Twiss, Zeus Technology Ltd,http://www.zeustech.net/
>> Licensed to The Apache Software Foundation,http://www.apache.org/
>>
>> Benchmarkingdocs.trafficserver.apache.org
>> <http://docs.trafficserver.apache.org/>(be patient)...^C
>>
>> Server Software: ATS/6.2.0
>> Server Hostname: docs.trafficserver.apache.org
>> <http://docs.trafficserver.apache.org/>
>> Server Port: 443
>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>
> So it seems your ab works against this CentOS7 box running ATS v6.2.0 ?
yes
> What version of OpenSSL did you build ATS with? I am running
> docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest stable
> release)
seems not matter that much since i have this issue for years now and the
httpd servers are built in the same environments with the same libraries
and don't have that issue
there where a lot of ATS and openssl versions over the time - looking at
the output of ssllabs the ATS box donÄt support some SSL3 *compatibke*
handshake for whatever reasons
[root@buildserver:~]$ rpm -qa | grep openssl
openssl-devel-1.0.2g-2.fc23.20160319.rh.x86_64
openssl-libs-1.0.2g-2.fc23.20160319.rh.x86_64
openssl-1.0.2g-2.fc23.20160319.rh.x86_64
openssl-perl-1.0.2g-2.fc23.20160319.rh.x86_64
[root@buildserver:~]$ rpm -q trafficserver
trafficserver-6.1.1-2.fc23.20160320.rh.x86_64
[root@buildserver:~]$ cat /rpmbuild/SPECS/trafficserver.spec
%global debug_package %{nil}
Summary: Apache Trafficserver
Name: trafficserver
Version: 6.1.1
Release: 2%{?dist}
Epoch: 2
License: ASL 2.0
Group: System Environment/Daemons
Source0:
http://www.apache.org/dist/%{name}/%{name}-%{version}.tar.bz2
Source1: %{name}.service
Source2: %{name}.tmpfilesd
URL: http://trafficserver.apache.org/index.html
BuildRequires: autoconf
BuildRequires: automake
BuildRequires: expat-devel
BuildRequires: gcc-c++
BuildRequires: hwloc-devel
BuildRequires: libaio-devel
BuildRequires: libtool
BuildRequires: openssl-devel
BuildRequires: pcre-devel
BuildRequires: tcl-devel
BuildRequires: xz-devel
BuildRequires: zlib-devel
BuildRequires: ncurses-devel
BuildRequires: libcurl-devel
Requires: systemd
%description
Apache Traffic Server is a fast, scalable and extensible HTTP/1.1
compliant caching proxy server
%package devel
Summary: Apache Traffic Server development libraries and
header files
Group: Development/Libraries
Requires: %{name} = %{version}-%{release}
%description devel
%package manpages
Summary: Trafficserver manuals
Group: Applications/System
%description manpages
%package plugins
Summary: Trafficserver plugins
Group: Applications/System
%description plugins
%prep
%setup -q
%build
export CFLAGS="%{optflags} -O3 -fPIC -Wno-deprecated-declarations
-Wno-error=unused-result -funroll-loops -funswitch-loops
-minline-all-stringops -flto -ffat-lto-objects -fuse-ld=gold
-fuse-linker-plugin"
export CXXFLAGS="$CFLAGS"
export LDFLAGS="-Wl,-z,now -Wl,-z,relro,-z,noexecstack,-fuse-ld=gold
-pie %{optflags} -O3 -funroll-loops -funswitch-loops
-minline-all-stringops -flto -ffat-lto-objects -fuse-ld=gold
-fuse-linker-plugin"
export SH_LDFLAGS="-Wl,-z,now -Wl,-z,relro,-z,noexecstack,-fuse-ld=gold
%{optflags} -O3 -funroll-loops -funswitch-loops -minline-all-stringops
-flto -ffat-lto-objects -fuse-ld=gold -fuse-linker-plugin"
./configure --enable-layout=Gentoo \
--libdir=%{_libdir}/%{name} \
--with-group=ats \
--with-user=ats \
--disable-debug \
--disable-diags \
--disable-spdy \
--disable-static \
--disable-tests \
--enable-hwloc \
--enable-shared \
--with-jemalloc \
--with-pic \
--with-tcl=%{_libdir} \
--with-xml=expat
%{__make} %{?_smp_mflags}
%install
make install-strip DESTDIR=%{buildroot}
mkdir -p %{buildroot}/run/%{name}
install -D -m 0644 -p %{SOURCE1} %{buildroot}%{_unitdir}/%{name}.service
install -D -m 0644 -p %{SOURCE2} %{buildroot}%{_tmpfilesdir}/%{name}.conf
rm -rf %{buildroot}%{_docdir}/%{name} \
%{buildroot}%{_libdir}/perl5/ \
%{buildroot}%{_libdir}/%{name}/*.a \
%{buildroot}%{_libdir}/%{name}/*.la \
%{buildroot}%{_libdir}/%{name}/plugins/*.la \
%{buildroot}%{_datarootdir}/perl5/Apache/TS.pm \
%{buildroot}%{_datarootdir}/perl5/Apache/TS.pm.in \
%{buildroot}%{_datarootdir}/perl5/Apache/TS/AdminClient.pm \
%{buildroot}%{_datarootdir}/perl5/Apache/TS/Config.pm \
%{buildroot}%{_datarootdir}/perl5/Apache/TS/Config/Records.pm \
%{buildroot}%{_bindir}/tspush \
%{buildroot}%{_bindir}/traffic_shell \
%{buildroot}%{_bindir}/traffic_sac \
%{buildroot}%{_bindir}/trafficserver \
%{buildroot}%{_bindir}/tstop \
%{buildroot}%{_bindir}/header_rewrite_test
strip -s %{buildroot}%{_bindir}/traffic_cop \
%{buildroot}%{_bindir}/traffic_line \
%{buildroot}%{_bindir}/traffic_logcat \
%{buildroot}%{_bindir}/traffic_logstats \
%{buildroot}%{_bindir}/traffic_server \
%{buildroot}%{_libdir}/%{name}/*.so* \
%{buildroot}%{_libdir}/%{name}/plugins/*.so
mkdir -p %{buildroot}%{_sysconfdir}/ld.so.conf.d \
%{buildroot}%{_sysconfdir}/%{name}/internal \
%{buildroot}%{_sysconfdir}/%{name}/snapshots \
%{buildroot}%{_sysconfdir}/%{name}/ssl \
%{buildroot}%{_docdir}/%{name}/etc/body_factory/default
chmod 0770 %{buildroot}%{_sysconfdir}/%{name}/internal
chmod 0770 %{buildroot}%{_sysconfdir}/%{name}/snapshots
chmod 0750 %{buildroot}%{_sysconfdir}/%{name}/ssl
chmod 0750 %{buildroot}%{_sysconfdir}/%{name}/body_factory
echo "%{_libdir}/%{name}" >
%{buildroot}%{_sysconfdir}/ld.so.conf.d/%{name}-%{_arch}.conf
mv %{buildroot}%{_sysconfdir}/%{name}/body_factory/default/*
%{buildroot}%{_docdir}/%{name}/etc/body_factory/default/
mv %{buildroot}%{_sysconfdir}/%{name}/*.config
%{buildroot}%{_docdir}/%{name}/etc/
%post
%{_sbindir}/ldconfig
%{_bindir}/systemctl --system daemon-reload &> /dev/null
chown root:ats %{_sysconfdir}/%{name}/body_factory &> /dev/null
chown root:ats %{_sysconfdir}/%{name}/ssl &> /dev/null
chown ats:ats %{_sysconfdir}/%{name}/internal &> /dev/null
chown ats:ats %{_sysconfdir}/%{name}/snapshots &> /dev/null
exit 0
%pre
getent group ats &> /dev/null || groupadd -r ats -g 176 &> /dev/null
getent passwd ats &> /dev/null || useradd -r -u 176 -g ats -d / -s
%{_sbindir}/nologin -c "Apache Traffic Server" ats &> /dev/null
exit 0
%files
%dir %{_libdir}/%{name}
%dir %{_sysconfdir}/%{name}
%config(noreplace) %{_sysconfdir}/%{name}/*
%{_bindir}/traffic*
%{_libdir}/%{name}/*.so.*
%{_unitdir}/%{name}.service
%{_tmpfilesdir}/%{name}.conf
%attr(0770, ats, ats) %dir %{_var}/log/%{name}
%attr(0770, ats, ats) %dir /run/%{name}
%attr(0770, ats, ats) %dir %{_var}/cache/%{name}
%attr(0644, root, root) %{_sysconfdir}/ld.so.conf.d/*
%files devel
%{_bindir}/tsxs
%dir %{_includedir}/trafficserver
%{_includedir}/trafficserver/*
%{_libdir}/%{name}/*.so
%{_libdir}/%{name}/pkgconfig/*.pc
%files manpages
%{_mandir}/man3/*
%{_docdir}/%{name}/*
%files plugins
%dir %{_libdir}/%{name}/plugins
%{_libdir}/%{name}/plugins/*.so
%changelog
* Sun Mar 20 2016 Reindl Harald <h....@thelounge.net>
- update to 6.1.1
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 16, 2016, at 4:38 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>>
>> On Apr 16, 2016, at 4:33 PM, Reindl Harald <h.reindl@thelounge.net <ma...@thelounge.net>> wrote:
>>
>>
>>
>> Am 17.04.2016 um 00:24 schrieb Leif Hedstrom:
>>>
>>>> On Apr 16, 2016, at 11:16 AM, Reindl Harald <h.reindl@thelounge.net <ma...@thelounge.net>> wrote:
>>>>
>>>>
>>>> Am 16.04.2016 um 18:46 schrieb Phil Sorber:
>>>>> Ok, here is my final plan then. I am going to mark them all deprecated
>>>>> for 6.2.x.
>>>>
>>>> when you are at it fix the problem that ATS is the only TLS webserver out there which can't be benchmarked with "ab" reported by my *over years* multiple times while none of the httpd-servers with TLS have SSL2/SSL3 enabled becuas efrankly our openssl has no support für anything below TLS1.0 at all
>>>
>>> I’m not sure what problem exactly you are pointing at here. Is it a bug in ab? Is it a bug in your OpenSSL implementation? Fwiw, I’ve never been able to reproduce this, e.g. this works just fine on CentOS7 (and I have SSL v2 and v3 disabled, of course):
>>>
>>> $ ab -c 5 -n 100 https://docs.trafficserver.apache.org/ <https://docs.trafficserver.apache.org/>
>>>
>>> Server Software: ATS/6.2.0
>>> Server Hostname: docs.trafficserver.apache.org <http://docs.trafficserver.apache.org/>
>>> Server Port: 443
>>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>>>
>>> Document Path: /
>>> Document Length: 229 bytes
>>>
>>> Concurrency Level: 5
>>> Time taken for tests: 2.758 seconds
>>> …
>>>
>>> Looking at your error messages, it sounds like your ab is trying to use SSL v3, which (hopefully?) is disabled on your ATS box?
>>
>> i *never* was able to benchmark my ATS box in the last 4 years and SSL 3 is for sure disabled - as said: openssl on Fedora even don't support it any longer at all
>>
>> i *never* had a problem to benchmark of any httpd box the last 13 years
>>
>> so what gives you ab -c 5 -n 100 https://www.thelounge.net/ <https://www.thelounge.net/> on your client?
>
> It fails too from that CentOS7 box to your box.
>
>>
>>
>> [harry@srv-rhsoft:~]$ ab -c 5 -n 100 https://docs.trafficserver.apache.org/ <https://docs.trafficserver.apache.org/>
>> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
>> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ <http://www.zeustech.net/>
>> Licensed to The Apache Software Foundation, http://www.apache.org/ <http://www.apache.org/>
>>
>> Benchmarking docs.trafficserver.apache.org <http://docs.trafficserver.apache.org/> (be patient)...^C
>>
>> Server Software: ATS/6.2.0
>> Server Hostname: docs.trafficserver.apache.org <http://docs.trafficserver.apache.org/>
>> Server Port: 443
>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>
I did the same test against https://www.ogre.com/ as well, which also runs ATS 6.2, on Fedora 22 (stock OpenSSL). It does not reproduce your problem either :/.
— leif
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 16, 2016, at 4:33 PM, Reindl Harald <h....@thelounge.net> wrote:
>
>
>
> Am 17.04.2016 um 00:24 schrieb Leif Hedstrom:
>>
>>> On Apr 16, 2016, at 11:16 AM, Reindl Harald <h....@thelounge.net> wrote:
>>>
>>>
>>> Am 16.04.2016 um 18:46 schrieb Phil Sorber:
>>>> Ok, here is my final plan then. I am going to mark them all deprecated
>>>> for 6.2.x.
>>>
>>> when you are at it fix the problem that ATS is the only TLS webserver out there which can't be benchmarked with "ab" reported by my *over years* multiple times while none of the httpd-servers with TLS have SSL2/SSL3 enabled becuas efrankly our openssl has no support für anything below TLS1.0 at all
>>
>> I’m not sure what problem exactly you are pointing at here. Is it a bug in ab? Is it a bug in your OpenSSL implementation? Fwiw, I’ve never been able to reproduce this, e.g. this works just fine on CentOS7 (and I have SSL v2 and v3 disabled, of course):
>>
>> $ ab -c 5 -n 100 https://docs.trafficserver.apache.org/
>>
>> Server Software: ATS/6.2.0
>> Server Hostname: docs.trafficserver.apache.org
>> Server Port: 443
>> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>>
>> Document Path: /
>> Document Length: 229 bytes
>>
>> Concurrency Level: 5
>> Time taken for tests: 2.758 seconds
>> …
>>
>> Looking at your error messages, it sounds like your ab is trying to use SSL v3, which (hopefully?) is disabled on your ATS box?
>
> i *never* was able to benchmark my ATS box in the last 4 years and SSL 3 is for sure disabled - as said: openssl on Fedora even don't support it any longer at all
>
> i *never* had a problem to benchmark of any httpd box the last 13 years
>
> so what gives you ab -c 5 -n 100 https://www.thelounge.net/ <https://www.thelounge.net/> on your client?
It fails too from that CentOS7 box to your box.
>
>
> [harry@srv-rhsoft:~]$ ab -c 5 -n 100 https://docs.trafficserver.apache.org/ <https://docs.trafficserver.apache.org/>
> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ <http://www.zeustech.net/>
> Licensed to The Apache Software Foundation, http://www.apache.org/ <http://www.apache.org/>
>
> Benchmarking docs.trafficserver.apache.org <http://docs.trafficserver.apache.org/> (be patient)...^C
>
> Server Software: ATS/6.2.0
> Server Hostname: docs.trafficserver.apache.org <http://docs.trafficserver.apache.org/>
> Server Port: 443
> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
So it seems your ab works against this CentOS7 box running ATS v6.2.0 ?
What version of OpenSSL did you build ATS with? I am running docs.trafficserver.a.o with OpenSSL v1.0.2g if I recall (latest stable release).
Ciao,
— leif
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.04.2016 um 00:24 schrieb Leif Hedstrom:
>
>> On Apr 16, 2016, at 11:16 AM, Reindl Harald <h....@thelounge.net> wrote:
>>
>>
>> Am 16.04.2016 um 18:46 schrieb Phil Sorber:
>>> Ok, here is my final plan then. I am going to mark them all deprecated
>>> for 6.2.x.
>>
>> when you are at it fix the problem that ATS is the only TLS webserver out there which can't be benchmarked with "ab" reported by my *over years* multiple times while none of the httpd-servers with TLS have SSL2/SSL3 enabled becuas efrankly our openssl has no support für anything below TLS1.0 at all
>
> I’m not sure what problem exactly you are pointing at here. Is it a bug in ab? Is it a bug in your OpenSSL implementation? Fwiw, I’ve never been able to reproduce this, e.g. this works just fine on CentOS7 (and I have SSL v2 and v3 disabled, of course):
>
> $ ab -c 5 -n 100 https://docs.trafficserver.apache.org/
>
> Server Software: ATS/6.2.0
> Server Hostname: docs.trafficserver.apache.org
> Server Port: 443
> SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
>
> Document Path: /
> Document Length: 229 bytes
>
> Concurrency Level: 5
> Time taken for tests: 2.758 seconds
> …
>
> Looking at your error messages, it sounds like your ab is trying to use SSL v3, which (hopefully?) is disabled on your ATS box?
i *never* was able to benchmark my ATS box in the last 4 years and SSL 3
is for sure disabled - as said: openssl on Fedora even don't support it
any longer at all
i *never* had a problem to benchmark of any httpd box the last 13 years
so what gives you ab -c 5 -n 100 https://www.thelounge.net/ on your client?
[harry@srv-rhsoft:~]$ ab -c 5 -n 100 https://docs.trafficserver.apache.org/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking docs.trafficserver.apache.org (be patient)...^C
Server Software: ATS/6.2.0
Server Hostname: docs.trafficserver.apache.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
____________________________________
from a centos 7 machine the same problem
ab -c 5 -n 100 https://www.thelounge.net/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.thelounge.net (be patient)...SSL handshake failed (1).
139628279273248:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:744:
SSL handshake failed (1).
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 16, 2016, at 11:16 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 16.04.2016 um 18:46 schrieb Phil Sorber:
>> Ok, here is my final plan then. I am going to mark them all deprecated
>> for 6.2.x.
>
> when you are at it fix the problem that ATS is the only TLS webserver out there which can't be benchmarked with "ab" reported by my *over years* multiple times while none of the httpd-servers with TLS have SSL2/SSL3 enabled becuas efrankly our openssl has no support für anything below TLS1.0 at all
I’m not sure what problem exactly you are pointing at here. Is it a bug in ab? Is it a bug in your OpenSSL implementation? Fwiw, I’ve never been able to reproduce this, e.g. this works just fine on CentOS7 (and I have SSL v2 and v3 disabled, of course):
$ ab -c 5 -n 100 https://docs.trafficserver.apache.org/
Server Software: ATS/6.2.0
Server Hostname: docs.trafficserver.apache.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
Document Path: /
Document Length: 229 bytes
Concurrency Level: 5
Time taken for tests: 2.758 seconds
…
Looking at your error messages, it sounds like your ab is trying to use SSL v3, which (hopefully?) is disabled on your ATS box?
Ciao,
— leif
>
> [harry@srv-rhsoft:~]$ ab -c 5 -n 100 https://www.thelounge.net/
> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
>
> Benchmarking www.thelounge.net (be patient)...SSL handshake failed (1).
> 140124746237920:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
> SSL handshake failed (1).
> 140124746237920:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
> SSL handshake failed (1).
> 140124746237920:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
>
Re: Deprecation of SSL v2/3
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.04.2016 um 18:46 schrieb Phil Sorber:
> Ok, here is my final plan then. I am going to mark them all deprecated
> for 6.2.x.
when you are at it fix the problem that ATS is the only TLS webserver
out there which can't be benchmarked with "ab" reported by my *over
years* multiple times while none of the httpd-servers with TLS have
SSL2/SSL3 enabled becuas efrankly our openssl has no support für
anything below TLS1.0 at all
[harry@srv-rhsoft:~]$ ab -c 5 -n 100 https://www.thelounge.net/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.thelounge.net (be patient)...SSL handshake failed (1).
140124746237920:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:769:
SSL handshake failed (1).
140124746237920:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:769:
SSL handshake failed (1).
140124746237920:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:769:
Re: Deprecation of SSL v2/3
Posted by Phil Sorber <so...@apache.org>.
As discussed,
https://github.com/apache/trafficserver/pull/589
On Sat, Apr 16, 2016 at 10:46 AM Phil Sorber <so...@apache.org> wrote:
> Ok, here is my final plan then. I am going to mark them all deprecated for
> 6.2.x.
>
> Then after branching I am going to remove all client <-> proxy support and
> ifdef out proxy <-> origin support for SSLv3. SSLv2 will be totally gone.
> Then add a configure option that reads something like
> --enable-deprecated-sslv3-to-origin so you can re-enable it in the case
> that you need it, but it's not even compiled in by default. We should also
> leave the default as is and remove the config option from the default
> config file so you have to track it down in the docs and read about how
> unwise it is, etc etc.
>
> Thanks.
>
> On Tue, Apr 12, 2016 at 10:27 AM Yongming Zhao <mi...@gmail.com> wrote:
>
>> +1
>>
>> nice to move forward
>>
>> - Yongming Zhao 赵永明
>>
>> > 在 2016年4月10日，下午8:42，Phil Sorber <so...@apache.org> 写道：
>> >
>> > I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
>> > remove it in 7.0.0.
>> >
>> > Currently our defaults do not enable them and have been that way for
>> about
>> > a year now. For 6.2.0 I'd like to mark them deprecated in the
>> > documentation, and then we remove the code for 7.0.0. This will mean
>> that
>> > as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
>> > library supports it.
>> >
>> > Appreciate any feedback.
>> >
>> > Thanks.
>>
>>
Re: Deprecation of SSL v2/3
Posted by Phil Sorber <so...@apache.org>.
As discussed,
https://github.com/apache/trafficserver/pull/589
On Sat, Apr 16, 2016 at 10:46 AM Phil Sorber <so...@apache.org> wrote:
> Ok, here is my final plan then. I am going to mark them all deprecated for
> 6.2.x.
>
> Then after branching I am going to remove all client <-> proxy support and
> ifdef out proxy <-> origin support for SSLv3. SSLv2 will be totally gone.
> Then add a configure option that reads something like
> --enable-deprecated-sslv3-to-origin so you can re-enable it in the case
> that you need it, but it's not even compiled in by default. We should also
> leave the default as is and remove the config option from the default
> config file so you have to track it down in the docs and read about how
> unwise it is, etc etc.
>
> Thanks.
>
> On Tue, Apr 12, 2016 at 10:27 AM Yongming Zhao <mi...@gmail.com> wrote:
>
>> +1
>>
>> nice to move forward
>>
>> - Yongming Zhao 赵永明
>>
>> > 在 2016年4月10日，下午8:42，Phil Sorber <so...@apache.org> 写道：
>> >
>> > I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
>> > remove it in 7.0.0.
>> >
>> > Currently our defaults do not enable them and have been that way for
>> about
>> > a year now. For 6.2.0 I'd like to mark them deprecated in the
>> > documentation, and then we remove the code for 7.0.0. This will mean
>> that
>> > as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
>> > library supports it.
>> >
>> > Appreciate any feedback.
>> >
>> > Thanks.
>>
>>
Re: Deprecation of SSL v2/3
Posted by Phil Sorber <so...@apache.org>.
Ok, here is my final plan then. I am going to mark them all deprecated for
6.2.x.
Then after branching I am going to remove all client <-> proxy support and
ifdef out proxy <-> origin support for SSLv3. SSLv2 will be totally gone.
Then add a configure option that reads something like
--enable-deprecated-sslv3-to-origin so you can re-enable it in the case
that you need it, but it's not even compiled in by default. We should also
leave the default as is and remove the config option from the default
config file so you have to track it down in the docs and read about how
unwise it is, etc etc.
Thanks.
On Tue, Apr 12, 2016 at 10:27 AM Yongming Zhao <mi...@gmail.com> wrote:
> +1
>
> nice to move forward
>
> - Yongming Zhao 赵永明
>
> > 在 2016年4月10日，下午8:42，Phil Sorber <so...@apache.org> 写道：
> >
> > I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> > remove it in 7.0.0.
> >
> > Currently our defaults do not enable them and have been that way for
> about
> > a year now. For 6.2.0 I'd like to mark them deprecated in the
> > documentation, and then we remove the code for 7.0.0. This will mean that
> > as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> > library supports it.
> >
> > Appreciate any feedback.
> >
> > Thanks.
>
>
Re: Deprecation of SSL v2/3
Posted by Phil Sorber <so...@apache.org>.
Ok, here is my final plan then. I am going to mark them all deprecated for
6.2.x.
Then after branching I am going to remove all client <-> proxy support and
ifdef out proxy <-> origin support for SSLv3. SSLv2 will be totally gone.
Then add a configure option that reads something like
--enable-deprecated-sslv3-to-origin so you can re-enable it in the case
that you need it, but it's not even compiled in by default. We should also
leave the default as is and remove the config option from the default
config file so you have to track it down in the docs and read about how
unwise it is, etc etc.
Thanks.
On Tue, Apr 12, 2016 at 10:27 AM Yongming Zhao <mi...@gmail.com> wrote:
> +1
>
> nice to move forward
>
> - Yongming Zhao 赵永明
>
> > 在 2016年4月10日，下午8:42，Phil Sorber <so...@apache.org> 写道：
> >
> > I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> > remove it in 7.0.0.
> >
> > Currently our defaults do not enable them and have been that way for
> about
> > a year now. For 6.2.0 I'd like to mark them deprecated in the
> > documentation, and then we remove the code for 7.0.0. This will mean that
> > as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> > library supports it.
> >
> > Appreciate any feedback.
> >
> > Thanks.
>
>
Re: Deprecation of SSL v2/3
Posted by Yongming Zhao <mi...@gmail.com>.
+1
nice to move forward
- Yongming Zhao 赵永明
> 在 2016年4月10日，下午8:42，Phil Sorber <so...@apache.org> 写道：
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean that
> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> library supports it.
>
> Appreciate any feedback.
>
> Thanks.
Re: Deprecation of SSL v2/3
Posted by Sudheer Vinukonda <su...@yahoo-inc.com.INVALID>.
+1
On Tuesday, April 12, 2016 7:56 AM, Steven R. Feltner <sf...@godaddy.com> wrote:
+1
> -----Original Message-----
> From: Phil Sorber [mailto:sorber@apache.org]
> Sent: Sunday, April 10, 2016 8:43 AM
> To: dev@trafficserver.apache.org; users@trafficserver.apache.org
> Subject: Deprecation of SSL v2/3
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the documentation,
> and then we remove the code for 7.0.0. This will mean that as of 7.0.0 you
> will not be able to enable SSLv2/3 even if your OpenSSL library supports it.
>
> Appreciate any feedback.
>
> Thanks.
Re: Deprecation of SSL v2/3
Posted by Sudheer Vinukonda <su...@yahoo-inc.com>.
+1
On Tuesday, April 12, 2016 7:56 AM, Steven R. Feltner <sf...@godaddy.com> wrote:
+1
> -----Original Message-----
> From: Phil Sorber [mailto:sorber@apache.org]
> Sent: Sunday, April 10, 2016 8:43 AM
> To: dev@trafficserver.apache.org; users@trafficserver.apache.org
> Subject: Deprecation of SSL v2/3
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the documentation,
> and then we remove the code for 7.0.0. This will mean that as of 7.0.0 you
> will not be able to enable SSLv2/3 even if your OpenSSL library supports it.
>
> Appreciate any feedback.
>
> Thanks.
RE: Deprecation of SSL v2/3
Posted by "Steven R. Feltner" <sf...@godaddy.com>.
+1
> -----Original Message-----
> From: Phil Sorber [mailto:sorber@apache.org]
> Sent: Sunday, April 10, 2016 8:43 AM
> To: dev@trafficserver.apache.org; users@trafficserver.apache.org
> Subject: Deprecation of SSL v2/3
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the documentation,
> and then we remove the code for 7.0.0. This will mean that as of 7.0.0 you
> will not be able to enable SSLv2/3 even if your OpenSSL library supports it.
>
> Appreciate any feedback.
>
> Thanks.
Re: Deprecation of SSL v2/3
Posted by Igor Galić <i....@brainsware.org>.
+1
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: https://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
On Sun, 10 Apr 2016, at 14:42, Phil Sorber wrote:
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for
> about a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean
> that as of 7.0.0 you will not be able to enable SSLv2/3 even if your
> OpenSSL library supports it.
>
> Appreciate any feedback.
>
> Thanks.
Re: Deprecation of SSL v2/3
Posted by Dave Thompson <da...@yahoo-inc.com>.
SSLv2 has been deprecated for 20 years. No browsers supports it. MACs are based on long dead MD5, and SHA1. Handshakes are not protected from MITM corruption, cipher downgrades, or padding attacks. The ciphers are weak, some now considered merely obfuscation. And now with DROWN, whole companies, are vulnerable to all traffic and authentication being compromised if only a single cert sharing machine allows SSLv2 handshake.
ATS should not contribute in anyway to extending the 20 year deprecation of that protocol, or allow for accidental mis-configuration. I would suggest a re-compile be necessary for those interested in flirting with the dangers, perhaps an #ifdef INSECURE_MODE_ON, though I can imagine some might consider even that position morally compromised :-)
On Monday, April 11, 2016 10:06 PM, xuchao <xu...@gmail.com> wrote:
+1 to disable for client <-> proxy
but please keep sslv2/v3 for proxy <-> origin.
I'm implement a man in the middle ssl forward proxy with ats.
发自我的 iPhone
在 2016年4月11日，08:57，Uri Shachar <us...@hotmail.com> 写道：
>> On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
>>
>> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
>> remove it in 7.0.0.
>>
>> Currently our defaults do not enable them and have been that way for about
>> a year now. For 6.2.0 I'd like to mark them deprecated in the
>> documentation, and then we remove the code for 7.0.0. This will mean that
>> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
>> library supports it.
>
> +1 to disabling for client <-> proxy connections.
> Completely disabling for proxy <-> origin is somewhat problematic for the forward proxy use case -- there are still some lingering SSLv3 servers out there, especially inside LANs....
>
> Cheers,
> Uri
Re: Deprecation of SSL v2/3
Posted by Dave Thompson <da...@yahoo-inc.com.INVALID>.
SSLv2 has been deprecated for 20 years. No browsers supports it. MACs are based on long dead MD5, and SHA1. Handshakes are not protected from MITM corruption, cipher downgrades, or padding attacks. The ciphers are weak, some now considered merely obfuscation. And now with DROWN, whole companies, are vulnerable to all traffic and authentication being compromised if only a single cert sharing machine allows SSLv2 handshake.
ATS should not contribute in anyway to extending the 20 year deprecation of that protocol, or allow for accidental mis-configuration. I would suggest a re-compile be necessary for those interested in flirting with the dangers, perhaps an #ifdef INSECURE_MODE_ON, though I can imagine some might consider even that position morally compromised :-)
On Monday, April 11, 2016 10:06 PM, xuchao <xu...@gmail.com> wrote:
+1 to disable for client <-> proxy
but please keep sslv2/v3 for proxy <-> origin.
I'm implement a man in the middle ssl forward proxy with ats.
发自我的 iPhone
在 2016年4月11日，08:57，Uri Shachar <us...@hotmail.com> 写道：
>> On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
>>
>> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
>> remove it in 7.0.0.
>>
>> Currently our defaults do not enable them and have been that way for about
>> a year now. For 6.2.0 I'd like to mark them deprecated in the
>> documentation, and then we remove the code for 7.0.0. This will mean that
>> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
>> library supports it.
>
> +1 to disabling for client <-> proxy connections.
> Completely disabling for proxy <-> origin is somewhat problematic for the forward proxy use case -- there are still some lingering SSLv3 servers out there, especially inside LANs....
>
> Cheers,
> Uri
Re: Deprecation of SSL v2/3
Posted by xuchao <xu...@gmail.com>.
+1 to disable for client <-> proxy
but please keep sslv2/v3 for proxy <-> origin.
I'm implement a man in the middle ssl forward proxy with ats.
发自我的 iPhone
在 2016年4月11日，08:57，Uri Shachar <us...@hotmail.com> 写道：
>> On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
>>
>> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
>> remove it in 7.0.0.
>>
>> Currently our defaults do not enable them and have been that way for about
>> a year now. For 6.2.0 I'd like to mark them deprecated in the
>> documentation, and then we remove the code for 7.0.0. This will mean that
>> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
>> library supports it.
>
> +1 to disabling for client <-> proxy connections.
> Completely disabling for proxy <-> origin is somewhat problematic for the forward proxy use case -- there are still some lingering SSLv3 servers out there, especially inside LANs....
>
> Cheers,
> Uri
Re: Deprecation of SSL v2/3
Posted by Dave Thompson <da...@yahoo-inc.com>.
+1
The consequences from DROWN (CVE-2016-0800 and CVE-2016-0703 ) are too severe on the whole shared cert infrastructure from just one machine being accidentally configured to allow SSLv2.
I filed this ticket:https://issues.apache.org/jira/browse/TS-4247
On Sunday, April 10, 2016 8:33 PM, Masaori Koshiba <ma...@apache.org> wrote:
+1
2016年4月11日(月) 9:57 Uri Shachar <us...@hotmail.com>:
> On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean that
> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> library supports it.
+1 to disabling for client <-> proxy connections.
Completely disabling for proxy <-> origin is somewhat problematic for the forward proxy use case -- there are still some lingering SSLv3 servers out there, especially inside LANs....
Cheers,
Uri
Re: Deprecation of SSL v2/3
Posted by Dave Thompson <da...@yahoo-inc.com.INVALID>.
+1
The consequences from DROWN (CVE-2016-0800 and CVE-2016-0703 ) are too severe on the whole shared cert infrastructure from just one machine being accidentally configured to allow SSLv2.
I filed this ticket:https://issues.apache.org/jira/browse/TS-4247
On Sunday, April 10, 2016 8:33 PM, Masaori Koshiba <ma...@apache.org> wrote:
+1
2016年4月11日(月) 9:57 Uri Shachar <us...@hotmail.com>:
> On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean that
> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> library supports it.
+1 to disabling for client <-> proxy connections.
Completely disabling for proxy <-> origin is somewhat problematic for the forward proxy use case -- there are still some lingering SSLv3 servers out there, especially inside LANs....
Cheers,
Uri
Re: Deprecation of SSL v2/3
Posted by Masaori Koshiba <ma...@apache.org>.
+1
2016年4月11日(月) 9:57 Uri Shachar <us...@hotmail.com>:
> > On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
> >
> > I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> > remove it in 7.0.0.
> >
> > Currently our defaults do not enable them and have been that way for
> about
> > a year now. For 6.2.0 I'd like to mark them deprecated in the
> > documentation, and then we remove the code for 7.0.0. This will mean that
> > as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> > library supports it.
>
> +1 to disabling for client <-> proxy connections.
> Completely disabling for proxy <-> origin is somewhat problematic for the
> forward proxy use case -- there are still some lingering SSLv3 servers out
> there, especially inside LANs....
>
> Cheers,
> Uri
Re: Deprecation of SSL v2/3
Posted by Masaori Koshiba <ma...@apache.org>.
+1
2016年4月11日(月) 9:57 Uri Shachar <us...@hotmail.com>:
> > On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
> >
> > I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> > remove it in 7.0.0.
> >
> > Currently our defaults do not enable them and have been that way for
> about
> > a year now. For 6.2.0 I'd like to mark them deprecated in the
> > documentation, and then we remove the code for 7.0.0. This will mean that
> > as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> > library supports it.
>
> +1 to disabling for client <-> proxy connections.
> Completely disabling for proxy <-> origin is somewhat problematic for the
> forward proxy use case -- there are still some lingering SSLv3 servers out
> there, especially inside LANs....
>
> Cheers,
> Uri
Re: Deprecation of SSL v2/3
Posted by Uri Shachar <us...@hotmail.com>.
> On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean that
> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> library supports it.
+1 to disabling for client <-> proxy connections.
Completely disabling for proxy <-> origin is somewhat problematic for the forward proxy use case -- there are still some lingering SSLv3 servers out there, especially inside LANs....
Cheers,
Uri
Re: Deprecation of SSL v2/3
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean that
> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> library supports it.
Makes sense to me, +1.
— Leif
Re: Deprecation of SSL v2/3
Posted by Uri Shachar <us...@hotmail.com>.
> On Apr 10, 2016, at 7:42 AM, Phil Sorber <so...@apache.org> wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean that
> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> library supports it.
+1 to disabling for client <-> proxy connections.
Completely disabling for proxy <-> origin is somewhat problematic for the forward proxy use case -- there are still some lingering SSLv3 servers out there, especially inside LANs....
Cheers,
Uri
Re: Deprecation of SSL v2/3
Posted by Yongming Zhao <mi...@gmail.com>.
+1
nice to move forward
- Yongming Zhao 赵永明
> 在 2016年4月10日，下午8:42，Phil Sorber <so...@apache.org> 写道：
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean that
> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> library supports it.
>
> Appreciate any feedback.
>
> Thanks.
Re: Deprecation of SSL v2/3
Posted by Theo Schlossnagle <je...@omniti.com>.
+1
> On Apr 10, 2016, at 8:42 AM, Phil Sorber <so...@apache.org> wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> documentation, and then we remove the code for 7.0.0. This will mean that
> as of 7.0.0 you will not be able to enable SSLv2/3 even if your OpenSSL
> library supports it.
>
> Appreciate any feedback.
>
> Thanks.