You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Mikhail T." <mi...@aldan.algebra.com> on 2014/10/28 23:58:25 UTC
Older clients stopped working after server disabled SSLv3
Hello!
After disabling SSLv3:
SSLOptions ALL -SSLv3
we noticed, that curl itself and libcurl-using programs (such as git) stopped
working on some of the (older) systems -- such as RHEL5 -- when invoked against
the https-URLs pointing at the reconfigured servers.
Invoking curl with the -1 option (a.k.a. --tlsv1) worked, but without the option
curl kept failing -- complaining about SSL protocol error. Unfortunately, there
is no way to propagate that option through git to the underlying libcurl...
On newer systems (RHEL6, FreeBSD9), things are fine, but we have a substantial
number of those old ones and need a solution...
I was able to find this question:
http://serverfault.com/questions/637880/disabling-sslv3-but-still-supporting-sslv2hello-in-apache/
and a patch linked to from one of the answers:
http://pastebin.com/Nvat7xTy
I can confirm, that the patch "works" -- curl and git started working after I
restarted the rebuilt httpd. And running sslscan against the patched server
continues to list the "bad" SSLv3 as disabled.
Could somebody, perhaps, begin reviewing it and/or comment even before it is
formally filed with Bugzilla? I searched there, but could not find anything
relevant... Thanks! Yours,
-mi
Re: Older clients stopped working after server disabled SSLv3
Posted by Kaspar Brand <ht...@velox.ch>.
On 01.11.2014 14:46, Yann Ylavic wrote:
> There is still that a client handshaking with a SSLv2Hello (by using
> SSLv23_client_method()) is likely to accept SSLv[23] protocols (unless
> using SSL_OP_NO_SSLv[23] explicitly like today's mod_ssl, but it's
> probably not the case for legacy clients), so MITM attacks on SSLv2
> for example might still be possible.
Protecting broken clients from MITM attacks is not within mod_ssl's
power (nor is it really its business)... the only thing we can do server
side is to refuse negotiating a protocol version lower than TLS 1.0.
The "badness" of SSLv3 as a consequence of Poodle is probably also
somewhat overstated, in particular when taking into account that TLS 1.0
isn't really immune to this kind of padding problem, see this thread:
https://www.ietf.org/mail-archive/web/tls/current/msg14058.html
> But is openssl-1.x's TLSv1_server_method() acting differently than
> 0.9.8's one with regard to SSLv2Hello?
No, it's the same in both versions. Meanwhile I found that there's
actually a subtle difference between 2.2 and 2.4: this change here (from
2005 already) -
https://svn.apache.org/viewvc?view=revision&revision=r264621
was never backported to 2.2, but made its way into 2.4, with the
following impact on mod_ssl:
- when httpd/mod_ssl 2.2 is compiled/run with OpenSSL 0.9.8, "all -SSLv2
-SSLv3" does allow SSLv2 compatible client hellos
- when httpd/mod_ssl 2.4 is compiled/run with OpenSSL 0.9.8, "all
-SSLv3" does *not* allow SSLv2 compatible client hellos
In both cases, "all -SSLv2 -SSLv3" or "all -SSLv3" with OpenSSL 0.9.8
actually amount to "TLSv1", but due to the differences in the
ssl_engine_init.c:ssl_init_ctx_protocol() code between 2.2 and 2.4, the
resulting behavior isn't the same (as for 2.2, SSLv23_server_method() is
chosen, while for 2.4, it's TLSv1_server_method()). My test from
yesterday was with 2.2.29 compiled against OpenSSL 1.0.1, in which case
even setting "SSLProtocol TLSv1" won't reject SSLv2 compatible client
hellos.
> The fact is that several today's clients (probably legacy/heavy) do
> support TLSv1 easily by using SSLv23_client_method() (and let the
> linked openssl do the right thing) since a while, and it's not always
> an option to modify these clients, and no option at all when you are a
> httpd admin...
All we currently know (from the message starting this thread) is
> we noticed, that curl itself and libcurl-using programs (such as git) stopped
> working on some of the (older) systems -- such as RHEL5 -- when invoked against
> the https-URLs pointing at the reconfigured servers.
so it's still quite unclear to me what specific issue we are trying to
address (and how common this is).
> Unless we consider/claim these clients are unsafe per se, and/or
> require openssl >= 1.0 for mod_ssl, I don't see why we should prevent
> them from connecting to httpd configured with "ALL -SSLv3".
IMO, it's more the question of how much tweaks we want to add to mod_ssl
to get OpenSSL behave with regard to supporting SSLv2 compatible client
hellos. If OpenSSL had an official API for enabling/disabling this
setting for the TLS 1.* protocols, then I would be more supportive of
this idea. If we have to rely on implicit OpenSSL behavior in the end,
then it feels more like a hack to me.
Kaspar
Re: Older clients stopped working after server disabled SSLv3
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Nov 1, 2014 at 1:04 PM, Kaspar Brand <ht...@velox.ch> wrote:
> On 01.11.2014 11:23, Yann Ylavic wrote:
>> The real questions IMO is:
>> Is SSLv2Hello replied with TLSv1.x server hello really safe against
>> MITM/poodle/other attacks?
>
> Well, no one can answer this question with "yes" as long as you do not
> define "other attacks". From what is known today, however, accepting
> SSLv2 client hellos does not lead to additional vulnerabilities compared
> to a TLS client hello.
OK, thanks for clarifying this, no (known) issue then from a server perspective.
There is still that a client handshaking with a SSLv2Hello (by using
SSLv23_client_method()) is likely to accept SSLv[23] protocols (unless
using SSL_OP_NO_SSLv[23] explicitly like today's mod_ssl, but it's
probably not the case for legacy clients), so MITM attacks on SSLv2
for example might still be possible.
> See also RFC 6176 section 3:
>
>> o TLS servers MAY continue to accept ClientHello messages in the
>> version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2],
>> Appendix E.2. Note that this does not contradict the prohibition
>> against actually negotiating the use of SSL 2.0.
>
> And this is what RFC 5246 says about its interpretation:
>
>> For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
>> way as a ClientHello with a "null" compression method and no
>> extensions.
>
> (Less options and extensions usually mean less potential for getting
> things wrong - just a general observation, not specific to the issue at
> hand.)
I guess it depends on whether or not extensions are involved in the
counter measures.
>
>> The problem is that with OpenSSL 0.9.8, "ALL -SSLv3" leaves only
>> SSL_PROTOCOL_TLSV1, and TLSv1_server_method() won't accept SSLv2Hello
>> (according to my own tests with openssl s_client).
>
> Ok, I see - so it's actually not about "Older clients" (as the subject
> of this thread refers to), but about mod_ssl compiled against OpenSSL
> 0.9.8 and not allowing TLS 1.0 connections with an SSLv2 compatible
> hello, is that correct?
Yes, at least for my own tests.
But is openssl-1.x's TLSv1_server_method() acting differently than
0.9.8's one with regard to SSLv2Hello?
(I'll give it a test).
> Given that 1.0.0 has been around for more than 4
> years already and 0.9.8 will be EOL'ed by the end of 2015, I don't think
> we should spend too much effort into addressing such legacy-version
> issues. I would again point to RFC 6176 section 3, and specifically:
>
>> o TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-
>> HELLO message format. Clients MUST NOT send any ClientHello
>> message that specifies a protocol version less than
>> { 0x03, 0x00 }. As previously stated by the definitions of all
>> previous versions of TLS, the client SHOULD specify the highest
>> protocol version it supports.
>
> (i.e., there's no good reason for a TLS-capable client to use an SSLv2
> compatible hello.)
Well, end of 2015 is not quite the same as tomorrow...
The fact is that several today's clients (probably legacy/heavy) do
support TLSv1 easily by using SSLv23_client_method() (and let the
linked openssl do the right thing) since a while, and it's not always
an option to modify these clients, and no option at all when you are a
httpd admin...
Unless we consider/claim these clients are unsafe per se, and/or
require openssl >= 1.0 for mod_ssl, I don't see why we should prevent
them from connecting to httpd configured with "ALL -SSLv3".
>
>> openssl s_client (with no protocol option, eg. -tls1/-ssl3/...) uses SSLv2Hello.
>
> It's not just determined by the use of these protocol switches,
> actually. It also depends on the OpenSSL version and whether SSLv2
> ciphers are still enabled. With OpenSSL 1.0.0 and later, SSLv2
> compatible client hellos are essentially gone:
So it might also depend on "Older" vs "Newer" clients too...
Regards,
Yann.
Re: Older clients stopped working after server disabled SSLv3
Posted by Kaspar Brand <ht...@velox.ch>.
On 01.11.2014 11:23, Yann Ylavic wrote:
> How about SSLv2Hello keyword (à la JDK), should we agree on a real
> issue caused by "ALL -SSLv3" (see below)?
This keyword wouldn't fit into the current set of options, so I'm not in
favor of it (the SSL2 compatible hello is like a flag which is
orthogonal to the protocol version).
> The real questions IMO is:
> Is SSLv2Hello replied with TLSv1.x server hello really safe against
> MITM/poodle/other attacks?
Well, no one can answer this question with "yes" as long as you do not
define "other attacks". From what is known today, however, accepting
SSLv2 client hellos does not lead to additional vulnerabilities compared
to a TLS client hello. See also RFC 6176 section 3:
> o TLS servers MAY continue to accept ClientHello messages in the
> version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2],
> Appendix E.2. Note that this does not contradict the prohibition
> against actually negotiating the use of SSL 2.0.
And this is what RFC 5246 says about its interpretation:
> For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
> way as a ClientHello with a "null" compression method and no
> extensions.
(Less options and extensions usually mean less potential for getting
things wrong - just a general observation, not specific to the issue at
hand.)
> The problem is that with OpenSSL 0.9.8, "ALL -SSLv3" leaves only
> SSL_PROTOCOL_TLSV1, and TLSv1_server_method() won't accept SSLv2Hello
> (according to my own tests with openssl s_client).
Ok, I see - so it's actually not about "Older clients" (as the subject
of this thread refers to), but about mod_ssl compiled against OpenSSL
0.9.8 and not allowing TLS 1.0 connections with an SSLv2 compatible
hello, is that correct? Given that 1.0.0 has been around for more than 4
years already and 0.9.8 will be EOL'ed by the end of 2015, I don't think
we should spend too much effort into addressing such legacy-version
issues. I would again point to RFC 6176 section 3, and specifically:
> o TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-
> HELLO message format. Clients MUST NOT send any ClientHello
> message that specifies a protocol version less than
> { 0x03, 0x00 }. As previously stated by the definitions of all
> previous versions of TLS, the client SHOULD specify the highest
> protocol version it supports.
(i.e., there's no good reason for a TLS-capable client to use an SSLv2
compatible hello.)
> openssl s_client (with no protocol option, eg. -tls1/-ssl3/...) uses SSLv2Hello.
It's not just determined by the use of these protocol switches,
actually. It also depends on the OpenSSL version and whether SSLv2
ciphers are still enabled. With OpenSSL 1.0.0 and later, SSLv2
compatible client hellos are essentially gone:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9ae5743515f88f481c0e1075c21404e67d9cc197
Kaspar
Re: Older clients stopped working after server disabled SSLv3
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Nov 1, 2014 at 8:15 AM, Kaspar Brand <ht...@velox.ch> wrote:
> On 29.10.2014 16:42, Yann Ylavic wrote:
>> On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. <mi...@aldan.algebra.com> wrote:
>>> That would solve our problem, though some may wonder about the subtle
>>> differences between "any" and "all" :-) More seriously, it would also make
>>> the config-files incompatible with earlier httpd-releases -- whereas the
>>> patch I linked to does not have this problem.
>
> Definitely agreeing with Mikhail. Adding "Any" as another option is just
> likely to cause even more confusion (and I'm also not in support of adding
> things like "safe", just for the records).
Well, I must admit ANY may be confusing (but definitively not a
compatibility issue).
How about SSLv2Hello keyword (à la JDK), should we agree on a real
issue caused by "ALL -SSLv3" (see below)?
This might also be confusing though, one may think this is the whole
SSLv2 protocol...
The real questions IMO is:
Is SSLv2Hello replied with TLSv1.x server hello really safe against
MITM/poodle/other attacks?
IOW, is it safe to accept SSLv2Hello whereas SSLv2 and SSLv3 are disabled?
I couldn't find any pointer to this answer, only conjectures about not
being treated unsafe by poodle vulnerabilty (online) detectors...
Clearly, is it worth handling it?
>
> Without clear steps on how to reproduce the problem (what httpd version,
> what OpenSSL version, what client, what SSLProtocol settings), I'm fairly
> doubtful that there really is a problem here. From a quick glance at
> OpenSSL's s23_srvr.c:ssl23_get_client_hello(), I fail to see any reason
> why the current mod_ssl code in
> ssl_engine_init.c:ssl_init_ctx_protocol() would disable the acceptance
> of an SSLv2 compatible ClientHello when a single protocol setting (cases
> like protocol == SSL_PROTOCOL_TLSV1) is active.
I also posted a reproducer in this thread...
The problem is that with OpenSSL 0.9.8, "ALL -SSLv3" leaves only
SSL_PROTOCOL_TLSV1, and TLSv1_server_method() won't accept SSLv2Hello
(according to my own tests with openssl s_client).
With OpenSSL 1.x, all SSL_PROTOCOL_TLSV1* are still active, and httpd
will use SSLv23_server_method(), hence SSLv2Hello is accepted.
>
> Reading further down on the serverfault entry referenced earlier [1],
> the "real" OP (Matt Hughes, i.e. the one who posted to httpd-users, in
> the thread mentioned by Jeff) meanwhile came to the conclusion that his
> problem "was a non-issue all along. Apache will accept SSLv2 handshake
> with either of the configurations I posted above". In fact, I have no
> problem to connect to httpd/mod_ssl with "SSLProtocol TLSv1", when
> using "openssl s_client -cipher RC4-MD5 -connect ...", (provided that
> RC4-MD5 is still enabled server-side). In that case, I'm seeing an
> SSLv2 compatible hello, with TLS 1.0 getting negotiated in the end.
openssl s_client (with no protocol option, eg. -tls1/-ssl3/...) uses SSLv2Hello.
The serverfault's OP does not mention the version of openssl used by his httpd.
Regards,
Yann.
Re: Older clients stopped working after server disabled SSLv3
Posted by Kaspar Brand <ht...@velox.ch>.
On 29.10.2014 16:42, Yann Ylavic wrote:
> On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. <mi...@aldan.algebra.com> wrote:
>> That would solve our problem, though some may wonder about the subtle
>> differences between "any" and "all" :-) More seriously, it would also make
>> the config-files incompatible with earlier httpd-releases -- whereas the
>> patch I linked to does not have this problem.
Definitely agreeing with Mikhail. Adding "Any" as another option is just
likely to cause even more confusion (and I'm also not in support of adding
things like "safe", just for the records).
Without clear steps on how to reproduce the problem (what httpd version,
what OpenSSL version, what client, what SSLProtocol settings), I'm fairly
doubtful that there really is a problem here. From a quick glance at
OpenSSL's s23_srvr.c:ssl23_get_client_hello(), I fail to see any reason
why the current mod_ssl code in
ssl_engine_init.c:ssl_init_ctx_protocol() would disable the acceptance
of an SSLv2 compatible ClientHello when a single protocol setting (cases
like protocol == SSL_PROTOCOL_TLSV1) is active.
Reading further down on the serverfault entry referenced earlier [1],
the "real" OP (Matt Hughes, i.e. the one who posted to httpd-users, in
the thread mentioned by Jeff) meanwhile came to the conclusion that his
problem "was a non-issue all along. Apache will accept SSLv2 handshake
with either of the configurations I posted above". In fact, I have no
problem to connect to httpd/mod_ssl with "SSLProtocol TLSv1", when
using "openssl s_client -cipher RC4-MD5 -connect ...", (provided that
RC4-MD5 is still enabled server-side). In that case, I'm seeing an
SSLv2 compatible hello, with TLS 1.0 getting negotiated in the end.
Kaspar
[1] http://serverfault.com/questions/637880/disabling-sslv3-but-still-supporting-sslv2hello-in-apache/
Re: Older clients stopped working after server disabled SSLv3
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. <mi...@aldan.algebra.com> wrote:
> On 29.10.2014 04:37, Yann Ylavic wrote:
>>
>> Forgot to mention the OP reproducer, that is with "SSLProtocol ALL
>> -SSLv3" (with or without the patch), both SSLv2Hello and SSLv3Hello
>> (version SSLv3) are refused by httpd.
>
> But if "ALL" is replaced with "ANY", then the (patched) server will be
> willing to advise the connecting clients to talk TLS, right?
Right, since the only protocols remaining are TLSv1.x (SSLv2 is
forcibly disabled in 2.4.x).
ANY is to be seen as "ALL +SSLv2Hello", maybe SSLv2Hello would be a
clearer keywork, but IMHO it couldn't be included to ALL w/o breaking
(some) configuration.
Since ALL not including SSLv2Hello looked weird to me, I proposed the
ANY semantic...
I'm quite open on the terms, though.
>
> That would solve our problem, though some may wonder about the subtle
> differences between "any" and "all" :-) More seriously, it would also make
> the config-files incompatible with earlier httpd-releases -- whereas the
> patch I linked to does not have this problem.
ANY is not meant to replace ALL, the latter would still exist and do
the same thing as before.
Just using "ANY -SSLv3" *instead of* "ALL -SSLv3" would do the trick
for you, and not change the existing configurations pleased with the
current meaning of ALL.
>
> But if your patch is going to be part of the next release, I'll proceed to
> building the (patched) 2.4.10 here ahead of time -- corporate Information
> Security are quite nervous about us still allowing SSLv3...
Using my patch, "SSLProtocol ANY -SSLv3" should be enough.
It is less intrusive than using SSLv23 inconditionaly (ie. does not
break "SSLProtocol TLSv1.2" where really TLSv1.2 only is to be allowed
from the first ClientHello).
Regards,
Yann.
Re: Older clients stopped working after server disabled SSLv3
Posted by "Mikhail T." <mi...@aldan.algebra.com>.
On 29.10.2014 04:37, Yann Ylavic wrote:
> Forgot to mention the OP reproducer, that is with "SSLProtocol ALL
> -SSLv3" (with or without the patch), both SSLv2Hello and SSLv3Hello
> (version SSLv3) are refused by httpd.
But if "ALL" is replaced with "ANY", then the (patched) server will be
willing to advise the connecting clients to talk TLS, right?
That would solve our problem, though some may wonder about the subtle
differences between "any" and "all" :-) More seriously, it would also
make the config-files incompatible with earlier httpd-releases --
whereas the patch I linked to does not have this problem.
But if your patch is going to be part of the next release, I'll proceed
to building the (patched) 2.4.10 here ahead of time -- corporate
Information Security are quite nervous about us still allowing SSLv3...
Thanks! Yours,
-mi
Re: Older clients stopped working after server disabled SSLv3
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Oct 29, 2014 at 4:16 AM, Yann Ylavic <yl...@gmail.com> wrote:
> Actually I tested the above with my earlier patch (slightly modified
> to initialize "ANY" with SSL_PROTOCOL_ALL|SSL_PROTOCOL_ANY instead of
> SSL_PROTOCOL_ANY alone) and it seems to work.
>
> With OpenSSL 0.9.8o (debian squeeze) :
> - openssl s_client using SSLv23 connects with SSLv2Hello and httpd
> handshakes correctly with TLSv1,
> - openssl s_client using TLSv1 connects with SSLv3Hello (version
> TLSv1) and httpd handshakes correctly with TLSv1,
> - openssl s_client using SSLv3 connects with SSLv3Hello (version
> SSLv3) and httpd refuses to handshake.
Forgot to mention the OP reproducer, that is with "SSLProtocol ALL
-SSLv3" (with or without the patch), both SSLv2Hello and SSLv3Hello
(version SSLv3) are refused by httpd.
>
> Regards,
> Yann.
Re: Older clients stopped working after server disabled SSLv3
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Oct 29, 2014 at 3:01 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Wed, Oct 29, 2014 at 2:43 AM, Yann Ylavic <yl...@gmail.com> wrote:
>> Maybe we should introduce another protocol keywork, namely ANY, which
>> would opt-in SSLv23 (SSLv2Hello), and not disable single protocol
>> configuration in any case like in the patch proposed by Mikhail.
>
> So that "SSLProtocol ANY -SSLv3" would still negociate TLSv1.x only
> but would accept SSLv2Hello from client.
> Clients using a v2Hello won't send TLS extensions though (while the
> ServerHello should be TLSv1.0), so if this may solve compatibiliy
> issues, I'm not sure it is secure to use it (no full TLS/extensions
> handshake)...
Actually I tested the above with my earlier patch (slightly modified
to initialize "ANY" with SSL_PROTOCOL_ALL|SSL_PROTOCOL_ANY instead of
SSL_PROTOCOL_ANY alone) and it seems to work.
With OpenSSL 0.9.8o (debian squeeze) :
- openssl s_client using SSLv23 connects with SSLv2Hello and httpd
handshakes correctly with TLSv1,
- openssl s_client using TLSv1 connects with SSLv3Hello (version
TLSv1) and httpd handshakes correctly with TLSv1,
- openssl s_client using SSLv3 connects with SSLv3Hello (version
SSLv3) and httpd refuses to handshake.
Regards,
Yann.
Re: Older clients stopped working after server disabled SSLv3
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Oct 29, 2014 at 2:43 AM, Yann Ylavic <yl...@gmail.com> wrote:
> Maybe we should introduce another protocol keywork, namely ANY, which
> would opt-in SSLv23 (SSLv2Hello), and not disable single protocol
> configuration in any case like in the patch proposed by Mikhail.
So that "SSLProtocol ANY -SSLv3" would still negociate TLSv1.x only
but would accept SSLv2Hello from client.
Clients using a v2Hello won't send TLS extensions though (while the
ServerHello should be TLSv1.0), so if this may solve compatibiliy
issues, I'm not sure it is secure to use it (no full TLS/extensions
handshake)...
Re: Older clients stopped working after server disabled SSLv3
Posted by Eric Covener <co...@gmail.com>.
On Tue, Oct 28, 2014 at 9:43 PM, Yann Ylavic <yl...@gmail.com> wrote:
> >
> > Kaspar, does the v2open require sslv2method? What do you think of the
> patch
> > above?
>
> I don't think so, SSLv23 seams to use the lowest non-disabled method,
> and we explicitely disable the ones not configured. So it should work.
> Kaspar has probably a better understanding than me on this though.
Whoops, I meant sslv23method there.
Re: Older clients stopped working after server disabled SSLv3
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Oct 29, 2014 at 2:15 AM, Eric Covener <co...@gmail.com> wrote:
> They had a year-old httpd2.4 from EPEL / RH software collections but it's
> built against an old openssl, so it isn't aware of tls1.1 and tls1.2 and
> that same block of code ends up locking you into exactly TLSv1.0 once you
> remove sslv2 and sslv3. If you leave sslv2, it gets disabled below that
> block and none of the equality checks match. They didn't get to test that
> for me yet.
I think that's what happening without TLSv1.1 and TLSv1.2 available
(eg. openssl 0.9.8).
There remain only TLSv1.0 since SSLv2 is forcibly disabled in 2.4.x.
Maybe we should introduce another protocol keywork, namely ANY, which
would opt-in SSLv23 (SSLv2Hello), and not disable single protocol
configuration in any case like in the patch proposed by Mikhail.
Something like the following patch :
Index: modules/ssl/ssl_private.h
===================================================================
--- modules/ssl/ssl_private.h (revision 1635012)
+++ modules/ssl/ssl_private.h (working copy)
@@ -295,8 +295,10 @@ typedef int ssl_opt_t;
#define SSL_PROTOCOL_TLSV1_2 (1<<4)
#define SSL_PROTOCOL_ALL (SSL_PROTOCOL_SSLV3|SSL_PROTOCOL_TLSV1| \
SSL_PROTOCOL_TLSV1_1|SSL_PROTOCOL_TLSV1_2)
+#define SSL_PROTOCOL_ANY (1<<5)
#else
#define SSL_PROTOCOL_ALL (SSL_PROTOCOL_SSLV3|SSL_PROTOCOL_TLSV1)
+#define SSL_PROTOCOL_ANY (1<<3)
#endif
typedef int ssl_proto_t;
Index: modules/ssl/ssl_engine_init.c
===================================================================
--- modules/ssl/ssl_engine_init.c (revision 1635012)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -490,6 +490,7 @@ static apr_status_t ssl_init_ctx_protocol(server_r
}
cp = apr_pstrcat(p,
+ (protocol & SSL_PROTOCOL_ANY ? "SSLv23, " : ""),
(protocol & SSL_PROTOCOL_SSLV3 ? "SSLv3, " : ""),
(protocol & SSL_PROTOCOL_TLSV1 ? "TLSv1, " : ""),
#ifdef HAVE_TLSV1_X
Index: modules/ssl/ssl_engine_config.c
===================================================================
--- modules/ssl/ssl_engine_config.c (revision 1635012)
+++ modules/ssl/ssl_engine_config.c (working copy)
@@ -1311,6 +1311,9 @@ static const char *ssl_cmd_protocol_parse(cmd_parm
else if (strcEQ(w, "all")) {
thisopt = SSL_PROTOCOL_ALL;
}
+ else if (strcEQ(w, "any")) {
+ thisopt = SSL_PROTOCOL_ANY;
+ }
else {
return apr_pstrcat(parms->temp_pool,
parms->cmd->name,
Index: modules/ssl/ssl_engine_io.c
===================================================================
--- modules/ssl/ssl_engine_io.c (revision 1635012)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -1137,6 +1137,7 @@ static apr_status_t ssl_io_filter_handshake(ssl_fi
* IPv4 and IPv6 addresses are not permitted".)
*/
if (hostname_note &&
+ !(sc->proxy->protocol & SSL_PROTOCOL_ANY) &&
sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
apr_ipsubnet_create(&ip, hostname_note, NULL,
c->pool) != APR_SUCCESS) {
[END]
>
> Kaspar, does the v2open require sslv2method? What do you think of the patch
> above?
I don't think so, SSLv23 seams to use the lowest non-disabled method,
and we explicitely disable the ones not configured. So it should work.
Kaspar has probably a better understanding than me on this though.
Regards,
Yann.
Re: Older clients stopped working after server disabled SSLv3
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Oct 28, 2014 at 9:24 PM, Eric Covener <co...@gmail.com> wrote:
>
> On Tue, Oct 28, 2014 at 9:15 PM, Eric Covener <co...@gmail.com> wrote:
>
>> There is an older/pre-poodle PR out there somewhere where the symptom
>> seems to be the v2hello/v2open disappearing with -SSLv3.
>
>
> I can't find it though -- Jeff?
>
I'm pretty sure that this is what I remembered:
http://mail-archives.apache.org/mod_mbox/httpd-users/201410.mbox/%3CE5CE5150-61E8-4342-834E-F79ADDEAB3A1@gmail.com%3E
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Older clients stopped working after server disabled SSLv3
Posted by Eric Covener <co...@gmail.com>.
On Tue, Oct 28, 2014 at 9:15 PM, Eric Covener <co...@gmail.com> wrote:
> There is an older/pre-poodle PR out there somewhere where the symptom
> seems to be the v2hello/v2open disappearing with -SSLv3.
I can't find it though -- Jeff?
Re: Older clients stopped working after server disabled SSLv3
Posted by Eric Covener <co...@gmail.com>.
On Tue, Oct 28, 2014 at 6:58 PM, Mikhail T. <mi...@aldan.algebra.com>
wrote:
> Hello!
>
> After disabling SSLv3:
>
> SSLOptions ALL -SSLv3
>
> we noticed, that curl itself and libcurl-using programs (such as git)
> stopped working on some of the (older) systems -- such as RHEL5 -- when
> invoked against the https-URLs pointing at the reconfigured servers.
>
> Invoking curl with the -1 option (a.k.a. --tlsv1) worked, but without the
> option curl kept failing -- complaining about SSL protocol error.
> Unfortunately, there is no way to propagate that option through git to the
> underlying libcurl...
>
> On newer systems (RHEL6, FreeBSD9), things are fine, but we have a
> substantial number of those old ones and need a solution...
>
> I was able to find this question:
>
>
> http://serverfault.com/questions/637880/disabling-sslv3-but-still-supporting-sslv2hello-in-apache/
>
> and a patch linked to from one of the answers:
>
> http://pastebin.com/Nvat7xTy
>
> I can confirm, that the patch "works" -- curl and git started working
> after I restarted the rebuilt httpd. And running sslscan against the
> patched server continues to list the "bad" SSLv3 as disabled.
>
> Could somebody, perhaps, begin reviewing it and/or comment even before it
> is formally filed with Bugzilla? I searched there, but could not find
> anything relevant... Thanks! Yours,
>
> -mi
>
>
I was working with someone on a similar problem but they disappeared for
now. I had come to a similar conclusion for another of their symptoms, but
didn't know enough openssl to understand how it affected the v2open.
They had a year-old httpd2.4 from EPEL / RH software collections but it's
built against an old openssl, so it isn't aware of tls1.1 and tls1.2 and
that same block of code ends up locking you into exactly TLSv1.0 once you
remove sslv2 and sslv3. If you leave sslv2, it gets disabled below that
block and none of the equality checks match. They didn't get to test that
for me yet.
Ironically my colleague was actually reporting the issue with the
v2open/v2hello and they noticed the tls1.1/tls1.2 disappearing issue as
trivia. But I was not even sure the v2open was really the culprit.
There is an older/pre-poodle PR out there somewhere where the symptom seems
to be the v2hello/v2open disappearing with -SSLv3.
Kaspar, does the v2open require sslv2method? What do you think of the patch
above?
--
Eric Covener
covener@gmail.com