You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by James Ellis <el...@hotmail.com> on 2008/03/02 22:27:29 UTC
[users@httpd] Unencrypted Channel From Web Server To App Server
Is it correct to say that in a typical Browser-Apache Web Server-Tomcat App Server setup, the SSL connection generally terminates at the Apache web server and the traffic between Apache and Tomcat (to the AJP connector) is unencrypted? If I am correct that this is the "usual" setup, then isn't this a pretty big security flaw 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).
Jim
Re: [users@httpd] Unencrypted Channel From Web Server To App Server
Posted by Sean Allen <se...@ardishealth.com>.
On Mar 2, 2008, at 7:20 PM, James Ellis wrote:
> Inline:
>
> > Date: Sun, 2 Mar 2008 17:59:00 -0600
> > From: wrowe@rowe-clan.net
> > To: users@httpd.apache.org
> > Subject: Re: [users@httpd] Unencrypted Channel From Web Server To
> App Server
> >
> > James Ellis wrote:
> > > Is it correct to say that in a typical Browser-Apache Web Server-
> Tomcat
> > > App Server setup, the SSL connection generally terminates at the
> Apache
> > > web server and the traffic between Apache and Tomcat (to the AJP
> > > connector) is unencrypted? If I am correct that this is the
> "usual"
> > > setup, then isn't this a pretty big security flaw 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).
> >
> > Yes. This design relies on the integrity of the network beyond the
> DMZ.
>
> I am assuming the following design:
>
> browser
> FIREWALL (BEGIN DMZ)
> web server
> FIREWALL (END DMZ)
> app server/database server
>
> You say it relies on the integrity of the network "beyond" the DMZ,
> but my point is that doesn't this design also rely on the integrity
> WITHIN the DMZ? Since SSL is ending at the web server
> here...traffic from the web server to the app server would be
> unencrypted...
>
> >
> > A good solution is to use proxy_http over ssl and the https
> connector for
> > the last mile, if this is a concern in the environment you have
> deployed.
And this right here:
> A good solution is to use proxy_http over ssl and the https
> connector for
> > the last mile
States exactly that, running the webserver to app server via an ssl
proxy rather than just regular http proxy.
RE: [users@httpd] Unencrypted Channel From Web Server To App Server
Posted by James Ellis <el...@hotmail.com>.
Inline:
> Date: Sun, 2 Mar 2008 17:59:00 -0600
> From: wrowe@rowe-clan.net
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] Unencrypted Channel From Web Server To App Server
>
> James Ellis wrote:
> > Is it correct to say that in a typical Browser-Apache Web Server-Tomcat
> > App Server setup, the SSL connection generally terminates at the Apache
> > web server and the traffic between Apache and Tomcat (to the AJP
> > connector) is unencrypted? If I am correct that this is the "usual"
> > setup, then isn't this a pretty big security flaw 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).
>
> Yes. This design relies on the integrity of the network beyond the DMZ.
I am assuming the following design:
browser
FIREWALL (BEGIN DMZ)
web server
FIREWALL (END DMZ)
app server/database server
You say it relies on the integrity of the network "beyond" the DMZ, but my point is that doesn't this design also rely on the integrity WITHIN the DMZ? Since SSL is ending at the web server here...traffic from the web server to the app server would be unencrypted...
>
> A good solution is to use proxy_http over ssl and the https connector for
> the last mile, if this is a concern in the environment you have deployed.
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
Re: [users@httpd] Unencrypted Channel From Web Server To App Server
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
James Ellis wrote:
> Is it correct to say that in a typical Browser-Apache Web Server-Tomcat
> App Server setup, the SSL connection generally terminates at the Apache
> web server and the traffic between Apache and Tomcat (to the AJP
> connector) is unencrypted? If I am correct that this is the "usual"
> setup, then isn't this a pretty big security flaw 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).
Yes. This design relies on the integrity of the network beyond the DMZ.
A good solution is to use proxy_http over ssl and the https connector for
the last mile, if this is a concern in the environment you have deployed.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org