Re: bug with SSLVerifyClient?
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?
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?
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?
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?
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?
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?
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?
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. */