Perhaps the below whitepaper may offer some insight for you:
3.2) How does SSL work through (application level) firewalls,
gateways and proxy servers?
SSL was designed to provide security between client and server and
to avoid any kind of 3-way man-in-the-middle attack. Thus SSL cannot
be proxied through traditional application level firewalls (such as
the CERN proxy server) because SSL considers a proxy server to be a
middleman.
The simplest alternative to this problem is to use a packet
filtering firewall. You set it up to open a reserved and trusted
port for the SSL+HTTP or SSL+NNTP services (443 or 563 respectively)
allowing all traffic on those ports to be passed through
unrestricted. The risk with this solution is that an internal
attacker could attempt to use these trusted ports without using SSL
and there is no way for the firewall to know.
SSL also can work with gateways that support the SOCKS protocol, a
protocol independent proxy mechanism. SOCKS is a generic byte
forwarding gateway between client and server and generally works
at the socket level. If all you want is TCP/UDP restrictions based on
client IP or server IP, SOCKS works fine.
However, most non-SSL HTTP proxies work at the protocol level and
have the ability to understand header information related to the
protocol. This goes beyond SOCKS to allow the firewall administrator
to use the header information for filtering and/or monitoring the
traffic. Also, SOCKS does not offer the firewall administrator
enough information about the request to let it decide whether to
allow it and whether to log the request.
A more secure approach is to use a firewall that supports the SSL
Tunneling CONNECT extension method as described in the Internet
draft
<http://search.ietf.org/internet-drafts/
draft-luotonen-web-proxy-tunneling-01.txt>
In SSL Tunneling, the client initiates an SSL connection via normal
HTTP then handshakes and creates a secure connection to the server
via a byte-forwarding tunnel. The proxy has access to the
client-proxy request headers, but the session is encrypted. Once
the handshake occurs, the proxy acts just like a SOCKS gateway. This
allows the firewall to monitor the requests, but not the traffic.
The biggest difference between the two methods is that when using
SOCKS, DNS resolution is the responsibility of the client, whereas
when requests are forwarded through a proxy, DNS resolution is the
responsibility of the proxy.
The are three additional things that the SSL Tunneling mechanism
does with the proxy server that do not happen when using SOCKS:
* The client sends a "user agent" message (for example,
"Mozilla/3.0/Macintosh").
* The proxy can send to the client an authorization request
allowing the administrator to use passwords to control external
Internet access.
* The standard is more easily extensible. For example, the client
could, in theory, send the URL being requested (or anything
else) to the firewall. However, there is no standard to support
this behavior and as far as we know there are no products which
do it.
The Netscape Proxy Server supports the SSL Tunneling CONNECT
extension method for tunneling SSL, and the use of the proxy is
described in
<http://developer.netscape.com/docs/manuals/proxy/adminux/
encrypt.htm>
Another solution, also available using the Netscape Proxy Server, is
that the proxy server can spoof SSL on behalf of the internal client.
The proxy will initiate SSL between itself and other servers on the
Internet, but be unsecure inside the firewall between the proxy
server and the client.
This compromise means that client authentication is not possible;
only server authentication of the remote sites is available.
However, you gain the ability for client authentication between the
client and the proxy. The administrator must decide which is more
important, until such time as a better solution arises. The
description of this feature of the Netscape Proxy Server is at
<http://developer.netscape.com/docs/manuals/proxy/adminux/
encrypt.htm>
Reverse proxies are a solution for serving secure content inside
a firewall to outside clients. For the Netscape Proxy Server
this is described at
<http://developer.netscape.com/docs/manuals/proxy/adminux/
revpxy.htm>
It is possible for a proxy server to hold both client and server
keys for its internal clients. This allows SSL sessions to be
carried out twice: once between the client and proxy server, and
again between the proxy server and the secure server. Thus, the
proxy server can to listen in on the conversation without having the
private keys of external servers. Clearly this isn't reasonable for
the general internet, but it is a viable solution for corporate
requirements inside a firewall.
Netscape Proxy Server 3.5 supports this feature. It can be used as
described above, or simply to create a secure tunnel between sites
across an insecure network. This is really multiple sessions of SSL,
not an end-to-end secure connection.
This means that 3.5 has full SSL support as opposed to just SSL
tunneling. It can therefore do client authentication and serve
documents like a secure server, or request documents like an
SSL-enabled client. SSL doesn't allow recursive encryption, so by
using it this way you lose the transparency of the proxy and get
multiple segments of secure connections, rather than a single
end-to-end connection.
-----Original Message-----
From: Bryan Hart [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 05, 2001 3:41 PM
To: [EMAIL PROTECTED]
Subject: Re: How to use a proxy with Net:SSLeay
Not possible currently but will appear in v.18 which should be out very
soon...
Bryan
----- Original Message -----
From: "Stephen DiRose" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 05, 2001 5:05 PM
Subject: How to use a proxy with Net:SSLeay
> Hey folks,
> Does anybody have an example using a proxy over ssl? Also, if you do,
which
> versions of the libraries are you using.
>
> Thanks!
> Steve
>
> please respond to me directly as I am not on this alias
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
