-----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: [email protected] For additional commands, e-mail: [email protected]
