Re: bug with SSLVerifyClient?

2016-11-23 Thread Helmut K. C. Tessarek
On 2016-11-21 12:40, Helmut K. C. Tessarek wrote:
> Can someone please shed some light on this?

Anyone? I really hoped that somebody who knew the code could explain
this behavior to me, since it makes no sense (and contradicts the
documentation).

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek
lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


Re: bug with SSLVerifyClient?

2016-11-23 Thread Eric Covener
On Mon, Nov 21, 2016 at 12:40 PM, Helmut K. C. Tessarek
 wrote:
> But I noticed that it is completely ignored (it always asks for a
> user/password, no matter, if I have the client cert installed or not).

I only have experience w/ a proprietary SSL mod, but:

* I didn't think SSLVerifyClient's data was ever implicitly used in
lieu of basic auth, this gave me pause in the quoted sentence
* The thing to look for here would be whether your request triggers an
SSL renegotiation or not, and if in that 2nd handhsake there is a
certificate request from the server.
* These configs won't work when TLS1.3 arrives because there is no
renegotiation.

-- 
Eric Covener
cove...@gmail.com


Re: bug with SSLVerifyClient?

2016-11-23 Thread Helmut K. C. Tessarek
On 2016-11-23 12:36, Eric Covener wrote:
> * I didn't think SSLVerifyClient's data was ever implicitly used in
> lieu of basic auth, this gave me pause in the quoted sentence
> * The thing to look for here would be whether your request triggers an
> SSL renegotiation or not, and if in that 2nd handhsake there is a
> certificate request from the server.
> * These configs won't work when TLS1.3 arrives because there is no
> renegotiation.

Why would there be a need for renegotiation? In my scenario SSL is
always used.
If the client has a cert installed, the cert should be used. Otherwise
the standard/basic auth should be used (still over SSL).

What is troubling is the fact that it works in a virtual server context,
but not in the directory context.

There are configurations available that either allow you to use a cert
or a basic (or 3rd party) auth mechanism. And I'm using them in my
virtual server context, but now I want it to work in the directory
context as well. It is in the documentation after all.

But it is not working and I would like to know why.

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek
lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


Re: bug with SSLVerifyClient?

2016-11-23 Thread Eric Covener
On Wed, Nov 23, 2016 at 1:30 PM, Helmut K. C. Tessarek
 wrote:
>
> Why would there be a need for renegotiation? In my scenario SSL is
> always used.
> If the client has a cert installed, the cert should be used. Otherwise
> the standard/basic auth should be used (still over SSL).

In your desired config, the initial handshake happens with
SSLVerifyClient=none, so no client certificate is requested so none
can be sent by the client.
The initial handshake completes, then a HTTP request is received that
maps to /dir
Now Apache has to honor your  section, and a change to
SSLVerifyClient from none to optional requires a new handshake to
request a client certificate.


Re: bug with SSLVerifyClient?

2016-11-23 Thread Helmut K. C. Tessarek
On 2016-11-23 13:43, Eric Covener wrote:
> In your desired config, the initial handshake happens with
> SSLVerifyClient=none, so no client certificate is requested so none
> can be sent by the client.
> The initial handshake completes, then a HTTP request is received that
> maps to /dir
> Now Apache has to honor your  section, and a change to
> SSLVerifyClient from none to optional requires a new handshake to
> request a client certificate.

I see, thank you for the explanation. It still does not explain why it
doesn't work though. It should, right? At least according to the
documentation.

But you also mentioned that this scenario won't work with TLS 1.3. Does
this mean you can only have either an auth schema (user/password auth)
or a client cert with TLS 1.3, but not both at the same time? Since when
is functionality removed in new protocols?

Cheers,
 K. C.

-- 
regards Helmut K. C. Tessarek
lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


Re: bug with SSLVerifyClient?

2016-11-23 Thread Ruediger Pluem


On 11/23/2016 07:55 PM, Helmut K. C. Tessarek wrote:
> On 2016-11-23 13:43, Eric Covener wrote:
>> In your desired config, the initial handshake happens with
>> SSLVerifyClient=none, so no client certificate is requested so none
>> can be sent by the client.
>> The initial handshake completes, then a HTTP request is received that
>> maps to /dir
>> Now Apache has to honor your  section, and a change to
>> SSLVerifyClient from none to optional requires a new handshake to
>> request a client certificate.
> 
> I see, thank you for the explanation. It still does not explain why it
> doesn't work though. It should, right? At least according to the
> documentation.
> 
> But you also mentioned that this scenario won't work with TLS 1.3. Does
> this mean you can only have either an auth schema (user/password auth)
> or a client cert with TLS 1.3, but not both at the same time? Since when

You can still have that if you configure SSLVerify on virtual server layer, but 
not
on directory level.

> is functionality removed in new protocols?

As far as I understand renegotiation has (and definitely had in the past) 
serious security
issues. Hence it is removed.

Regards

Rüdiger


Re: bug with SSLVerifyClient?

2016-11-23 Thread Helmut K. C. Tessarek
On 2016-11-23 14:30, Ruediger Pluem wrote:
> You can still have that if you configure SSLVerify on virtual server
> layer,

Right, no renegotiation necessary in that case. Makes sense, thanks.

> but not on directory level.

Well, apparently I can't have that now either. :-(

>> is functionality removed in new protocols?
> As far as I understand renegotiation has (and definitely had in the
> past) serious security issues. Hence it is removed.

Ok, just out of curiosity: was the design flawed or the implementation?

Cheers,
 K. C.


-- 
regards Helmut K. C. Tessarek
lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


Re: bug with SSLVerifyClient?

2016-11-24 Thread Helmut K. C. Tessarek
On 2016-11-24 03:33, Plüm, Rüdiger, Vodafone Group wrote:
> I agree that it should work with current TLS versions, but I have current no 
> time to
> dig further.

At least I know now that I'm not off when I say: it should work.

That's why I asked here on the dev list, because people who know the
code might have an idea where the problem is right away.

Maybe somebody else will be able to answer my question or tell me how to
fix this.

> As it is changed in the SPEC it is a design problem, otherwise just the 
> software
> implementing it would need to be fixed.

That was my point actually. Fixing the design makes no sense, if the
implementation sucks. It's not the first time though that just all
implementations are at a fault. That's why I asked, I just didn't know.

Cheers,
 K. C.

-- 
regards Helmut K. C. Tessarek
lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/