At 07:05 PM 7/25/2001 +0200, Issac Goldstand wrote:
> > 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.
> > 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).
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.
> Issac
>
> > At 03:26 PM 7/25/2001 +0200, Issac Goldstand wrote:
> > >I am trying to make a back-end mod_perl/mod_ssl server. The front-end
> > >server that is currently in place is doing a great job forwarding normal
> > >requests to the back-end, but it is not forwarding SSL. Now, the
>front-end
> > >server does not understand SSL, itself. What I'm doing is trying to
>force
> > >the entire VirtualHost listening on port 443 to an IP on a private subnet
>on
> > >an obscure port (what I do for all the back-end servers. There are
>actually
> > >3 of them doing various things). But it won't work. The strange thing
>is
> > >that if I go to http://mysite:443/ I get the default Apache "It Worked"
> > >page, but https://mysite/ generates an error saying that the front end
> > >cannot understand, which seems to be pointing at the fact that it's not
> > >forwarding ANYTHING to the back-end server...
> > >
> > >Stas & Eric: This situation is mentioned in your book, but in nowhere
>enough
> > >detail. IMHO, that segment of the book (near the end of chapter "Server
> > >Setup Strategies for the Best Performance") should be redone in better
> > >detail to explain forwarding SSL to the back-end server.
> > >
> > > Issac
> > >
> > >Internet is a wonderful mechanism for making a fool of
> > >yourself in front of a very large audience.
> > > --Anonymous
> > >
> > >Moving the mouse won't get you into trouble... Clicking it might.
> > > --Anonymous
> > >
> > >PGP Key 0xE0FA561B - Fingerprint:
> > >7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
> >
> > __________________________________________________
> > Gunther Birznieks ([EMAIL PROTECTED])
> > eXtropia - The Open Web Technology Company
> > http://www.eXtropia.com/
> >
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
