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

Michael Snoyman michael at snoyman.com
Thu Jul 25 05:47:53 CEST 2013 

OK, fair enough, you've convinced me. We can address the concerns that I
have about this value being misleading with clearer documentation.

However, given that serverName is essentially just "the Host header, or
whatever else I feel like giving you," I still think it makes sense to
remove that one.


On Wed, Jul 24, 2013 at 6:52 PM, davean <davean at xkcd.com> wrote:

> Perhaps the part that might help you understand what I mean is:
>
> -- | An action when a plain HTTP comes to HTTP over TLS/SSL port.
>
> data OnInsecure = DenyInsecure L.ByteString                | AllowInsecure
>
>
> (
> http://hackage.haskell.org/packages/archive/warp-tls/1.4.1.3/doc/html/Network-Wai-Handler-WarpTLS.html
> )
>
> "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."
>
> HTTP can come in on an HTTPS port. Your HTTPS server can get HTTP requests.
>
> Though in theory you could run an HTTP and an HTTPS server on the same
> port I suppose ... at an immense technical complexity.
>
> -davean
>
>
> On Wed, Jul 24, 2013 at 11:46 AM, Michael Snoyman <michael at snoyman.com>wrote:
>
>> What I'm looking for as far as use case is "I want to do X, and if you
>> put Y in the Request value, I could do X better." For example, "If I knew
>> that a request was insecure, I could automatically redirect to the secure
>> URL." My reasoning here is that, for all such use cases I've heard,
>> determining if it's a secure connection from the Request value is wrong. In
>> this case, you have to run two Warp servers anyway, one over HTTP and one
>> over HTTPS. So the more logical thing would be to just have two separate
>> applications, one with the redirect logic and one without.
>>
>> And you're probably right; I can't think of any handlers that can't
>> determine if they were connected to securely. But again, my concern is
>> about including misleading information in Request which, given its lack of
>> reliability, can't really be used. If there *are* real use cases that I'm
>> not thinking of, that's a different story.
>>
>>
>> On Wed, Jul 24, 2013 at 6:36 PM, davean <davean at xkcd.com> wrote:
>>
>>> I explicitly described a scenario in my email. Can you tell me more
>>> about what you want me to describe? Unless you consider my Vault
>>> alternative as not in the Request.
>>>
>>> Not sure what backend couldn't reliably tell whether *it* was connected
>>> to securely. None can make claims about other steps in the chain (Which is
>>> also exactly why we need this value).
>>>
>>> -davean
>>>
>>>
>>> On Wed, Jul 24, 2013 at 11:29 AM, Michael Snoyman <michael at snoyman.com>wrote:
>>>
>>>> My concern is that, by throwing in as much information as possible in
>>>> Request, we'll essentially be diluting the meaning of the values there. My
>>>> approach was to only include values in Request that can be reliably
>>>> reported by all backends, or at the very least would clearly be nonsense
>>>> for certain backends[1]. My big concern is making it easy to write
>>>> incorrect code. My question is: what is a concrete example where you would
>>>> want the isSecure field in Request? If you're talking about a case where
>>>> you're using warp-tls and no reverse proxies, then you can tell your
>>>> application (via a config parameter, for example) that this is the case.
>>>>
>>>> Maybe I just don't have the right mental model for what people are
>>>> expecting for WAI. I want to understand the use cases better, so please
>>>> keep up the discussion :).
>>>>
>>>> [1] Example: wai-test clearly has to provide a fake IP address for the
>>>> remote end of the connection.
>>>>
>>>>
>>>> On Wed, Jul 24, 2013 at 6:10 PM, davean <davean at xkcd.com> wrote:
>>>>
>>>>> 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 <fmaste at gmail.com
>>>>> > 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 <michael at snoyman.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>> web-devel mailing list
>>>>>> web-devel at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/web-devel
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> web-devel mailing list
>>>>>> web-devel at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/web-devel
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> web-devel mailing list
>>>>> web-devel at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/web-devel
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20130725/a1d1361c/attachment.htm>

More information about the web-devel mailing list