Re: Older clients stopped working after server disabled SSLv3

2014-11-02 Thread Kaspar Brand 
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=revisionrevision=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

2014-11-01 Thread Kaspar Brand 
On 29.10.2014 16:42, Yann Ylavic wrote:
 On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. mi+t...@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

2014-11-01 Thread Yann Ylavic 
On Sat, Nov 1, 2014 at 8:15 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
 On 29.10.2014 16:42, Yann Ylavic wrote:
 On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. mi+t...@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

2014-11-01 Thread Kaspar Brand 
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

2014-11-01 Thread Yann Ylavic 
On Sat, Nov 1, 2014 at 1:04 PM, Kaspar Brand httpd-dev.2...@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

2014-10-29 Thread Yann Ylavic 
On Wed, Oct 29, 2014 at 4:16 AM, Yann Ylavic ylavic@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

2014-10-29 Thread Jeff Trawick 
On Tue, Oct 28, 2014 at 9:24 PM, Eric Covener cove...@gmail.com wrote:


 On Tue, Oct 28, 2014 at 9:15 PM, Eric Covener cove...@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-f79addeab...@gmail.com%3E



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Older clients stopped working after server disabled SSLv3

2014-10-29 Thread Mikhail T. 
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

2014-10-29 Thread Yann Ylavic 
On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. mi+t...@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.

Older clients stopped working after server disabled SSLv3

2014-10-28 Thread Mikhail T. 
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

2014-10-28 Thread Eric Covener 
On Tue, Oct 28, 2014 at 6:58 PM, Mikhail T. mi+t...@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
cove...@gmail.com

Re: Older clients stopped working after server disabled SSLv3

2014-10-28 Thread Eric Covener 
On Tue, Oct 28, 2014 at 9:15 PM, Eric Covener cove...@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

2014-10-28 Thread Yann Ylavic 
On Wed, Oct 29, 2014 at 2:15 AM, Eric Covener cove...@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 (14)
 #define SSL_PROTOCOL_ALL   (SSL_PROTOCOL_SSLV3|SSL_PROTOCOL_TLSV1| \
 SSL_PROTOCOL_TLSV1_1|SSL_PROTOCOL_TLSV1_2)
+#define SSL_PROTOCOL_ANY   (15)
 #else
 #define SSL_PROTOCOL_ALL   (SSL_PROTOCOL_SSLV3|SSL_PROTOCOL_TLSV1)
+#define SSL_PROTOCOL_ANY   (13)
 #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

2014-10-28 Thread Eric Covener 
On Tue, Oct 28, 2014 at 9:43 PM, Yann Ylavic ylavic@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

2014-10-28 Thread Yann Ylavic 
On Wed, Oct 29, 2014 at 2:43 AM, Yann Ylavic ylavic@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

2014-10-28 Thread Yann Ylavic 
On Wed, Oct 29, 2014 at 3:01 AM, Yann Ylavic ylavic@gmail.com wrote:
 On Wed, Oct 29, 2014 at 2:43 AM, Yann Ylavic ylavic@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.