tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dmccrthy <dmccr...@gmail.com>
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?

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" <aw@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

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