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-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 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 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 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 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-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: svn commit: r1770771 - /httpd/httpd/trunk/docs/manual/mod/mpm_common.xml

2016-11-23 Thread Daniel 
Hello Luca,

note that "scoreboard is full" is caused for not being enough
maxsparethreads available and event being constantly reclaming threads, so
for the case you mention, the comment should rather go on MaxSpareThreads
rather than ServerLimit.

2016-11-23 11:53 GMT+01:00 Luca Toscano :

> Hi Stefan,
>
> 2016-11-21 23:13 GMT+01:00 :
>
>> Author: sf
>> Date: Mon Nov 21 22:13:05 2016
>> New Revision: 1770771
>>
>> URL: http://svn.apache.org/viewvc?rev=1770771=rev
>> Log:
>> Describe new behavior of ServerLimit
>>
>> This has changed a bit after the fix for PR 53555. Better wording is
>> welcome.
>>
>>
> first of all thanks a lot for this big effort! I am still reading your
> code and trying to understand how it works in detail, but I have some
> suggestions on how to improve the docs:
>
> - in http://httpd.apache.org/docs/trunk/mod/mpm_common.html#serverlimit
> it would be great to have a little note section after the "With event,
> increase this directive if the process number.." with a little background
> about why event is special. Even something trivial as mentioning that
> everything originated from reports of the "scoreboard is full, not at
> MaxRequestWorkers" error could direct people from the search engines to the
> httpd manual pages rather than random blogs.
> - Some summaries and explanation that you wrote like
> https://bz.apache.org/bugzilla/show_bug.cgi?id=53555#c39 (I know that
> something has been changed in the meantime) would be really great to be
> captured somewhere, maybe in https://httpd.apache.org/
> docs/trunk/mod/event.html.
>
> I am happy to help with some work (even after the votes) but since you
> know really well the code there is a very high chance that the
> documentation will be more accurate and reliable :)
>
> Thanks!
>
> Luca
>
>
>
>


-- 
*Daniel Ferradal*
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

Re: svn commit: r1770771 - /httpd/httpd/trunk/docs/manual/mod/mpm_common.xml

2016-11-23 Thread Luca Toscano 
Hi Stefan,

2016-11-21 23:13 GMT+01:00 :

> Author: sf
> Date: Mon Nov 21 22:13:05 2016
> New Revision: 1770771
>
> URL: http://svn.apache.org/viewvc?rev=1770771=rev
> Log:
> Describe new behavior of ServerLimit
>
> This has changed a bit after the fix for PR 53555. Better wording is
> welcome.
>
>
first of all thanks a lot for this big effort! I am still reading your code
and trying to understand how it works in detail, but I have some
suggestions on how to improve the docs:

- in http://httpd.apache.org/docs/trunk/mod/mpm_common.html#serverlimit it
would be great to have a little note section after the "With event,
increase this directive if the process number.." with a little background
about why event is special. Even something trivial as mentioning that
everything originated from reports of the "scoreboard is full, not at
MaxRequestWorkers" error could direct people from the search engines to the
httpd manual pages rather than random blogs.
- Some summaries and explanation that you wrote like
https://bz.apache.org/bugzilla/show_bug.cgi?id=53555#c39 (I know that
something has been changed in the meantime) would be really great to be
captured somewhere, maybe in
https://httpd.apache.org/docs/trunk/mod/event.html.

I am happy to help with some work (even after the votes) but since you know
really well the code there is a very high chance that the documentation
will be more accurate and reliable :)

Thanks!

Luca