RE: Reverse proxy scenario

[Ben Nagy <bnagy () sa volante com au>]

> -----Original Message-----
> From: Carric Dooley [mailto:carric () com2usa com]
> Sent: Thursday, 21 September 2000 3:12 AM
> To: firewall-wizards () nfr net; firewall-wizards () nfr com
> Subject: [fw-wiz] Reverse proxy scenario
>
>
> OK.. I don't work much with proxies so I wanted to run this 
> past you guys
> and get some input:
>
> I have a client (an internet bank) that wants to secure an 
> account access
> front-end.  The architecture is:
>
> A front-end web server protected by FW-1 that the users 
> actually attach to
> via SSL.

With you so far.

>  This web server would then connect back through the 
> FW-1 to a
> private DMZ where it would have to speak through an 
> application proxy to get
> to another webserver that has a database backend

Uh, OK.

> (the golden egg with
> account data that we are trying to protect).  The front end 
> web server will
> make XML calls (hopefully over SSL or some other encrypted tunnel...
> suggestions?)

What does SSL buy you here? If an attacker has compromised your front-end
web server then they have access to all the traffic going through it and can
defeat the SSL easily...

I guess it removes the ultra trivial "sniff the inside NIC" attack but if
we're talking about valuable data I'd imagine that a more sophisticated
attacker should be part of the threat model.

> through the proxy to the other 
> database-backended web server.
> This way the user never actually interacts with the box that 
> queries the
> database.

Seems reasonable.

[snip] 
> I have been researching proxying SSL and it looks like that's 
> a pain in the
> a**.

Why? You can't do much more than ferry the packets backwards and forwards,
true, but that's all you need. The proxy between the inside WWW and the
outside WWW just needs to pass SSL stuff. No big deal. You could even use
one of these e-commerce accelerator thingies to turn the traffic into
cleartext on the other side of the SSL doohicky.

But, as I said, I'm dubious about the benefit of SSL for the inside
connection, anyway.

> I would like to get some input from anyone that has done revers
> http/https setups for companies.  I have looked at using something
> specifically for this, like Netscape Proxy, or going with 
> something like
> Raptor or Gauntlet so they can add more functionality to this 
> architecture
> later on.  I can't find any data on doing this with either Raptor or
> Gauntlet however.

The current version of Gauntlet has an SSL proxy. Don't know about Raptor,
sorry. Squid can proxy SSL/TLS, so I assume that Nutscrape can as well
(being a fairly obvious ripoff of Squid).

>  I realize the proxy has to have a key for 
> the SSL tunnel,

Uh...not really. Depends on your approach. The way you're talking about
doing things involves the proxy impersonating the internal server. In that
case you just need to tell the external server that the proxy's public key
belongs to the inside server - effectively a key substitution attack.

The "other" way is to just pass the SSL packets through without decrypting
them.

[snip]
> I am trying to get to a place where:
> If the front end box is comprimised, the traffic can't be sniffed for
> sensitve info.

I fail to see how you can do this. If the front-end box is compromised, so
is all the traffic that goes through it. Worse - if an attacker rips the
private key out of the front-end box they can then impersonate that box and
make bogus transactions on your internal server which you won't be able to
repudiate. Yuck.

Moral: Don't get your front-end box compromised.

[snip]
> Any takers?  =)

I think you're making a mistake in terminating the SSL connection from the
client to the bank in an external security zone. It seems to me that they
key threat here is impersonation, right? The best way of avoiding that is to
use strong authentication (like SSL with client certs). So what you really
need is a box that you really trust doing your SSL auth stuff. Everything
behind that box is just taint checking. Yes, taint checking is hard, but not
impossible.

I know Intel (shudder) makes a dedicated box that just does SSL - I don't
know if it speaks LDAP or has some other way of verifying the certs of
hundreds of users, and I haven't done or seen a determined security review
of the product. However, on spec, that sort of thing sounds good - single
function box, hardware crypto offload, no remote management.

Anyway, that's enough ramble from me.

Cheers,
 
--
Ben Nagy
Network Consultant, Volante Solutions
PGP Key ID: 0x1A86E304  Mobile: +61 414 411 520 

_______________________________________________
Firewall-wizards mailing list
Firewall-wizards () nfr net
http://www.nfr.net/mailman/listinfo/firewall-wizards