NYCPHP Meetup

[Jeff Hegedus]

Hi all,

 

I have multiple domains but only a single IP address and I'd like to support
encrypted connections for certain operations like login, credit card info,
secure file upload and download, etc.  I've heard a lot about how SSL can't
be used with name based virtual hosting but I'm still looking for a solution
that does not force me to set up a separate IP for each domain that has
needs for secure operations.  I've had a couple of ideas that I think might
work but I'd like a few other smart folks to bounce the idea off if
possible.

 

 

 

1.  IPTABLES + APACHE REVERSE PROXY + MULTIPLE INTERNAL WEB SERVERS

 

There are two domains.  domain1 and domain2 both mapped to the internet
address inet_ip by dns.

 

The firewallServer located at inet_ip (internally this is internal_ip_4) has
iptables installed and running.

There is an iptables rule that redirects all traffic with a destination of
inet_ip:443 that is not part of an established connection to internal_ip_3

(not sure exactly how to write this yet.  Can anyone give a definitive
answer on whether it is possible and how?  If not, I'll look into it as time
permits)

Internal_ip_3 is running an apache server with name based virtual hosts and
reverse proxy rules set up to map domain1 to internal_ip_1 and domain2 to
internal_ip_2

Internal_ip_1 is running an apache server set up with SSL and a certificate
for domain1

Internal_ip_2 is running an apache server set up with SSL and a certificate
for domain2

 

 

I'm not sure if this is accurate, but I was thinking that if a client were
to make a request to https://www.domain1.com <https://www.domain1.com/> 

the initial packet would come into the firewall server and be routed to
internal_ip_3.

I was also thinking that at this point the connection has not yet been made
to the destination server so no encryption has actually been performed.

This would allow Apache to freely read the header information.

If this is correct, SSL shouldn't actually need to be installed on the
internal_ip_3 server and port 443 could be set up as a standard http server

 

OK, the above is one of the key points in this method of supporting SSL.
Please let me know if you know this won't work.

 

If the above is true, progress continues by the initial packet being routed
to the internal_ip_1 server.

This server has Apache set up with SSL and a certificate for domain1

The request is received and the handshake is performed.

Finally, the response from Apache on internal_ip_2 is encrypted with the
certificate for domain1 and returned to the client.

 

Further requests come in from client1 that are encrypted but due to the fact
that they are part of 

an established connection they are routed appropriately to the machine the
client previously connected to.

This is the second key question.  Will conntrack actual be able to do this
mapping with an encrypted packet.  If it can't the whole thing falls apart.

 

If this doesn't work exactly as is, would doing an SNAT when incoming
packets hit the firewallServer and the reverseProxy allow it to work?

 

Ok, that's that was my first attempt to design a solution.

 

 

 

next.

 

2.  ONE DOMAIN WITH SSL ENABLED THAT IS LEVERAGED FOR ALL LOGINS AND OTHER
SECURE REQUIREMENTS

 

I haven't worked out all of the details on this but it seems like it should
be pretty manageable

to have the site that needs secure services pass a site id and perhaps an
original URL to the secure site.

This should allow the secure site to brand the pages and fulfill secure
services with things like site specific user lists and redirects to the
referring page.

 

This seems like a pretty workable solution with the key drawbacks being some
confusion and potentially paranoia

on the part of the user due to the URL not being part of the original domain
and some additional coding and deployment complexity

due to the fact that the functionality of a "site" would really be split
across multiple domains.

With any luck,  proper branding could reduce the user confusion and proper
architecture and documentation would make it easier for developers to
implement.

 

OK, that's the second attempt.

 

 

 

I'd really appreciate any input anyone has.

 

Thanks,

 

 

 

 

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20050806/53f1e66f/attachment.html>