Martin, very nice! I will give that a shot. I appreciate your effort on this as well as others that have posted. Cheers! G40
On Wed, Jan 19, 2011 at 1:50 AM, Martin Kuba <ma...@ics.muni.cz> wrote: > Dne 18.1.2011 18:12, g f napsal(a): > > 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. >> > > Hi G40, > > 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 ! > > > 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. >> > > I see, it is the situation that I have guessed. > > > 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. >> > > It creates a security hole, because now clients without certificate can > access the application, as I have written above. > > 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> > > > > 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. >> > > You cannot forward certificates, because they do not work without their > associated private keys. > > Cheers > > Martin > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Supercomputing Center Brno Martin Kuba > Institute of Computer Science email: ma...@ics.muni.cz > Masaryk University > http://www.ics.muni.cz/~makub/<http://www.ics.muni.cz/%7Emakub/> > Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 > -------------------------------------------------------------- > >
