dmccrthy wrote:
Chris, André,
Many thanks. I hadn't considered either the MITM or Apache HTTPD angles.
The proxy idea occurred to me (sorry, I had a typo in my original mail and
that may not have been clear) but I agree it's messy.
Many thanks again, I just couldn't find anything that said yes it can be
done, or no it can't. A 3rd party feature request is a last resort so I had
to find out if there was some under-the-bonnet way. I really appreciate
your insights into this.
No problem.
For the sake of completeness, the only thing which made me cautious about using an
already-made proxy server such as Apache httpd, is the question of the DNS lookups (or
rather the "resolver" in the machine itself), if you play with the fake entry in the hosts
file.
Consider the following scenario :
- the webapp in question wants to connect to "server.company.com:8000"
- to divert this to your own local proxy, you define "server.company.com" in the local
hosts file as 127.0.0.1 (the localhost), and you set up a local httpd to listen on
127.0.0.1:8000, to do the proxying.
- thus when the webapp builds its TCP connection to "server.company.com:8000" - presumably
by looking up "server.company.com" first - it gets back (from the local OS's resolver) the
IP address 127.0.0.1, and builds a TCP connection to 127.0.0.1.
Then over that connection, it sends a HTTP 1.1 request including a "Host:
server.company.com" header.
So far so good.
- your httpd proxy catches this connection and the request.
- now the proxy has itself to build a connection to the "real"
server.company.com.
So it does a lookup (using the local OS's TCP stack) for the IP address of
"server.company.com", to build its own connection to it.
And.. it gets back 127.0.0.1 as an IP address (because of course that lookup also looks in
the local hosts file first).
That would be kind of a self-inflicted DOS attack, and it would be interesting to see how
quickly the proxy would blow up.
I am not quite sure how you would "corrupt" the httpd proxy code not to do that
(*).
If you tell it to connect to the IP address of that remote host instead, it may not work
as expected, if that remote host happens to be configured with Virtual Hosts itself (which
work by name).
You may be able to configure your webapp to connect to another fake hostname, rather than
the real destination one. In that case, there is a workaround : define that fake hostname
as 127.0.0.1, instead of the real destination one.
But otherwise, you may be in trouble.
(*) well, actually I do have an idea, but it involves an Apache httpd with perl/mod_perl
on it, and some devious perl coding to mess around with the proxy request before mod_proxy
sends it out. If it is really important to you, and you find no other solution, I could
point you to a good consultant for this kind of thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
