Secure traffic on reverse proxy and ShibUseHeaders

[Cantor, Scott]

On 11/26/12 12:06 PM, "Paul Beckett (ITCS)" <P.Beckett at uea.ac.uk> wrote:

>It seems to me if I want to authenticate a user in Apache, and pass the
>username to the application I have three options:
>1)     
>Environment variable , with AJP connector (no encryption)
>2)     
>Environment variable, with AJP connector, using SSL tunnel

Or SSH tunnel, which I would advise as a superior alternative, depending
on how it affects performance. SSH connection verification is quite well
understood. SSL certificate verification by typical code is a flaming
disaster.

>2)    
>The extra complexity of SSL tunnel and managing this for a *lot* of
>different services, seems like a major management overhead and something
>else to go wrong

Another argument in favor of SSH if you want to do this.

>3)     
>Would seem preferable but concerned about the spoofing issues :
>
>https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking

That isn't the problem, the problem is that you're specifically
distrusting the network link to your back-end, and if that's the case, the
attacker just injects headers on that link. If you use HTTP proxying
between them, you MUST control the network between Apache and Tomcat.

>The wiki page suggests the Shib SP has some spoof protection, but still
>recommends against using headers. Is it possible to say how significant
>the risk is?

On Apache very low to nil. On IIS, it's highly dependent on application
tools and Microsoft not changing things. I don't consider the latter to be
low risk.

> Is there any known ways to currently overcome the Shib SP¹s spoof
>protection?

Use unsafe settings on IIS, particularly certain .NET APIs, and expose the
spoof checking key in some way.

> 
>Any other thoughts, comments or advice on the subject would be very
>welcome.

I don't personally like HTTP proxying as a security mechanism, especially
not when Tomcat doesn't require it. AJP is just superior for performance,
and in controlling the threat model.

-- Scott