[ale] apache, ssl, DMZ, brain calcification

James P. Kinney III jkinney at localnetsolutions.com
Sat Aug 27 08:38:40 EDT 2005


What I'm looking at is a way to share decrypt keys between the real
DMZ'ed webserver and the iptables router. The idea is all new port 443
packets are run through a process that decrypts the payload to find the
URL. That URL is mapped to an internal IP address which is passed back
as the --to-destination $IP_address field for the DNAT. So the packet
now get sent, intact since it was a copy that was opened, to the
internal IP of the ssl website.

I don't see this as breaking the SSL security since the original packet
is unchanged except for the DNAT. However, the big headache is the
apache mod that needs to be able to send the needed info to the router.
That is a chunk of code that is, by necessity, hardened to prevent
security leaks in apache. 


Hmm. The initial https request is NOT encrypted. Maybe a way to do the
tracking through SNAT/DNAT with the connection tables...

research ensues....

On Fri, 2005-08-26 at 23:36 -0400, Allan Neal wrote:
> Unfortunatly the user tool would not work.  SSL will not allow you to do
> hostname based hosting.  Each site has to have it's own IP address.  The
> reason for this is that the url is encoded in the SSL portion of the packet.
> The only part that IPTables can see it the IP address.  So in order to get
> IPTables to do what you are talking about here, you would have to decrypt the
> packet at the firewall to see (name1|name2).  
> 
> You could do one base site with different contexts i.e. https://sitename/name1
> and https://sitename/name2.  Then you only have to have one Cert.  I suspect
> this is not what you are looking for though.
> 
> Sorry I can't be of more help.  This is how it has worked for me in my job
> though.  I run several SSL sites for my company.   We haven't found a way
> around this and it even caused us to recently purchase ARIN space to get
> enough IP addresses to handle our growth.
> 
> Allan
> 
> On Wed, Aug 24, 2005 at 06:15:53PM -0400, James P. Kinney III wrote:
> > I am looking at setting up an ssl-enabled web server in the dmz. As I
> > only have a few real IP addresses, I am looking at using internal IP
> > (10.0.*) addresses to handle the ssl-cert requirements of unique IP for
> > each namespace.
> > 
> > What I'm stumped on is how to get https://name1 AND https://name2 to
> > both get through the firewall and point to the correct virtual interface
> > IP address on the DMX server. Do I need to write a userspace tool that
> > interfaces with iptables to read the server name from the IP stack?
> > 
> > Can this be done with an apache proxy on the firewall?
> > -- 
> > James P. Kinney III          \Changing the mobile computing world/
> > CEO & Director of Engineering \          one Linux user         /
> > Local Net Solutions,LLC        \           at a time.          /
> > 770-493-8244                    \.___________________________./
> > http://www.localnetsolutions.com
> > 
> > GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
> > <jkinney at localnetsolutions.com>
> > Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
> 
> 
> 
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://www.ale.org/mailman/listinfo/ale
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
-- 
James P. Kinney III          \Changing the mobile computing world/
CEO & Director of Engineering \          one Linux user         /
Local Net Solutions,LLC        \           at a time.          /
770-493-8244                    \.___________________________./
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part




More information about the Ale mailing list