tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS Mutual Authentication connections
Date Thu, 08 Jan 2015 22:07:54 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message