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

Clients directly accessing the server also makes sense when you have tens of thousands of open connections at a time (that would be me). The proxy overhead is just silly. As for HTTPS, isSecure is interesting when using something like warp-tls so as to handle insecure connections more elegantly. While the server can't know about if a proxy received a secure connection it can know if it did. This is even interesting when using a proxy since if the proxy is on another system it should still connect with HTTPS for a large number of threat models. Of course one may put that in the Vault. And don't forget CDN updates where connections that were being sent as HTTPS start being sent as HTTP due to the CDN operator's error. Perhaps you still want to serve most connections when they come in as HTTP from the CDN, send a warning to the ops team, and deny some requests as too sensitive? Plenty of cases here. This isn't about the entire history of the connection, it is about conveying the webserver's information to the app so the app writer can make appropriate choices to figure out what the history actually is given their specific situation. -davean PS: The below happens BTW: client <-> their work's proxy <-> their ISP's proxy <-> CDN <-> provider's proxy <-> final HTTP server That is forwarded 4 times. Of course someone in there can also be lying. I've even seen some pretty clever goes at forging X-Forward-Fors through (or around) proxies. On Wed, Jul 24, 2013 at 9:59 AM, Federico Mastellone wrote:

Wai should provide "a common protocol for communication between web applications and web servers.", using proxies, load balancers or not. I use Wai in a small setup (measured by clients), where clients access the server directly. I was even going to request support for client certificates.

Because some fields are unknown when running behind Amazon ELB I don't think they should be taken out of the Wai interface. In that case, that fields could be Nothing, False, etc. I think it would be great to write an Application that can be run with any Wai compatible server, and maybe later warp supports this fields behind a reverse proxy.

On 24/07/2013, at 09:23, Michael Snoyman wrote:

On Wed, Jul 24, 2013 at 3:08 PM, Kazu Yamamoto 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/Termin...

_______________________________________________

web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel