WSGIAccessScript and SSL Environmental Variables

[Jason Connor]

Hi All,

I'm writing an access script for a directory hierarchy that requires
x509 certs to access. The certs contain multiple oid entries that
correspond to the directories the client has access to. As these certs
are issued and revoked at runtime, so I want the oid checking to be
dynamic.

I've added a wsgi script with the WSGIAccessScript directive that
pulls the SSL cert and checks the oid entries against request uri.
I've also added the SSLOptions +StdEnvVars +ExportCertData directive.
However the SSL environmental variables are not passed into my access
script.

Am I missing something?

[Graham Dumpleton]

No. Sorry, been meaning to document this in a wiki page but haven't
got around to doing it.

Use attached C extension module and follow instructions below.

To build:

1. Modify setup.py to change as necessary paths to include directories
and Apache Runtime Libraries (apr/aputil). Change version is APR
libraries if needed.

2. Run:

python setup.py build
python setup.py install

3. In code use:

import ssl_engine_vars

# Get Python CObject reference to Apache request object.

request_rec = environ['apache.request_rec']

# Are we running under SSL.

if ssl_engine_vars.is_https(request_rec):
...

# Lookup SSL variables.

organisation = ssl_engine_vars.var_lookup(request_rec, "SSL_SERVER_I_DN_O")

If variable isn't set, the mod_ssl returns empty string.

4. In Apache configuration, ensure you have set:

WSGIPassApacheRequest On

Not necessary to have:

SSLOptions StdEnvVars

This mechanism can be used for access, authentication, authorisation hooks.

Can only be used in content handler, ie., WSGI application, if the
WSGI application is running in embedded mode.

Graham

[Graham Dumpleton]

I now have a question for those out there who understand what
information is in client SSL certificates.

Having to use an extension like this to access this stuff is a pain.
The alternative is for mod_wsgi to simply provide in the WSGI
environment some permanent function call backs under the keys:

mod_ssl.is_https
mod_ssl.lookup_var

My question is, if availability of these is always present, including
in the WSGI application itself, does it expose sensitive information
to a WSGI application which you might not want to expose.

Consider for example where HTTPS was required to access site, but the
site was being used to host arbitrary users code in a type of shared
hosting situation. Would those users be able to get to stuff they
shouldn't.

If there is that risk, then could look at a directive to enable supply
of these instead.

Graham

[Mark Rees]

Imho, I do not think the additional information provided by a verified certificate ssl connection would expose any information that shouldn't be seen. In the end, the administrator of the apache location/directory can via apache ssl directives specify if client cert verification is required for the location so could limit visibility that way if required. Also it may be worthwhile using the apache CGI env as a comparison, if you have ssl cert required set in a CGI location all the server and client SSL variables are available in the environment.

All that being said, in the end it does not bother me that we have to import a module to get access to the variables. It is working well at a number of our production sites. So thanks again Graham for creating this extension when I raised my own ssl env issue with you at PyCon AU.

Regards

Mark

--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To post to this group, send email to mod...@googlegroups.com.
To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.

[Graham Dumpleton]

On 14 July 2010 11:29, Mark Rees <mark.jo...@gmail.com> wrote:
> Imho, I do not think the additional information provided by
> a verified certificate ssl connection would expose any information that
> shouldn't be seen. In the end, the administrator of the apache
> location/directory can via apache ssl directives specify if client cert
> verification is required for the location so could limit visibility that way
> if required. Also it may be worthwhile using the apache CGI env as a
> comparison, if you have ssl cert required set in a CGI location all the
> server and client SSL variables are available in the environment.

Only if you have:

SSLOptions +StdEnvVars

so for mod_ssl at least, that CGI environment populated is optional.

> All that being said, in the end it does not bother me that we have to import
> a module to get access to the variables. It is working well at a number of
> our production sites. So thanks again Graham for creating this extension
> when I raised my own ssl env issue with you at PyCon AU.

So it made it to production now. That is good to hear. :-)

Graham

[Gelonida]

Hi Graham,

What's the advantage of the plugin over using the apache option:
SSLOptions +StdEnvVars

Currently I'm using +StdEnvVars as you suggested in the answer to my post
"I would like to get client certificate info in a mod_wsgi"

[Graham Dumpleton]

On 14 July 2010 21:10, Gelonida <gelo...@gmail.com> wrote:
> Hi Graham,
>
>
> What's the advantage of the plugin over using the apache option:
> SSLOptions +StdEnvVars

You cant use StdEnvVars for access, authentication or authorisation
providers of mod_wsgi. This is because the variables get populated in
an Apache phase after those are called. What the plugin does is giving
you access to the proper APIs rather than the view created by
StdEnvVars to satisfy stuff that uses CGI environment.

Graham

[Gelonida]

Graham Dumpleton wrote:
> On 14 July 2010 21:10, Gelonida <gelo...@gmail.com> wrote:
>> Hi Graham,
>>
>>
>> What's the advantage of the plugin over using the apache option:
>> SSLOptions +StdEnvVars
>
> You cant use StdEnvVars for access, authentication or authorisation
> providers of mod_wsgi. This is because the variables get populated in
> an Apache phase after those are called. What the plugin does is giving
> you access to the proper APIs rather than the view created by
> StdEnvVars to satisfy stuff that uses CGI environment.
>

Thanks for the explanation