On Wed, Jul 24, 2013 at 3:08 PM, Kazu Yamamoto <kazu@iij.ad.jp> wrote:

Michael,

> I'm definitely not talking about removing the peer information. Request has
> a remoteHost field which is of type SockAddr, and therefore provides both
> remote IP address and port number (the latter, as you mention, being mostly
> useless).

Please understand that I'm not opposing your opinion. I'm just trying
to interpret user's opinions.

I appreciate the input, I just wanted to clarify my proposal.

> I'm not sure what you mean by telling if communication is encrypted using
> the headers + IP address, can you clarify?

Suppose a Yesod application receives X-Forwarded-For:.

A bad client can insert X-Forwarded-For:. But if an IP address is
provided and the application knows the IP address of the proxy, the
application can tell whether or not the IP address can be trusted.

I'm not sure that there is a standard header field to tell HTTPS.
But if the proxy and the application shares such field:
- The application can truct the field according peer's IP address
- The application can tell the outside HTTP is encrypted

Correct me if I misunderstand.

I'd never considered checking the IP address of the proxy. When I've used X-Forwarded-For, I've always made sure to set up a firewall to ensure the *only* connections come from the reverse proxy, and then x-forwarded-for can be trusted.

As far as determining secure/insecure, it seems like Amazon's ELB sets x-forwarded-proto[1]. Not sure if that's a well accepted standard, but it seems useful.

Michael

[1] http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#x-forwarded-proto