-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 1/8/15 9:52 AM, André Warnier wrote: > dmccrthy wrote: >> Hi, >> >> Is it possible to configure or hack Tomcat in some way to >> intercept outbound HTTP URL requests from a deployed web >> application and convert them to HTTPS with Mutual >> Authentication? >> >> My scenario is: >> >> * 3rd party web application that makes client invocations to a >> server that requires HTTPS with Mutual Authentication * I don’t >> know what framework the web application uses or how it creates >> the HTTP client connections * I can’t make changes to the 3rd >> party application >> >> I have investigated the below but they don’t seem to offer a >> solution >> >> * Adding Custom Resource Factories - >> http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources- >> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html> >> >> howto.html >> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>. >> This requires changes to the client application * HTTP connector >> - http://tomcat.apache.org/tomcat-7.0-doc/config/http.html.. This >> is for the Tomcat web server, not for outbound client >> connections >> >> I have successfully configured the server and can make SoapUI >> calls to it using HTTPS and Mutual Authentication. If I had >> control of the client code I would use HttpClient and accomplish >> it that way. >> >> For the Tomcat client application I have searched Google, >> Stackoverflow, and the Tomcat wiki and mail archives but all >> HTTPS/Mutual Authentication solutions I can find refer to Tomcat >> as the web server, not to web applications making outbound >> connections from a Tomcat instance. >> >> If there is no option to configure Tomcat then the only options I >> can think of are below, but if anyone has any other insights it >> would be much appreciated. >> >> 1) Write a between the Tomcat “client” instance and the HTTPS/MA >> endpoint 2) Find out the framework/socket factory/url connection >> factory the 3rdparty web app uses and override it with a Tomcat >> plugin 3) Raise a feature request with the 3rd party vendor to >> support HTTPS/MA >> > > I don't know really about the "hacking Tomcat" option (but I > believe that is not possible in this case, because Tomcat is not > involved at all in those connections which the webapp is making "on > the side"). > > This is what you could do outside of Tomcat (but it is some work) > : > > 1) find out to what hostname:port that application is making a > call. Say for now that it is "server.company.com:8000". > > 2) in the "hosts" file of the Tomcat server, add an entry for that > hostname, with IP address 127.0.0.1, like 127.0.0.1 > server.company.com (alternatively, you could use another valid IP > of your Tomcat server) Yup: MITM. > 3) on the Tomcat server, create a separate "proxy" process which > listens on that IP and port 8000 for such HTTP requests, and > forwards them via HTTPS to the real external host/port (while being > careful not to create a loop via the hosts file - iow, if possible, > it should not do a DNS lookup for the external hostname > "server.company.com", because it would get 127.0.0.1 as the IP > address, and that would be self-defeating) > > Of course then, the burden of the HTTPS/MA dialog falls on that > process which you create. Any web server capable of proxying would work here, probably better than Tomcat. Proxying connections from HTTP to HTTPS using Apache httpd would be fairly simple: no code required, just configuration. > Note that this approach is somewhat simplistic and flaky, and will > only work if these external HTTP requests/responses are really > simple, and the responses returned by the external server don't do > things like re-directs elsewhere etc.. Apache httpd would probably handle these appropriately. Writing one's one code would be a mistake, here. > It would indeed be a lot better to ask the webapp provider to fix > their code. +1 > But also note that to simplify your life you may be able, for this > separate "proxy" process, to use an already-existing piece of > software such as an Apache httpd webserver (listening on > localhost:8000) (*), or some utility that creates "tunnels". +1 > (*) or even a dedicated Tomcat instance, provided you find a webapp > able to act as a HTTPS/MA proxy I'm not sure if there's a Java-based proxy web application out there; I've never looked for one. The use of httpd, nginx, or squid seems like a much better choice. The nice thing is that you don't have to deploy it wide-scale: you can just make it listen to localhost connections and not expand the attack surface of your server. So, even though you might be introducing more complexity, etc. into your network setup, you are not exposing that service to the world and only have "trusted" clients connecting to it (the service you are trying to MITM). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUrq0cAAoJEBzwKT+lPKRY/B4QAKB+9GhfOGH49duuMDpKo9Y5 yPBcyM5S0BAaTeDnePYr+62fLqOLc3LlENUprM01wPKqTgMuIgeFd9q6yOGeDzwb +p8DF+zpvNFO+3n1KG+UAtZdNOdmFoZoMJZ76ZEngw67yYODSD1EKs1e9ckyTvGc 28hG3lle+9ApmVDocREPb3vs6ZhE5CjjrtSzz8ZYyKJPif8U+VwrDg3AjfaDTSVk 3JFC0ow2/smjDJ/er287114g+yXOR4ABojE45gJ/hr2IUrO/GWiwmO3Bhk/EGeck 24FOJ8ntBt5OqOXUX1LpcjpsoZujf3kQEyx3HC+Y7USijS02OZoVmvjTvlIdW4yE Fvl08wxOcjRo8GkdYoBMBwLQd56O11h2qOBHMa++ij09GLpbzHAj5z0Aac5ppLjl C2pgnAob1wRsfsaym726dOvtipRhXJyaIHxzjd7TqvCUG+47ypyWkxGpHyN9WzXE YEGI3UI7qpkBBNl43KRHyo5slz9YDgcDRQYFjh0MufXBFuE5s2q9AO4y1eIWO7G2 q/P5MgKuUPjlFmBNAeh7C5FFtiKPx7LXkchfvfjD7J5c+tTOKokXJC7uU7W6mZkt joGjO6oxh7LnVy4hPDtqS5TbwX9pzYbCdidFJpptH0LgMR6/4T8a00Aj81KLzy50 x4vaYzEKdFHYQwmHhdqf =Zyum -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
