Re: [hybi] Extensibility mechanisms?

Willy Tarreau <w@1wt.eu> Thu, 22 July 2010 05:54 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BEB3A69A8 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 22:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.883
X-Spam-Level:
X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=-1.440, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_24=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWfuqimeiZKU for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 22:54:43 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 57FD43A6862 for <hybi@ietf.org>; Wed, 21 Jul 2010 22:54:42 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6M5sqIM009524; Thu, 22 Jul 2010 07:54:52 +0200
Date: Thu, 22 Jul 2010 07:54:52 +0200
From: Willy Tarreau <w@1wt.eu>
To: Adam Barth <ietf@adambarth.com>
Message-ID: <20100722055452.GL7174@1wt.eu>
References: <AANLkTikkfdlUxQ0MGNvVQKa5gfovkGHWdCgyN9juKSQJ@mail.gmail.com> <4C462F9E.9030207@caucho.com> <Pine.LNX.4.64.1007212153110.7242@ps20323.dreamhostps.com> <AANLkTiku76oSucTNDFdwgsFBNFa_cCpC-YktTnMfX47-@mail.gmail.com> <4C479130.4020500@caucho.com> <AANLkTikLDjBP-Xs5t6TxmJuq4nG8jwThQ=n34B4cEmup@mail.gmail.com> <4C479CE4.6070805@caucho.com> <AANLkTims1er0Rbv0ysP4gRs1Kd0He8hapHeJ3nON=JQa@mail.gmail.com> <4C47C5B0.3030006@caucho.com> <AANLkTi=ND-FOH8OoD=TCbiyeSZ-h0LhxQBXN5w-2hfvj@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AANLkTi=ND-FOH8OoD=TCbiyeSZ-h0LhxQBXN5w-2hfvj@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Extensibility mechanisms?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jul 2010 05:54:44 -0000

Hi Adam,

On Wed, Jul 21, 2010 at 09:40:00PM -0700, Adam Barth wrote:
> The more I read on this list, the more I think that folks here don't
> understand the requirements on the protocol, especially the security
> requirements.  That's understandable if you haven't worked extensively
> with the browser security model.  Fortunately, Ian is an expert on
> these topics and has more time to reply to this list than I do.

Unfortunately, if neither of you two can take some time to give concrete
examples of what you're trying to protect against, you will constantly
see proposals that don't fit your requirements.

My understanding of cross-protocol attacks (please correct me if I'm
wrong) is the fact that a browser can be tricked into sending specially
crafted data to an IP:port which it believes is one protocol while it's
another one, the typical example being a form designed to send a POST
to an SMTP server, which will ignore all the HTTP part it does not
understand and will happily apply the body's data as SMTP commands. It's
easy to put web sites on the net that build such forms so that browsers
which get there are accidentely used to perform that attack.

If this is indeed the issue you're talking about, then I don't see why
the HTTP-based handshake could be a problem there. It's not more than
any other common HTTP request, it's even better in that no data should
flow until the server has correctly replied indicating proper support
for the protocol.

Basically we should get this :

  - the client sends an HTTP handshake (headers only)
  - the server responds with its HTTP handshake
  - the client checks the response and only then forwards
    data.

This standard scheme protects against cross-protocol attacks (as I
understand them) as the client does not send anything unless the
server proves its ability to understand the client protocol. Also,
the request and response are different HTTP messages, so a simple
echo server can't return the valid handshake by accident.

So with this, I'm sorry I don't see what class of cross-protocol
attacks remain and which ones we should actively protect against,
so if you have good examples, it would be nice if you could take
some time to share them.

Best regards,
Willy