httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From g f <gfo...@gmail.com>
Subject Re: [users@httpd] SSL library error 1 in handshake
Date Wed, 19 Jan 2011 14:29:02 GMT
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 <makub@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: makub@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
> --------------------------------------------------------------
>
>

Mime
View raw message