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

davean davean at xkcd.com
Thu Jul 25 06:12:15 CEST 2013 

I agree, that is a pure duplication. It is in he headers also and that is
where it should be because that is what it is.

-davean


On Wed, Jul 24, 2013 at 11:47 PM, Michael Snoyman <michael at snoyman.com>wrote:

> 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/1078f78d/attachment.htm>

More information about the web-devel mailing list