Hi All, Thank you very much for the solution.
Best Regards, Mohan On Wed, May 25, 2016 at 9:00 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mohanavelu, > > On 5/25/16 10:21 AM, Mohanavelu Subramanian wrote: > > I have Httpd process and Tomcat instances both running on 2 > > different machines. The communication between them happens through > > AJP protocol (mod_jk) which doesn't support encryption. But we are > > using some features of mod_jk like automatic passing of security > > information like SSL certificate to tomcat which in turn is > > accessed in our application, validated and verified. > > > > Now, we have requirement to make the communication between them as > > Secured. Since AJP doesn't support encryption, I came to know that > > we need to use SSH, IPSec. But I could not find any proper document > > to configure SSH or IPSec for AJP. Could please share if you any. > > > > I have considered mod_proxy_http as well for supporting security > > which is easy to configure as well. But as I mentioned above we are > > already making use mod_jk features. Again it will require more > > efforts to migrate from mod_jk to mod_proxy_http. > > It's not so bad switching from mod_jk to mod_proxy_http, but you are > right that it does require re-configuration. > > IPsec and SSH tunnels (using the ssh binary) are a total pain. We use > stunnel, and it's fairly simple to set up. stunnel uses SSL/TLS to > tunnel other protocols. It does *not* use the SSH protocol, which is > critical to understanding how it works. > > stunnel is a little more complicated than a normal protocol because it > can be used in a number of different ways. I'll give some contrived > examples to see how you can set it up in different ways, depending > upon the support for encryption of the underlying protocol. > > Let's say that you have an HTTPS server, but your client can't speak > HTTPS for some reason. If you set up stunnel on the *client* side, you > can connect locally to the stunnel server and have it establish a > secure-connection to the remote server running HTTPS. Like this: > > client -> localhost:12345 stunnel > stunnel -> remote_host:443 > > As far as the client is concerned, it's using HTTP to talk to > localhost. But really it's talking to remove_host:443, so everyone is > happy. (Yes, there are issues with URLs and redirects produced by the > server, but that's out of scope for this discussion). > > Let's take another example: you have clients that are HTTPS-capable, > but the service you are running can only support HTTP for some reason, > and you want to secure it. Set up stunnel on the *server*, then have > your remote clients connect to *it* and tunnel to localhost. Like this: > > client -> remote_host:443 > stunnel localhost:8080 > > As far as the client is concerned, it's using HTTPS to communicate > with remote_host:443, but really it's connecting to remote_host:8080. > (Yes, there are some issues with URLs and redirects but that's out of > scope for this discussion.) > > So what if the underling protocol doesn't support TLS at all? Well, > then you have to set up stunnel on *both sides* of the tunnel, like this > : > > client (mod_jk) -> localhost:12345 > stunnel -> remote_host:12345 > stunnel -> localhost:8009 > > The setup for stunnel looks like this for the client (on the web server) > : > > sslVersion = all > options = NO_SSLv2 > options = NO_SSLv3 > client = yes > [ajp13s] > accept=localhost:8009 > connect=remote_host:8010 > > On the server, it looks like this: > > sslVersion = all > options = NO_SSLv2 > options = NO_SSLv3 > client = no > [ajp13s] > accept=8010 > connect=localhost:8009 > > On the web server, set your worker's host to "localhost" and port to > 8009. mod_jk will connect to localhost:8009 which stunnel will accept > and forward over the network to remote_host:8010 which will be > accepted by stunnel on the server and forwarded to localhost:8009 on > the server. > > stunnel is great because it will auto-reconnect if the connection is > dropped for some reason. Remember a few things with stunnel: > > 1. Depending upon the version, you might only be able to use TLSv1 > (and not e.g. TLSv1.2) > 2. stunnel generally ignores certificate issues, such as expiration, > etc. You might want to configure it with a little more care than the > default. THIS ALSO MEANS IT DOES NOT AUTHENTICATE THE SERVER BY > DEFAULT. You could accidentally connect to a malicious server. > > Hope that helps, > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAldFxP8ACgkQ9CaO5/Lv0PBskQCfUnXqw5wGSTo+Tr9wk6ZvxJCq > NPsAoJaPHHhvHCkI8TnAMaCrQ5q3y9x9 > =h4AI > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
