Inline: > To: users@tomcat.apache.org > From: [EMAIL PROTECTED] > Subject: Re: mod_jk or mod_proxy_ajp - encryption benefits? > Date: Sun, 2 Mar 2008 15:31:21 -0800 > > > "James Ellis" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > >Inline: > > > >> Date: Sun, 2 Mar 2008 18:16:24 +0100 > >> From: [EMAIL PROTECTED] > >> To: users@tomcat.apache.org > >> Subject: Re: mod_jk or mod_proxy_ajp - encryption benefits? > >> > >> James Ellis schrieb: > >> > I know that mod_jk is the battle tested connector between Apache and > >> > Tomcat, but as I understand it the SSL connection generally > >> > terminates at the Apache web server and the traffic between Apache > >> > and Tomcat (to the AJP connector) is unencrypted. Two questions: > >> > > >> > 1) Does mod_proxy_ajp provide for any encryption between the web > >> > server and the app server (Tomcat) that mod_jk does not? > >> > >> No, the AJP13 protocol does not support encryption. Both connectors use > >> the same protocol. If you need to use encrypted traffic with AJP13, you > >> could tunnel through an encrypted channel. > > > > > >Is this the common practice then when communicating from the web server to > >the application server? > > It is relatively uncommon (hence why encryption has taken so long to be > added to AJP/1.3). However, sites that have to communicate over a WAN do > often use SSH tunneling or similar. >
Wait...so encryption HAS been added or HAS NOT been added to AJP/1.3 ? > > > >If not, it seems like an awfully big security hole, since the DMZ is > >supposed be only "partly" safe. If someone were to >crack into the DMZ and > >could sniff network traffic, then they could in theory listen in to traffic > >and grab all of it in an >unencrypted state (which may include credit card > >information, usernames, passwords etc). > > > > For most sites, if someone were to crack into the DMZ, they would probably > be more interested in querying your DB server for the credit card > information, usernames, passwords, etc :). In other words, you would have > many much bigger problems to worry about than someone sniffing AJP/1.3 > traffic. And this is why it is relatively rare to use tunneling with > AJP/1.3. Your resources are usually better spent securing your DMZ. > But in most sites, the point of the DMZ is to isolate the web server. The database/application server wouldn't be in the DMZ...just the web server, so they couldn't query the database unless they broke through two firewalls (one facing internet, one facing dmz). From what I am gathering though, they could, however, sniff traffic that has been decrpyted at the web server (where SSL ends) and being sent to the app server (probably to be saved/checked against the database). Is this just an acceptable risk or do most companies use SSL tunneling? > > > > > > > >> > >> > 2) If the > >> > answer to number 1 above is "NO". Is it possible to keep the server > >> > certificates on the app servers and so that the connection from the > >> > client to the app server is encrypted all the way through? In this > >> > case the apache web server would simply function as a load > >> > balancer/failover solution. > >> > >> Again no. We are talking about a reverse proxy situation and as far as I > >> know, you can't reverse proxy https without having an ssl endpoint on > >> the apache httpd. > >> > >> For a normal (forward) proxy, httpd supports connect, but I don't know > >> how well this works in the real world. > >> > >> You could also ask on the httpd users list, maybe they know better. > >> > >> > Thanks, Jim > >> > >> Regards, > >> > >> Rainer > >> > >> > >> --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
