> > > The front end server must be configured to understand SSL. Otherwise,
how
> > > else can the HTTP request be pulled apart (decrypted) to understand
that
> >it
> > > has to be forwarded to the backend server.
> >
> >2 words: dumb proxy. The request doesn't need to be pulled apart by the
> >front-end server in this case. The entire virtualhost is supposed to be
> >tunneled directly to the back-end server. That's what I'm trying to
figure
> >out how to do...
>
> I see. I don't know if that will work. The connect header is a special
> proxy feature to allow a proxy to just pass through all the TCP level
> packets instead of opening a separate SSL client connection. But from a
> reverse proxy perspective, I am not sure that mod_proxy is automatically
> given this special header by the browser as it might if you configured IE
> or Netscape to use a physical proxy server.
>
> But it definitely won't work based on the HTTP Hostname parameter because
> SSL has to be established before any other HTTP header other than the
weird
> connect one is decoded.
I know :(
> > > If you configure the back-end server to understand SSL, that's OK, but
> > > beware that all mod_proxy is doing is establishing one SSL connection
from
> > > browser to mod_proxy and then a brand new SSL connection from
mod_proxy to
> > > the backend server. 2 separate SSL sessions because SSL cannot (ie
> > > inconvenient to) be man-in-the-middled.
> >
> >I know that. The key is (and must be) on the back-end server. Which is
why
> >I'm trying to do it this way. The mod_perl book seemed to imply that
this
> >was possible, and I _know_ that mod_proxy is supposed to recognize
CONNECT
> >requests for this very purpose - it says so in the manual... I just
don't
> >know how to set it up properly...
> >
> > > It has some likelihood to also to be inefficient because I am not
entirely
> > > sure that mod_proxy is caching the SSL client session key that it
> >generates
> > > to connect to the back-end server as the browser normally does for the
> > > front end.
> >
> >I'm not even sure that mod_proxy can be it's own SSL client... The
> >documentation says it knows how to handle incoming CONNECTS, but I'm not
> >sure that it could make its own HTTPS request...
>
> If you try it, I think you will find that this works. If you compile in
> mod_ssl, mod_proxy can establish SSL connections to the back-end. The only
> thing you lose other than performance is the capability of passing a PKI
> certificate through the proxy (since decoding and establishing a new SSL
> connection would be considered a man-in-the-middle attack).
I see what you mean. I'm not dealing with client certs (yet), and I'm
thinking that when the system that I'm testing now goes production, it'll be
a front-end SSL, back-end non-SSL sorta deal... But that won't work for now
due to other security issues on the developments boxes...
> When you don't care about client certificates, it really doesn't matter
> that the reverse proxy is in the middle because the reverse proxy has the
> valid server certificate that your client is pre-programmed to understand
> is a valid certificate (eg from Verisign).
>
> Really, the cleanest way of doing what you want is to run the SSL engine
on
> the front-end and then proxy (convert) back the connection to the backend
> as HTTP. If you are using some authentication on the front-end (eg client
> certificates) there are modules which will allow you to take a USER_DN and
> pass it to the back-end server as an addition parameter (eg using
> mod_rewrite) or as another custom HTTP header.
I understand that. It's just not doable for this... In actuality, the
"back-end" server now is not REALLY back-end... The mod_perl server is
_behind_ that, so I'm really doing what you're suggesting already :)
However, information must still get to this "middle-level" server, and the
top level server certainly can't be trusted to decode sensitive
information...
Issac
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
