Roy,
You are right, in your case it's not a good idea to authenticate at the reverse proxy level. We should find a secure solution to access your internal application and keep your internal authentication with X509 certs.
With my best knowledge, I don't know a transparent "reverse proxy"solution ? Maybe it doesn't exist ?
The solution I see for this case will be using VPN technology.
Maybe you can use a tunneling solution with SSL or SSH (SSH v3 now support PKI). Or you can use standard IPSEC software. But if we use VPN technology, the main disavantage is that we need to install a software client.
In my point of view I prefere the "reverse proxy" solution because we don't need to install a client and is easier to use and more "Glamour"...
If somebody has an other solution, it will be nice .
Sylvain
--------------------------------------------------------------------------------------------------------
Sylvain Maret
Senior Security Engineer
e-Xpert Solutions SA
Route de Pr�-Marais 29
1233 Bernex / Geneva
Switzerland
Tel: +41 22 727 05 55
Fax: +41 22 727 05 50
Mail: [EMAIL PROTECTED]
| "Roy Preece" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 14.07.2001 00:41
|
To: <[EMAIL PROTECTED]> cc: Subject: RE: Reverse Proxy SSL |
hmmmmm,
Thanks Sylvain, but the perl scripts on my internal web server check cert details like issuer, common_name and expiry date before continuing. This is just additional security for permission to continue ie: If common name is in a db and issuer is myCA then continue - else - Nasty Msg. I would have to run these perl scripts on the external server for this to work. I am not comfortable with that idea.
Therefore, I still need the following ;
https client-------->Tunnel reverse proxy server----------->https internal server with client Auth (X.509).
Besides the users like it when the page presents prefilled web forms with details from their certificate mapped to a user db :-)
You see, I have been running this system internally for quite some time, but now I need to open it up to some external users. The simplest secure way would be to reverse proxy SSL transparently. Is there really no-one else who needs to do this?
Feeling like the odd one out again,
Roy Preece
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
Sent: Friday, July 13, 2001 10:14 PM
To: [EMAIL PROTECTED]
Subject: RE: Reverse Proxy SSL
What you can do is:
https ---------> reverse proxy SSL with Client authentication (X509) -------------------------------->https to your internal web server (192.168.x.y) as exemple
In this case you authenticate on the reverse proxy with your personal cert and the reverse proxy get the internal content with https (SSL)
proxypass / https://172.20.1.10:444/
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
SSLVerifyClient require
SSLVerifyDepth 10
It work on my side.
Sylvain
--------------------------------------------------------------------------------------------------------
Sylvain Maret
Senior Security Engineer
e-Xpert Solutions SA
Route de Pr�-Marais 29
1233 Bernex / Geneva
Switzerland
Tel: +41 22 727 05 55
Fax: +41 22 727 05 50
Mail: [EMAIL PROTECTED]
| "Roy Preece" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 13.07.2001 14:02 | To: <[EMAIL PROTECTED]> cc: Subject: RE: Reverse Proxy SSL |
Unfortunately, it seems that the answer is.....................................
#1. Nobody seems to have successfully reverse proxied to a https server on a private (192.168) network
https-------->Straight thru proxy---------->https cert authentication + (perl $ENV{'SSL_CLIENT_S_DN_CN'} stuff.)
I will look at implementing the following less secure method.
https-------->Authenticating Proxy + (perl $ENV{'SSL_CLIENT_S_DN_CN'} stuff.)---------->Plain old http + NFS.
OR
VPN
Cheers,
Roy Preece
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Roy Preece
Sent: Wednesday, July 11, 2001 9:22 PM
To: [EMAIL PROTECTED]
Subject: Reverse Proxy SSL
OK, from the lack of response to my previous email (SSLClient Browser <--> Apache Proxypassreverse <--> https://192.168.xxx.xxx) I can deduce one of two cases is true.
1. Nobody has successfully achieved a reverse proxy of SSL in the way I am describing, (Hard to believe)
or...........
2. You are really sick of this question.(Sorry)
If you chose 2, I have read through all of the mail archives on this list and others with regard to reverse proxying https. The most popular config seems to be to run SSL between the browser and the proxy server and then plain old http between the proxy server and the backend private servers. However, I want the client browser to use a cert to authenticate directly on the back end server on a private network, therefore I just want the reverse proxy to pass the encrypted traffic back and forth.
Is this possible..................How? Tips and pointers greatly appreciated.
TIA,
Roy Preece
-----------------------------------------------------------------------------------------------
DISCLAIMER
This email and any files transmitted with it, including replies
and forwarded copies (which may contain alterations)
subsequently transmitted from the Company, are confidential
and solely for the use of the intended recipient. It may contain
material protected by attorney-client privilege. The contents
do not represent the opinion of e-Xpert Solutions SA except
to the extent that it relates to their official business.
If you are not the intended recipient or the person responsible
for delivering to the intended recipient, be advised that you
have received this email in error and that any use is strictly
prohibited. If you are not the intended recipient, please advise
the sender by return e-mail, then delete this message and any
attachments.
e-Xpert Solutions SA: [EMAIL PROTECTED]
-----------------------------------------------------------------------------------------------
DISCLAIMER
This email and any files transmitted with it, including replies
and forwarded copies (which may contain alterations)
subsequently transmitted from the Company, are confidential
and solely for the use of the intended recipient. It may contain
material protected by attorney-client privilege. The contents
do not represent the opinion of e-Xpert Solutions SA except
to the extent that it relates to their official business.
If you are not the intended recipient or the person responsible
for delivering to the intended recipient, be advised that you
have received this email in error and that any use is strictly
prohibited. If you are not the intended recipient, please advise
the sender by return e-mail, then delete this message and any
attachments.
e-Xpert Solutions SA: [EMAIL PROTECTED]
