Re: [hybi] Extensibility mechanisms?
Maciej Stachowiak <mjs@apple.com> Thu, 22 July 2010 17:10 UTC
Return-Path: <mjs@apple.com>
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 0DFF43A67EE for <hybi@core3.amsl.com>; Thu, 22 Jul 2010 10:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.268
X-Spam-Level:
X-Spam-Status: No, score=-106.268 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 7ujfM3znGmpq for <hybi@core3.amsl.com>; Thu, 22 Jul 2010 10:10:22 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 2C2463A676A for <hybi@ietf.org>; Thu, 22 Jul 2010 10:10:22 -0700 (PDT)
Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id DCFDFA4B2022 for <hybi@ietf.org>; Thu, 22 Jul 2010 10:10:39 -0700 (PDT)
X-AuditID: 11807136-b7c9dae000000fcd-a8-4c487b8f30d5
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id 3F.5C.04045.F8B784C4; Thu, 22 Jul 2010 10:10:39 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_SeuBzdqI7OgB32vNsj5lUQ)"
Received: from [17.151.96.25] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L5Y00DI5YDRAGA0@elliott.apple.com> for hybi@ietf.org; Thu, 22 Jul 2010 10:10:39 -0700 (PDT)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <AANLkTingCdW6aXjw2xVEuZ9L4RkT5dD2ncJtvrytQFbH@mail.gmail.com>
Date: Thu, 22 Jul 2010 10:10:38 -0700
Message-id: <79D7AADB-A502-4A86-A2CA-18F24FAF0EF1@apple.com>
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> <20100722055452.GL7174@1wt.eu> <F412C956-038F-400D-A431-C42B4C7B829C@apple.com> <AANLkTingCdW6aXjw2xVEuZ9L4RkT5dD2ncJtvrytQFbH@mail.gmail.com>
To: Mike Belshe <mike@belshe.com>
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAQAAAZE=
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 17:10:24 -0000
On Jul 22, 2010, at 8:07 AM, Mike Belshe wrote: > BTW - Isn't the creation of this problem really because we allow arbitrary UTF-8 written by the JS application? If we had a true framing layer (where frames have headers, instead of allowing UTF-8), would these attacks be real? It seems to me that the simplest frame header would be sufficient to prevent all of these attack vectors, but the frame headers could contain nonces or whatever other security information is needed too. I think it would be unwise to depend on a framing layer as a primary defense. First, who can say whether HTTP services would be vulnerable to data that happens to also be properly framed WebSocket messages? I wouldn't bet on it myself. Second, this does nothing to protect against using HTTP to attack WebSocket services. > The reason I mention this is because as we look to using a TLS/NPN, we can potentially get rid of the first round trip. There was a lot of suppor for that idea within the group. But, we can *only* do so if we don't have JS able to write directly to the socket. If JS is able to write UTF-8 to the socket, then skipping the first round trip opens a security vulnerability as depicted by Maciej & Adam here. With TLS/NPN, I expect the handshake would fail at the TLS level in case of a cross-protocol attack (either WebSocket vs HTTP or HTTP vs WebSocket), and therefore no attacker-controlled content would ever be sent. Regards, Maciej > > Mike > > > On Thu, Jul 22, 2010 at 12:18 AM, Maciej Stachowiak <mjs@apple.com> wrote: > > On Jul 21, 2010, at 10:54 PM, Willy Tarreau wrote: > > > 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. > > There's at least three kinds of concerns about cross-protocol attacks and the WebSocket protocol, in the case where the client is the browser: > > 1) Hostile JS code running in the browser may use the browser's WebSocket client code to try to attack existing HTTP resources, if it can make a request that looks sufficiently like HTTP. > 2) Hostile JS code running in the browser may use the browser's WebSocket client code to try to attack existing non-HTTP servers, if it can make a request that looks sufficiently like the service in question. > 3) Hostile JS code running in the browser may use the browser's HTTP client code (e.g. via XMLHttpRequest) to try to attack newly created WebSocket servers, if it can make a request that looks sufficiently like WebSocket. > > There is also another orthogonal dimension to the threat space: > > A) Attacks on confidentiality, where the attacker is trying to get access to information from the resource being attacked which he or she should not be able to obtain. > B) Attacks on integrity, where the attacker is attempting to inject commands into a resource, without necessarily caring about getting a response back. > > > Cross-protocol attacks were much discussed earlier in the year, and I gave some sketches of attack scenarios here: > http://www.ietf.org/mail-archive/web/hybi/current/msg01198.html > > > > > > 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. > > What's "the HTTP-based handshake"? We have had several proposals for handshakes that start out looking like HTTP. They are not all equally effective in protecting against cross-protocol attacks, though some of them do have some protection.. > > Although I am not an expert on cross-protocol attacks, one thing I have learned is that the issues can be *extremely* subtle. This leads me to conclude that it's better to err on the side of caution, and design the protocol to be even more robust against such threats than we think is strictly necessary. > > I believe the TLS-based handshake (as proposed by Adam) is more robust than solutions involving nonces and challenge/response built into an HTTP-like handshake. The reason for this is that it's hard for the attacker to control the bytes sent, other than to cause the initiation of a TLS handshake, which is something that all network services are already exposed to by browsers. The attacker cannot get to the next-level protocol running over TLS unless the server explicitly opts in. With HTTP-based schemes, it takes much more care to avoid sending information as the "wrong" protocol. > > However, HTTP-based challenge-response solutions are definitely better than not trying to address the issue at all. > > Regards, > Maciej > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi >
- [hybi] Extensibility mechanisms? Justin Erenkrantz
- Re: [hybi] Extensibility mechanisms? Thomson, Martin
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] Extensibility mechanisms? Justin Erenkrantz
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Justin Erenkrantz
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Maciej Stachowiak
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Extensibility mechanisms? Thomson, Martin
- Re: [hybi] Extensibility mechanisms? Roberto Peon
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Julian Reschke
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Julian Reschke
- Re: [hybi] Extensibility mechanisms? Martin J. Dürst
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- [hybi] HTTP is not a disaster. Was: Extensibility… Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] Extensibility mechanisms? Jamie Lokier
- Re: [hybi] Extensibility mechanisms? Julian Reschke
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] HTTP is not a disaster. Was: Extensibi… Pieter Hintjens
- Re: [hybi] Extensibility mechanisms? Pieter Hintjens
- Re: [hybi] Extensibility mechanisms? Bjoern Hoehrmann
- [hybi] NAT reset recovery? Was: Extensibility mec… Markus.Isomaki
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] Extensibility mechanisms? Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Vladimir Katardjiev
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Vladimir Katardjiev
- [hybi] WebSocket, TLS and intermediaries Vladimir Katardjiev
- Re: [hybi] Extensibility mechanisms? Roberto Peon
- Re: [hybi] Extensibility mechanisms? Roberto Peon
- Re: [hybi] Extensibility mechanisms? Julian Reschke
- Re: [hybi] Extensibility mechanisms? Pieter Hintjens
- Re: [hybi] NAT reset recovery? Was: Extensibility… Markus.Isomaki
- Re: [hybi] NAT reset recovery? Was: Extensibility… Pieter Hintjens
- Re: [hybi] NAT reset recovery? Was: Extensibility… Markus.Isomaki
- Re: [hybi] NAT reset recovery? Was: Extensibility… Pieter Hintjens
- Re: [hybi] NAT reset recovery? Was: Extensibility… Markus.Isomaki
- Re: [hybi] NAT reset recovery? Was: Extensibility… Pieter Hintjens
- Re: [hybi] NAT reset recovery? Was: Extensibility… Greg Wilkins
- Re: [hybi] NAT reset recovery? Was: Extensibility… Vladimir Katardjiev
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Pieter Hintjens
- Re: [hybi] NAT reset recovery? Was: Extensibility… Pieter Hintjens
- Re: [hybi] NAT reset recovery? Was: Extensibility… Thomson, Martin
- Re: [hybi] NAT reset recovery? Was: Extensibility… Markus.Isomaki
- Re: [hybi] NAT reset recovery? Was: Extensibility… Thomson, Martin
- Re: [hybi] NAT reset recovery? Was: Extensibility… Vladimir Katardjiev
- Re: [hybi] NAT reset recovery? Was: Extensibility… Dave Cridland
- Re: [hybi] NAT reset recovery? Was: Extensibility… Markus.Isomaki
- Re: [hybi] NAT reset recovery? Was: Extensibility… Markus.Isomaki
- Re: [hybi] NAT reset recovery? Was: Extensibility… Dave Cridland
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] NAT reset recovery? Was: Extensibility… Jamie Lokier
- Re: [hybi] WebSocket, TLS and intermediaries Ian Hickson
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] Extensibility mechanisms? John Tamplin
- Re: [hybi] Extensibility mechanisms? Roberto Peon
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] Extensibility mechanisms? Jack Moffitt
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] WebSocket, TLS and intermediaries Mike Belshe
- Re: [hybi] WebSocket, TLS and intermediaries Maciej Stachowiak
- Re: [hybi] WebSocket, TLS and intermediaries John Tamplin
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] WebSocket, TLS and intermediaries Roberto Peon
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] WebSocket, TLS and intermediaries Roberto Peon
- Re: [hybi] Extensibility mechanisms? Roberto Peon
- Re: [hybi] WebSocket, TLS and intermediaries Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Thomson, Martin
- Re: [hybi] WebSocket, TLS and intermediaries Thomson, Martin
- Re: [hybi] Extensibility mechanisms? Jamie Lokier
- Re: [hybi] WebSocket, TLS and intermediaries Maciej Stachowiak
- Re: [hybi] WebSocket, TLS and intermediaries Willy Tarreau
- Re: [hybi] WebSocket, TLS and intermediaries Willy Tarreau
- Re: [hybi] WebSocket, TLS and intermediaries Willy Tarreau
- Re: [hybi] WebSocket, TLS and intermediaries Willy Tarreau
- Re: [hybi] Extensibility mechanisms? Willy Tarreau
- Re: [hybi] Extensibility mechanisms? Willy Tarreau
- Re: [hybi] Extensibility mechanisms? Roberto Peon
- Re: [hybi] WebSocket, TLS and intermediaries Julian Reschke
- Re: [hybi] Extensibility mechanisms? Simone Bordet
- Re: [hybi] Extensibility mechanisms? Simone Bordet
- Re: [hybi] WebSocket, TLS and intermediaries Maciej Stachowiak
- Re: [hybi] WebSocket, TLS and intermediaries Willy Tarreau
- Re: [hybi] WebSocket, TLS and intermediaries Maciej Stachowiak
- Re: [hybi] Extensibility mechanisms? Ian Hickson
- Re: [hybi] WebSocket, TLS and intermediaries Ian Hickson
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] WebSocket, TLS and intermediaries Mike Belshe
- Re: [hybi] WebSocket, TLS and intermediaries Greg Wilkins
- Re: [hybi] WebSocket, TLS and intermediaries Willy Tarreau
- Re: [hybi] Extensibility mechanisms? Maciej Stachowiak
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Maciej Stachowiak
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Maciej Stachowiak
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] WebSocket, TLS and intermediaries Roberto Peon
- Re: [hybi] Extensibility mechanisms? Willy Tarreau
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Extensibility mechanisms? Willy Tarreau
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Maciej Stachowiak
- [hybi] Upgrade Mechanism and HasMat (was Re: Exte… Salvatore Loreto
- Re: [hybi] Extensibility mechanisms? Willy Tarreau
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Roy T. Fielding
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Salvatore Loreto
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Willy Tarreau
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Dave Cridland
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Willy Tarreau
- Re: [hybi] Extensibility mechanisms? Willy Tarreau
- Re: [hybi] Extensibility mechanisms? John Tamplin
- Re: [hybi] Extensibility mechanisms? Willy Tarreau
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Dave Cridland
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Dave Cridland
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] Extensibility mechanisms? John Tamplin
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Maciej Stachowiak
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Maciej Stachowiak
- Re: [hybi] Extensibility mechanisms? Maciej Stachowiak
- Re: [hybi] Extensibility mechanisms? Maciej Stachowiak
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Adam Barth
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Extensibility mechanisms? Mike Belshe
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Roy T. Fielding
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … John Tamplin
- Re: [hybi] Extensibility mechanisms? Willy Tarreau
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Roy T. Fielding
- Re: [hybi] Extensibility mechanisms? Simon Pieters
- Re: [hybi] Extensibility mechanisms? Greg Wilkins
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Greg Wilkins
- Re: [hybi] Upgrade Mechanism and HasMat (was Re: … Maciej Stachowiak
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Jamie Lokier
- Re: [hybi] Extensibility mechanisms? Jamie Lokier
- Re: [hybi] Extensibility mechanisms? Jamie Lokier
- Re: [hybi] Extensibility mechanisms? Jamie Lokier
- Re: [hybi] Extensibility mechanisms? Adam Barth
- Re: [hybi] Extensibility mechanisms? Scott Ferguson
- Re: [hybi] WebSocket, TLS and intermediaries Patrick McManus