[web-devel] [Yesod] Re: Next version of WAI: cleaning house

[Michael Snoyman]

On Wed, Jul 24, 2013 at 3:08 PM, Kazu Yamamoto <kazu at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20130724/a89ee6c3/attachment.htm>