Ian Bicking: the old part of his blog

Security: yep

The security problem doesn't seem to have much to do with HTTP headers, really. If your back-end server is open to the network, the entire content of each request is suspect, right?

You need authentication; and you need to secure the channel from snooping and tampering. Each of these three facets of the problem has to be enforced in some protocol layer.

Take authentication. You need to: (a) stack HTTP on top of a network-level protocol that authenticates; OR (b) use some hypothetical flavor of HTTP authentication that's actually secure; OR (c) stack another authentication-capable protocol on top of HTTP--you know, SOAP with digital signatures or whatever they're doing these days.

  1. doesn't exist, and everyone knows (c) is immoral, so take (a). This is the "don't do that" solution. Just do exactly what you said you weren't going to do, and firewall off the back-end server. There are several ways to do it--SSL; SSH (?); checking getpeername(); moving the back-end server to another machine behind a physical firewall; VMware... some of which have performance problems, and some of which are only secure given certain prerequisites. You can pick one way that will work everywhere; or you can have your system choose the best way dynamically; or you can push the burden of configuring all the pieces to talk together onto the user.

Or take tampering. You need to: (a) stack HTTP on top of a protocol that provides a no-tampering guarantee; or (b) use some hypothetical HTTP feature that prevents tampering, like adding an HTTP header with a digitally signed hash of the message; or (c) stack another protocol on top of HTTP. Again with the SOAP.

Etc. The world of (a) contains multitudes, with no means of interoperability; the standards for (b) simply doesn't have the features you need; and the stuff at level (c) is despised by all right-thinking persons.

-j

Comment on HTTP proxying questions
by Jason