Re: [hybi] workability (or otherwise) of HTTP upgrade

[Mark Nottingham <[e-mail]>]

Keep in mind you're e-mailing *two* working group lists here, and those on httpbis may not be aware of the entire discussion that's happened in hybi. 

Having said that, the original question on this thread was about Upgrade, so we've drifted off-topic.

AIUI, the issue of concern with Upgrade is that some intercepting proxies will forward the Upgrade header, despite it being both hop-by-hop in the spec, and listed in the Connection header. Because the proxy would be parsing the traffic as if it were HTTP messages and also routing them, it introduces new attack vectors.

A quick aside for clarification here -- IETF folks have been unhappy with the practice of deploying intercepting proxies for more than a decade, and this is just one of many bad effects they introduce. 

IME one of the primary reasons people deploy them is that proxy configuration by browsers is, at best, primitive. I and many others have repeatedly asked the browser vendors to work with us on improving proxy configuration, but haven't yet made progress. 

In other words, WebSockets is hard to deploy because browsers haven't made it easy to interpose a proxy without user intervention; there are significant shortfalls in terms of capabilities, and huge differences in how browsers handle proxy.pac, etc. If the browser vendors would like to work to improve this so as to avoid this situation in the future, that would be great (and I'm sure we could find folks in the community to help out), but unfortunately that doesn't help us at the moment. 

That having been said, it seems to me that there is not a "fundamental flaw" (as per the original question) in Upgrade per se; there are implementation issues which cause it not to work in some circumstances. No protocol (or format) is perfectly implemented, so this isn't terribly surprising. 

The question is what the impact of those bad implementations are on deploying a particular use of Upgrade. Upgrade can be used in a perfectly safe manner for some applications of HTTP; for example, Subversion, Atompub, and other places where an untrusted script can't touch the bytes. 

WebSockets, of course, does allow an untrusted script to touch the bytes on the wire, and that's the problem. Adam has proposed one way of dealing with this -- by using a non-routable hostname in the request-line, he's hoping to jam any intercepting proxies so that they'll fail early (13% of traffic, in his tests). As he points out, though, this doesn't offer good security in all circumstances, and I suspect there are probably a few other attacks that could leak through this approach.

If you want to run over port 80 -- whether you use Upgrade, CONNECT, or a new WEBSOCKET_PLEASE method -- you have to deal with the possibility that someone will assume that the traffic is HTTP, and not have a perfect implementation of the protocol. At the moment HYBI seems to want perfect security, perfect interoperability and perfect deployment success; I'd suggest that something has to give. 

I'd suggest that if HYBI doesn't want to use another port (still the most obvious and safest solution), you could explore in a number of strategies for mitigating these flaws, while still using HTTP Upgrade. For example:

1) Preclude traffic being mis-interpreted as HTTP messages by:
  a. Encrypting the entire stream (as discussed), or
  b. Encoding the stream (e.g., disallowing newlines in payload, or transmitting them as a replacement character)

2) Assure that WebSockets messages are also valid HTTP messages, but without the constraints of the HTTP message exchange pattern. 

None of these approaches will deal with interoperability problems caused by transparent proxies, but they should mitigate the security issues, as I understand them. 

This is getting longer than I intended, so I'll stop now.




On 09/12/2010, at 10:28 AM, Brian McKelvey wrote:

> Requiring encryption has been proposed and subsequently rejected by the group many, many times now, mostly in the previous discussion on framing.  There were a number of people with use cases that demanded an extremely high throughput, low overhead solution for various reasons.  Can we please stop considering that option to still be even remotely on the table?  Maybe circle back to it as a last resort if we get desperate, but that's not yet.  Until then it waters down the discussion.
> 
> Encryption should be available but not required.  I myself use draft-76 wss:// exclusively on port 443 of my servers (behind STunnel and HAProxy) because of the higher connection success rate.  But I can understand the use cases where it isnt required, and could be problematic.
> 
> Brian
> 
> Sent from my iPhone
> 
> On Dec 7, 2010, at 7:27 AM, Joe Mason <[e-mail]> wrote:
> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Maciej Stachowiak
>>> Sent: Tuesday, December 07, 2010 2:05 AM
>>> To: Mark Nottingham
>>> Cc: hybi HTTP; HTTP Working Group
>>> Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
>>> 
>>> If the goal was not to interoperate with HTTP at all, it would be much
>>> better to use an approach where everything is encrypted. One plausible
>>> way to do that would be to restrict the protocol to TLS-only, at which
>>> point the nextprotoneg proposal can take care of dispatch without
>>> having to involve the HTTP layer. I think this is a plausible option,
>>> but many hybi WG members have expressed concern about the performance
>>> issues and other barriers to deployment of an all-TLS solution.
>>> 
>>> Another approach is to invent our own crypto and start with a key
>>> exchange. Inventing crypto makes me nervous compared to using something
>>> known (such TLS), and might well impose many of the same costs that
>>> folks are worried about with TLS.
>> 
>> If we are going to encrypt everything, we should just use TLS.  Crypto is an especially bad place to be reinventing the wheel.  As far as I know all the performance concerns apply to any encryption, even simple XOR masking, so there's no point in discussing tradeoffs of various implementations - the tradeoff is whether we want encryption at all.  Once we're over that hump, I don't think any custom encryption scheme is going to have benefits that outweigh TLS's huge benefit of "well understood and in wide use".
>> 
>> Joe
>> 
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi

--
Mark Nottingham   http://www.mnot.net/