IETF Logo Mail Archive

Re: [hybi] Websocket: two protocols into one, and Internet rules broken

Joel Martin <hybi@martintribe.org> Thu, 16 June 2011 21:24 UTC

Return-Path: <buskanaka@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BFF11E82F9 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level:
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPgxiQ+4EbOy for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:24:25 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D17E11E8234 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:24:25 -0700 (PDT)
Received: by eye13 with SMTP id 13so195746eye.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:24:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Bd+3AWk2GbhzyQoRsaLu6IoNEulaxAxyt8NZaFiyQrE=; b=LK4eXgQSB0HsI5LeDPwXVGbx98D9HAizombRO3Gv/q9YjkGs92X7ICj6PpbloEtfRe f3N0QcQNwB+Pw2g1jGc9xMMElhdvuHIiZgk5g00uf0aDKlmOKMoMZwAOimhnvq1ksgoM iLtRhcWTs1/wzy6Rb0taffBdPVTLpS2O8zexc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=jPVs8ZEPC1+3hCH7av1sbYcwvboNLAH1Mm/zBR8FPMHeLhfjGo3xFg2UoAm82Lp/5c m66QG4K+ThsIiXbJwcekMR/RhemY1/aL557ZivgUH16L60Vaamkh9lnpoUqCeO/mzInK djZXLhIfFJstMEAJHEAuBfmcsbMauBMRBSbr4=
Received: by 10.14.29.71 with SMTP id h47mr631941eea.106.1308259464374; Thu, 16 Jun 2011 14:24:24 -0700 (PDT)
MIME-Version: 1.0
Sender: buskanaka@gmail.com
Received: by 10.14.127.1 with HTTP; Thu, 16 Jun 2011 14:24:04 -0700 (PDT)
In-Reply-To: <20110616205147.GA29656@1wt.eu>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com> <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com> <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com> <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com> <20110616205147.GA29656@1wt.eu>
From: Joel Martin <hybi@martintribe.org>
Date: Thu, 16 Jun 2011 16:24:04 -0500
X-Google-Sender-Auth: OAa3rp-y86w1D4q3t6w0UVP-Nv0
Message-ID: <BANLkTimE5SjYzE4Xd4t3XCvBF9AqSQPfww@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Content-Type: multipart/alternative; boundary="90e6ba5bbae5a5e9e804a5dae4ed"
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 21:24:26 -0000

On Thu, Jun 16, 2011 at 3:51 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Jun 16, 2011 at 01:39:35PM -0700, Ian Fette
> (????????????????????????) wrote:
> > Historically, many servers are lazy. They will not bother validating
> > whatever the client sends, and will just return some value and then get
> > exploited. By forcing the server to prove something to the client, we
> > essentially also force the server to validate at least part of the
> client's
> > handshake (rather than just hardcoding in some 101 Upgrade WS response).
> So,
> > by making the server prove something to the client, it's a way of forcing
> > the server to actually take some steps that have a side effect of
> protecting
> > it (e.g. this /forces/ the server to parse the Sec-WebSocket-Key header.)
>
> And also to ensure that the response was not delivered by a lazy cache.


Sure, that makes sense... for the WebSocket client connection case. But what
how does it help in the non-WebSocket client case (which the paragraph is
talking about).

Regards,

Joel Martin

v2.23.0 | Report a Bug | By Email