Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
In-Reply-To: <3F30B5E1.5040506@netcologne.de>
To: "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>
MIME-Version: 1.0
Subject: Re: AW: Proxied SSL connection
From: "Roland Weber" <ROLWEBER@de.ibm.com>
Message-ID: 
 <OF677AB88F.1CBEF1D4-ONC1256D7A.002D100F-C1256D7A.00324A15@de.ibm.com>
Date: Wed, 6 Aug 2003 11:08:08 +0200
Content-Type: multipart/alternative;
 boundary="=_alternative 002E696DC1256D7A_="

--=_alternative 002E696DC1256D7A_=
Content-Type: text/plain; charset="US-ASCII"

Hello Christian,

It depends on what you want to do. SSL is meant to
establish a secure end-to-end connection, and the both
ends are *usually* the client and the backend server.

I wouldn't rule out the possibility to connect to the
proxy using SSL. But this will only secure the connection
to the proxy, not to the backend server. It just doesn't
make sense to secure the first hop of the connection
and let the secured data be transferred unprotected
from there on.

You could use the secure connection to the proxy to
establish a tunnel to the backend server and run SSL
through that tunnel as well. But this would mean the
client has to encrypt data twice, without adding to
the security of the overall connection, since the SSL
tunnel to the backend alone will protect the data all
the way.

I think Oleg is right calling it an *unusual* setup if
the SSL security ends at the proxy.

regards,
  Roland


[...]

AFAIK, what Oleg describes is not only the conventional, but the 
official (and possibly only) way to do SSL through a proxy. I recently 
read up on the details (e.g., see 
http://muffin.doit.org/docs/rfc/tunneling_ssl.html), and found that 
tunneling is probably the only way to do it.

regards
Christian


--=_alternative 002E696DC1256D7A_=--