Re: [hybi] Upgrade Mechanism and HasMat (was Re: Extensibility mechanisms?)

["Roy T. Fielding" <[e-mail]>]

On Jul 22, 2010, at 10:27 AM, Adam Barth wrote:

> On Thu, Jul 22, 2010 at 2:33 AM, Roy T. Fielding <[e-mail]> wrote:
>> On Jul 22, 2010, at 1:21 AM, Salvatore Loreto wrote:
>>> I see more value to work on a general solution to secure the HTTP Upgrade mechanism
>>> against cross-protocol vulnerability, instead of trying to draft something ad-hoc for WebSocket
>> 
>> The HTTP Upgrade mechanism is not vulnerable to cross-protocol attacks.
>> Other (non-HTTP) services are vulnerable to browser misdirection if
>> the browser can be directed to send arbitrary bytes to an arbitrary
>> TCP port.  That is a problem which HTTP is actually good at avoiding
>> because the first line is unique to HTTP.
> 
> HTTP is the source of a large number of cross-protocol attacks.  The
> uniqueness of the first line often does not help because other
> protocols (such as SMTP, DNS, FTP, etc) happily ignore leading junk on
> the socket that they don't understand.  Claiming HTTP is not
> vulnerably to cross-protocol attacks is just silly.

HTTP is not vulnerable.  Please understand what that means before
misdirecting accusations.  The only things vulnerable there are the
invalid and insecure implementations of SMTP, DNS, FTP, etc.
They will continue to be vulnerable no matter what we do in hybi.

> If you'd like some background reading about cross-protocol attacks
> involving HTTP, I'd invite you to read the classic paper on the
> subject:
> 
> http://www.remote.org/jochen/sec/hfpa/hfpa.pdf

I have before.  Did you read it?

  3.3	Vulnerable protocols

  Generally, all ASCII command based protocols might be vulnerable
  to this attack. This includes, but is probably not limited to:
  FTP, SMTP, NNTP, POP3, IMAP, and IRC.  Servers using binary
  protocols like SSH or DNS will generally close the connection
  if they receive anything they don’t understand. Because using
  this attack implies that there is always the HTTP protocol
  overhead at the beginning, there is no way to use this attack on
  ”binary” protocols.  Some protocols like the one used for rsh
  require that the connection originates from a TCP port smaller
  than 1024, which is generally not the case for a request
  originating from a web browser.

Just to reiterate, *other* protocol services are vulnerable to attack
from a browser *using* HTTP if those *other* protocol services do not
validate an incoming request.  This is a well-known implementation
issue with older Internet services due to excessive adherence to the
robustness principle.  It is not a vulnerability in HTTP and is not
caused by HTTP.  You can even avoid the issue entirely, using HTTP,
by implementing transfer-encoding and sending all message bodies compressed.

> There's a later paper with more interesting examples called "Extended
> HTML Form Attack Revisited", but I couldn't turn up the PDF with a
> quick search.  Collin Jackson and I also have a number of unpublished
> results in this area, all of which use HTTP to attack other protocols.

Which means the other implementations are vulnerable, not that HTTP
is vulnerable or even that other protocols are vulnerable.  This is
a trivial thing to fix on any one of those implementations, which is
why we tell those implementations that *they* have a security
vulnerability (so that the people who can fix it, will fix it).

....Roy