Re: reverse proxying SSL with open source software

On Sun, 7 Nov 1999, Paul Boyer wrote:

PB} Thanks for the responses.
PB}
PB} I got several responses telling that decrypting SSL on a proxy would be
PB} a lack of security, making it possible to someone "in the middle" to
PB} snoop everything that passes through.
PB} My need was more making a HTTP server reachable by HTTPS only, via a
PB} preverse proxy handling the SSL part, and passing back to a HTTP server.

I developed this capability for one of my customers. While I had thought,
initially, of using Squid; it quickly became clear that the answer to the
problem involved a different approach. The basic processing flow is shown
below.

        WWW Client <-- HTTPS --> Proxy Server <-- HTTP --> WWW Server

My approach also works using HTTPS between the Proxy and WWW servers with
one significant caveat. The WWW Server cannot employ discretionary access
controls on the WWW content. If discretionary access controls are needed,
HTTP must be used between the Proxy and WWW servers to avoid the "Man in
the Middle" problem.

PB} but Yes, it is true. It _IS_ a security problem of SSL itself, also know
PB} as the "Man in the middle" attack. The only possible way to avoid it
PB} would be that the client could authenticate the server's key, and make
PB} sure it is not an unknown proxy's key that would be untrusted.
PB}
PB} There is nothing new in this being a vulnerability. For me, it is a
PB} feature of HTTPS. There is some cases where this could be a usefull
PB} feature :
PB}
PB} * Add SSL to some web server that can't properly handle it
PB} typically, if you want to make some odd web server reachable from the
PB} Internet, you can handle authentication with your firewall, but would
PB} like to get the whole thing encrypted. That kind of a proxy would be a
PB} great help.

The common Proxy Server approach solves this problem nicely and avoids the
associated "political" and "budgetary" problems that can arise. Have you
ever tried to tell someone that they must throw their Web development
effort away and start over because they chose the wrong server software?

PB} * Enforce the encryption used.
PB} If you have a weak 40bit SSL module on a Web server and want to do
PB} 128bit SSL, that would be a great help too.

Using "virtual hosting" technologies on the Proxy server, you can tailor
the cypher algorithms that are negotiated for each WWW server. A common
Proxy server allows you to address some cypher negotiation problems that
are browser specific, i.e. accepting 40-bit RC4-MD5 during the initial
negotiation and then forcing 128-bit RC4-MD5 to be negotiated when the
content is accessed. (Only way to get some versions of Internet Exploder
to work as desired.)

PB} * Performance :
PB} You can have a farm of web servers doing primarily HTTP, but each can do
PB} some HTTPS for some few pages. They are all using load balancing, etc.
PB} You can simply plug a reverse proxy that handles the HTTPS thing, with
PB} only one single key, and let the web servers do HTTP to the proxy.

Although the approach that I took supports the creation of a common view
to the external world, I haven't implemented it. The customer wanted a
"transparent" solution. A laptop used in the campus environment had to
have all its bookmarks work when taken to the field. The only difference
between the environments was the encryption of the data as it moved across
the Internet and authentication of the user when in the field.

PB} * Content-filtering :
PB} typically Anti-virus could be effective on HTTPS downloads, protecting a
PB} company's Internet downloads. Privacy concerns are then ruleds by ethic
PB} and security policies. That last use is more controversial because it is
PB} on the client side, not operated by the Web server owner...

Beyond discretionary access controls based on the authenticated user, my
approach doesn't support content filtering.

PB} There is also a "Bad Thing(tm)" that can be done using this: putting a
PB} reverse https/https proxy in the middle of some innocent E-commerce
PB} connections, and record some sensitive information. This already exist
PB} for sure, I never though someting was doable without soon discovering
PB} someone did it before ;
PB} If it is a bad guy doing it, it is not open source.
PB}
PB} HTTPS is _LOW_ protection, for sure, and that can be usefull. I want to
PB} use this feature.
PB} I also would be _HAPPY_ to welcome a more robust security for privacy,
PB} and I am thinking in some possibilities that I need to test, but it is
PB} an other point.
PB}
PB} >From what Jeffrey wrote, it seems clearer the proper solution is more on
PB} the Apache side than the Squid one, so may be this post should go to an
PB} other list (any suggestions ?) but I can't beleive this has not yet been
PB} done on Squid and/or Apache, since it _IS_ featured on Netscape proxy
PB} AND MS-Proxy.

I bet you've been reading Microsoft's marketing blurbs. Their technical
staff was far too interested in our solution to the problem when a
colleague let slip what we were doing at a security conference in Redmond
in January. :-)

                             Merton Campbell Crockett
+--------------------------------------------------------------------------+
| Manager, Network Operations & Services | Chief Network/Security Engineer |
| General Dynamics Electronic Systems | Naval Surface Warfare Center |
| Intelligence Systems Organization | Port Hueneme Division |
| Thousand Oaks, CA | Port Hueneme, CA |
+--------------------------------------------------------------------------+
Received on Sun Nov 07 1999 - 12:25:57 MST