tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dmccrthy <>
Subject Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS Mutual Authentication connections
Date Thu, 08 Jan 2015 23:06:59 GMT
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?

 On 8 Jan 2015 22:08, "André Warnier" <> 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 ""
> - to divert this to your own local proxy, you define ""
> in the local hosts file as (the localhost), and you set up a
> local httpd to listen on, to do the proxying.
> - thus when the webapp builds its TCP connection to "
>" - presumably by looking up ""
> first - it gets back (from the local OS's resolver) the IP address
>, and builds a TCP connection to
> Then over that connection, it sends a HTTP 1.1 request including a "Host:
>" 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"
> So it does a lookup (using the local OS's TCP stack) for the IP address of
> "", to build its own connection to it.
> And.. it gets back 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, 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message