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

Wed Jul 24 17:52:54 CEST 2013

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/20130724/9dfd2732/attachment.htm>