Re: [TLS] Preventing cross-protocol attacks without NPN (was: Request

Adam Barth <> Thu, 19 August 2010 17:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F5783A67F1 for <>; Thu, 19 Aug 2010 10:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.803
X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jSA0Rfs+edgS for <>; Thu, 19 Aug 2010 10:16:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 26DCD3A68EA for <>; Thu, 19 Aug 2010 10:15:59 -0700 (PDT)
Received: by fxm18 with SMTP id 18so1387464fxm.31 for <>; Thu, 19 Aug 2010 10:16:34 -0700 (PDT)
Received: by with SMTP id v13mr63482far.94.1282238194252; Thu, 19 Aug 2010 10:16:34 -0700 (PDT)
Received: from ( []) by with ESMTPS id a6sm806425faa.20.2010. (version=SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 10:16:33 -0700 (PDT)
Received: by pzk6 with SMTP id 6so972601pzk.31 for <>; Thu, 19 Aug 2010 10:16:31 -0700 (PDT)
Received: by with SMTP id f15mr150587wfd.14.1282238191183; Thu, 19 Aug 2010 10:16:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 19 Aug 2010 10:16:10 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Adam Barth <>
Date: Thu, 19 Aug 2010 10:16:10 -0700
Message-ID: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] Preventing cross-protocol attacks without NPN (was: Request
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Aug 2010 17:16:01 -0000


I think you're right that we could fix these problems by changing the
browser security model to something more like the Java security model.
 However, the browser security model isn't going anywhere any time

Kind regards,

On Thu, Aug 19, 2010 at 6:48 AM, Martin Rex <> wrote:
> Nathaniel W Filardo <> wrote:
>> The particular class of attacks you're worried about all involve an agent,
>> C, making requests to a server S, on behalf of some untrusted third party,
>> M.  Further, S thinks that it is speaking P and C thinks that it is speaking
>> Q, with P != Q.  It happens to be that S's interpretation of P is compatible
>> with C's production of Q.  Is that not an accurate understanding?
> "involve an agent C".  It's about a promiscuous zombie call "web browser"
> (not necessarily Mr. Smith in a black suit). ;-)
> The last "cross-protocol attack" I complained about was TLS endpoints
> chasing AIA URLs from untrusted end-entity certs when faced with
> incomplete certificate chains.  There the scenario involved a client
> (browser), a server (online bank) who trust each other and a secure
> protocol (TLS), which was susceptible to outside(!) attackers injecting
> a crafted ServerHello+ServerCertificate handshake message into a newly
> established TCP connection.
> The "cross-protocol attack" mentioned with WebSocket, on the other hand,
> is about a completely different threat scenario.  There, the worry
> is about rightful peers, i.e. Servers attacking clients by serving
> them URLs and active content to coerce them in connecting to services
> that they shouldn't be connecting to.
> Personally, I don't think NPN is going to improve anything.  It is
> just going to make things slightly more obscure, but by misleading
> the consumers of the technology about where there is the flaw in
> their architecure, they're going to significantly increase the
> damage in the long run.
> Blacklisting known bad stuff is a race that you can not win.
> Probably no one would suggest to "enhance" MUA to roam the internet
> and collect more spam to present to the user.  Browsers do just that,
> they will happily download and annoy end users with significantly
> larger amounts of spamvertisement than most users would agree to
> when asked.
> For Java applets there was originally a security model that the
> applet could only callback to the site where it came from.
> Security-wise this was a sensible approach.  If something similar
> had been done for HTML pages, XSS would be a non-problem and
> neither would there be any cross-protocol issues.
> Since the services that are listening for plaintext protocols today
> are not going to go away anytime soon, why do you think the situation
> would improve with NPN?  Is there a "once WebSockets -- forever WebSockets"
> requirement, that mixing content from "old" (port 80) and
> "new" Web (=through WebSockets) is going to be entirely prohibited?
> Cross-Protocol attacks are very very old stuff.
> Back in the old days of the IP-Protocols, there were services
> such as "chargen 19/udp" and "echo 7/udp" and IIRC, you only needed
> to send a UDP datagram with a crafted source ip/port to chargen
> to make two machines saturate a network link.
> The WebSockets + NPN architecture sounds like a inetd with builtin
> TLS and out-of-band protocol signaling instead of relying on the
> implicit assumptions of well known ports.
> But this approach, especially when _NOT_ sending the next protocol
> in the ClientHello (in clear text), is in direct conflict with the
> idea to perform server endpoint identification for TLS in a fashion
> that clearly distinguishes services by their certificate (attributes),
> like ExtendedKeyUsage (EKUs) and Service SubjectAltNames.
> Personally, I really dislike the idea of requiring all application
> services on a Host to be single-admin'ed and all authentication
> and authorization at the TLS layer to be unconditionally host-wide.
> That comes close to killing TLS client certificates as a means to
> authenticate users if you have differing requirements for applications.
> The protection that you're looking for should be provided by IPsec,
> not a multiplexing TLS+NPN-enriched WebSockets inetd.
> Seperating services on a host into individual processes with
> only those privileges and the level of user authentication and
> user authorization that these services actually need is sensible
> risk management.  Terminating and dispatching EVERY network
> connection to a machine in a single application puts us back
> into the MS-DOS area (lack of process seperation).
> And what exactly do you mean by "Next Protocol".  A lot of stuff
> uses HTTP these days, and if you really only distinguish the
> next protocol level, then there still is a lot of cross-protocol
> attack surface left.  Doesn't SOAP use HTTP as well?
> I know that my DSL-router is VERY open-minded to SOAP-requests
> for administrative purposes (and no, it doesn't require authentication
> for many actions -- different to the administrative WebUI).
> -Martin