-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All,
On 5/25/16 11:30 AM, Christopher Schultz wrote: > 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. I've added the above to the wiki: https://wiki.apache.org/tomcat/AJP%20with%20stunnel - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldFyYcACgkQ9CaO5/Lv0PBz4gCeJRdGjWsJepYG8Ozh1A/Z+d07 r6kAniN465Rw0kv/awlbxEamUPK9MmjI =H8q/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
