Dne 18.1.2011 18:12, g f napsal(a):Hi G40,
Hey Martin,
common access cards are smart cards that allow a user to authenticate to a domain using just the card(inserted into the card reader) and a pin number.
ÂThe directive
*/SSLVerifyClient require/*
requires all https access utilize a smart card. no smart card, no access.
to be precise, the "SSLVerifyClient require" does not requires that all https access utilizes a smart card,
it requires that the HTTP client presents a certificate. The certificate may be stored in many ways
on the computer with the HTTP client, for example directly in the browser (like in Firefox), in the MS-Windows
system-wide certificate store, or in some PKCS11 device like your cryptographic smart card.
So the "SSLVerifyClient require" is not enough to ensure that a smart card is used, but
if a user has a smart card configured properly, it can be used. A user still have the option
to provide the certificate from some other source than a smart card. This may or may not affect your security.
*/SSLVerifyClient optional
/*this seems to fix my issue. It prompts for the smart card for access but also allows the request (that comes from localhost) through.
Actually no, it does not fix the issue, it just hides it. "SSLVerifyClient optional" allows non-authenticated
access, so anybody without a certificate can now access your application !I see, it is the situation that I have guessed.
The proxy resides in www/cgi-bin
I am not a python person but I can better describe it in java terms (recall we use mod_jk to hand off to tomcat6):
user accesses /https://mydomain.com/*protected_app*/*_A*
protected_app requires data from some_other_protected_app using ajax and a pseudo proxy servlet
/https://mydomain.com/*protected_app_A*/pseudo_proxy_Servlet/ makes a URLConnection to (to avoid the _javascript_ cross site scripting error) to
/https://mydomain.com/*protected_app_B*/web-service/
Apache attempts to authenticate this request coming from
/https://mydomain.com/*protected_app_A*/pseudo_proxy_Servlet/ Â. To apache it appears as a request from localhost from user Java1.6(tomcat) and so authentication fails since apache is asking the
servlet for a cert and it does not have the client cert.
It creates a security hole, because now clients without certificate can access the application, as I have written above.
Setting
*/SSLVerifyClient optional/*
seems to fix the problem since the request from localhost java1.6(tomcat) is allowed since It no longer requires client certs.
What you actually need to do it to make sure that clients coming from outside present a certificate,
while internal calls from localhost do not.
So configure two virtual web servers, one for localhost and one for mydomain.com,
and use "SSLVerifyClient required" for mydomain.com and ""SSLVerifyClient none" for localhost. Something like
<VirtualHost 127.0.0.1:443>
ÂServerName localhost
ÂSSLEngine on
ÂSSLVerifyClient none
Â...
</VirtualHost>
<VirtualHost *:443>
ÂServerName mydomain.com
ÂSSLEngine on
ÂSSLVerifyClient required
Â...
</VirtualHost>You cannot forward certificates, because they do not work without their associated private keys.
As it is configured now, it works for me.
ÂI realize that the ideal solution would be to set /*SSLVerifyClient require*/ and configure apache to forward client certs to tomcat as well as the python proxy, which I am currently researching.
Cheers
Martin
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Supercomputing Center Brno       Martin Kuba
Institute of Computer Science  Âemail: makub@xxxxxxxxxxx
Masaryk University       http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ Â Â mobil: +420-603-533775
--------------------------------------------------------------
|