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 Fri, 09 Jan 2015 16:43:19 GMT
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Chuck,
> 
> On 1/8/15 6:21 PM, Caldarale, Charles R wrote:
>>> From: dmccrthy [mailto:dmccrthy@gmail.com] Subject: Re: Tomcat
>>> 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS Mutual
>>>  Authentication connections
>>> 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
>> This is for requests coming _into_ Tomcat, not any outbound
>> requests your webapp is doing - which Tomcat is not involved in (or
>> even aware of) at all.  Again, you need some sort of proxy, if your
>> webapp cannot be changed to do the right thing.
> 
> No, this is for constructing URLs and using classes like URLConnection
> to access them. If the underlying code (e.g. Apache httpclient) uses
> URLConnection under the hood, then this technique will work.
> 
> This is actually what my initial suggestion was in my first reply to
> this thread: install a stream handler for a particular protocol.
> 
> The thing is, I don't think you'd want to do this for *all* http://
> URLs... only those that should be converted into secure ones. So you'd
> have to be able to change the URL.
> 
> Another thought: use stunnel. It's probably the simplest possible
> thing to set up. Have stunnel listen on a nearby host (perhaps
> localhost) for non-secure HTTP connections, and connect the other end
> to the "real" server's HTTPS port. We do this at $work to deal with a
> product that doesn't support HTTPS internally, just as the OP is doing.
> 

I think that the final answer is : "it depends".
I've done a few of these "proxy hacks" in the past, for various purposes, including a 
couple of failed attempts too (but rich in lessons).
If you know exactly what kind of requests the client (the webapp in this case) is sending

to what server, and you know exactly what it gets in response, then you can usually do 
something of the "man in the middle" kind of thing.
But by experience, some websites return really nightmarish stuff, full of re-directs, 
javascript modules making their own connections elsewhere, cookies containing information

needed to access follow-up pages and whatnot, and that can quickly become unmanageable.
(Think Akamai, ads and analytics sites, www.bbc.com and img.bbc.com, balancing proxies etc..)

I have a couple of questions here, for my own edification but I believe also on-topic for

the OP :

We have this webapp making a HTTP connection on the side, to some third-party host.
It is a fair bet that the creators of that webapp did not start from scratch, and that 
they used some existing library to do that (à la httpclient as Chris suggested).

First question thus : even not having the source code of the webapp, can one easily find 
out what it uses in order to make that HTTP connection ?

Assuming that the answer to the previous question is yes, second question :
If a webapp "invokes" a given class to create such a connection, where does java look 
first for the corresponding class ? in the webapp's own WEB-INF/classes or WEB-INF/lib ?

And if the answer to that is also yes, can one place a jar there, with classes having the

same name as the one which the webapp would normally invoke, and which would be found 
first/override the usual ones it uses ?

And could such a class examine the original request URL, and if it is not one that it 
should intercept and massage, just delegate the call to the similarly-named "normal" class
?

Or is there something fundamentally uncouth/illegal/fattening in such a scheme ?



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message