[users@httpd] RE: Apache SSL Feature - Please Advise (PATCH for mod_ssl)

["TAYLOR, TIM (CONTRACTOR)" <TI...@DFAS.MIL>]

Ben, 
  I have attached three patch versions. Writing the code is not nearly as difficult as figuring out the best way to go.

Patch 1 (proof of concept)
source: ssl_engine_init.c, ssl_engine_kernel.c
I really don't expect this one to go simply because I merely changed the meaning of the existing directives to what I had initially assumed when I bumped into the limitation. I simply force SSLCACertificateFile to be used for the cert store load for client authentication only and force SSLCACertificatePath to be used for the client_CA STACK_OF(X509_NAME) only. This patch requires both directives be configured if client verify is enabled. Obviously, this one is not downward compatible with existing configurations.

Patch 2 (special use case)
source: ssl_engine_init.c, ssl_engine_kernel.c
Again, no new directives but if only one of the SSLCACertificate* directives are specified, mod_ssl will behave as it did before (load certs into the cert store and load names into the client_CA stack list). However, if both are specified it behaves like patch 1. This will I think preserve downward compatibility with most configs. I like this one because intuitively it is what I would expect. Wasn't the hashing of CA names for symbolic links intended to expedite the creation of the opaque DistinguishedName list of the handshake CertificateRequest message (RFC2246)? However, I realize it is not 100% downward compatible.

Patch 3 (new config)
source: ssl_engine_init.c, ssl_engine_kernel.c, ssl_engine_config.c, mod_ssl.c, mod_ssl.h
Two new directives, SSLCADNRequestFile and SSLCADNRequestPath. I figured I might as well give the same flexibility. If the new directives are not specified old behavior continues. If either or both SSLCADNRequest* is configured, they would configure the client_CA stack ONLY and any SSLCACertificate* directive(s) will be used for the cert store load ONLY. The benefit here is complete downward compatibility. No requirement to use the new directives and no change in meaning for the use of existing directives (except when new is used too).

I look for your recommendation, Ben, and solicit comments of those interested. Please note this capability is important to us in the U.S. Department of Defense. It saves CRL bandwidth and processing, as well as, eliminates user questions and confusion for thousands.

regards,
tt
317-510-5987

-----Original Message-----
From: Ben Laurie [mailto:ben@algroup.co.uk]
Sent: Sunday, November 21, 2004 10:01 AM
To: TAYLOR, TIM (CONTRACTOR)
Subject: Re: Apache SSL Feature - Please Advise


TAYLOR, TIM (CONTRACTOR) wrote:
> Hello Ben.
> 
> I have a situation where I believe Apache is limiting an SSL
> capability that I need to be able to use. I posted the following on
> the apache user mail list but got no response. I want to know if I
> should look into making the change myself and present it as a patch,
> just open a bug report or is there some other means for requesting a
> new feature that won't evoke derisive laughter.
> 
> My post to [users@httpd]: First of all, I have already asked on the
> OpenSSL and was referred to Apache, so here goes.
> 
> Premise 1 SSL/TLS Handshake has a certificateRequest message (for
> client authentication) that will prompt the browser for a
> certificate. Now the Draft (SSL)/RFC (TLS) state that in the
> certificateRequest the server may include a list of acceptable CA's.
> 
> 
> Premise 2 After receiving a certificate from the client in response
> to a certificate request SSL/TLS will perform validation (not out of
> date, not a forgery, and, if configured, not revoked). During
> validation a trust list of CAs is consulted to validate the
> certificate chain.
> 
> My Problem My organization has a Root CA which has subordinate
> (intermediate) CAs of two different classes. I only want to accept
> certificates from one of the subordinate CA classes. Mind you that
> both classes issue RSA-signing certificates. This causes my end
> users, who have a certificate from each of the two subordinate CA
> classes, to get prompted to pick a certificate to authenticate with.
> I have good reasons for needing to eliminate the selection prompt
> (user confusion, CRL bandwidth use, etc). Using functionality of
> premise 1, I can specify only (let's say) Class A  CAs in the
> certificateRequest message. If don't include the root CA in that
> list, I see the browser response I want, only Class A Certificates
> are eligible (and presented to user) for use. However, It won't
> validate because of the lack of a root CA. If I include the Root CA
> in the premise 1 list with the Class A CA's, the user is presented
> with both Class A and Class B certificates, obviously because both
> are valid for that Root CA trust anchor. :-(  That's right, darned if
> I do and darned if I don't.
> 
> Apache SSL Configuration Limitation SSLCACertificateFile and
> SSLCACertificatePath are documented as interchangeable. I have found
> no configuration of directives that will give me separate control of
> the certificateRequest (premise 1) and the validation trust list
> (premise 2). They are treated as one and the same and I recognize
> that for most that is fine.
> 
> Openssl Functionality Openssl development has stated that openssl
> does not force them to be the same.
> 
> Therefore, I am led to believe that apache is using the same list for
> both (premise) purposes. Is this an opportunity for a new Apache SSL
> directive? I am thinking of a new directive for trust anchors only.
> The code could be changed to look for the setting for this directive
> at path validation time, and if not null, load any CAs defined there
> (file/path) into the context cert store.This would be a fairly simple
> change and would keep backward compatibility with existing SSL
> configurations.
> 
> How would you recommend I proceed?

Apologies for the delay, I've been travelling.

If you can write the code, then by all means send me a patch.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: [users@httpd] RE: Apache SSL Feature - Please Advise (PATCH for mod_ssl)

[Joe Orton <jo...@redhat.com>]

On Fri, Dec 10, 2004 at 01:24:29PM -0500, TAYLOR, TIM (CONTRACTOR) wrote:
>   I have attached three patch versions. Writing the code is not nearly
>   as difficult as figuring out the best way to go.

users@httpd is not the best place to discuss this; I'm following up to
dev@httpd.apache.org.  (An alternative way to get patches attention is
to put them in bugzilla, http://issues.apache.org/bugzilla/)

...
> Patch 3 (new config) source: ssl_engine_init.c, ssl_engine_kernel.c,
> ssl_engine_config.c, mod_ssl.c, mod_ssl.h Two new directives,
> SSLCADNRequestFile and SSLCADNRequestPath. I figured I might as well
> give the same flexibility. If the new directives are not specified old
> behavior continues. If either or both SSLCADNRequest* is configured,
> they would configure the client_CA stack ONLY and any
> SSLCACertificate* directive(s) will be used for the cert store load
> ONLY. The benefit here is complete downward compatibility. No
> requirement to use the new directives and no change in meaning for the
> use of existing directives (except when new is used too).

Neither of the backwards-incompatible solutions look particularly
desirable.  I can't think of a better way than Patch 3 really.  It would
be nice if there was some way of just picking out the DNs by name from
the already configured SSLCACertificate* chain e.g.

   SSLCADNRequest /C=US/O=Blah/OU=...

to avoid the chance of having a mismatch where the client is sent the
wrong DNS, but you get into syntax issues and I don't know if OpenSSL
even supports parsing dnames like that.

I don't think there's any need for the SSLCAProxyDN* you added in your
patch, there is no equivalent point where the client sends DNs, but
otherwise it looks OK.  Could you resubmit the patch without that bit?

Regards,

joe