Hi André, Chris, Just to park the proxy idea for a moment, I found the link below from 2008. It looks like a minor change to the Catalina WebAppLoader class might solve the problem and let me provide a custom HTTPS URL protocol handler. Have I misread this?
http://tomcat.10.x6.nabble.com/Custom-URL-handlers-in-Tomcat-web-app-td2006418.html Thanks, Diarmuid On 8 Jan 2015 22:08, "André Warnier" <a...@ice-sa.com> wrote: > 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 > >
