[TLS] Preventing cross-protocol attacks without NPN (was: Request for review: Next Protocol Negotiation Extension)

Adam Barth <ietf@adambarth.com> Thu, 19 August 2010 08:18 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5BCF3A68EC for <tls@core3.amsl.com>; Thu, 19 Aug 2010 01:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.386
X-Spam-Level:
X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=-1.275, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, J_CHICKENPOX_33=0.6, SARE_FWDLOOK=1.666]
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 AQ4lwOKRmy7K for <tls@core3.amsl.com>; Thu, 19 Aug 2010 01:18:14 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 30E943A67E1 for <tls@ietf.org>; Thu, 19 Aug 2010 01:18:14 -0700 (PDT)
Received: by ywi4 with SMTP id 4so516533ywi.31 for <tls@ietf.org>; Thu, 19 Aug 2010 01:18:49 -0700 (PDT)
Received: by 10.90.63.1 with SMTP id l1mr1000385aga.146.1282205928556; Thu, 19 Aug 2010 01:18:48 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id g31sm1186957ibh.16.2010.08.19.01.18.46 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 01:18:47 -0700 (PDT)
Received: by iwn3 with SMTP id 3so1759200iwn.31 for <tls@ietf.org>; Thu, 19 Aug 2010 01:18:46 -0700 (PDT)
Received: by 10.231.191.147 with SMTP id dm19mr10886845ibb.6.1282205926257; Thu, 19 Aug 2010 01:18:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.60.18 with HTTP; Thu, 19 Aug 2010 01:18:26 -0700 (PDT)
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 19 Aug 2010 01:18:26 -0700
Message-ID: <AANLkTi=pXFM7HnXJCuJUoKVZKnX1HijQMRr3nHFefHZD@mail.gmail.com>
To: Nathaniel W Filardo <nwf@cs.jhu.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] Preventing cross-protocol attacks without NPN (was: Request for review: Next Protocol Negotiation Extension)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Aug 2010 08:18:15 -0000

[I've changed the subject because Nathaniel's reply was quite
thoughtful and I suspect many folks have tuned out of the original
thread due to its size.]

On Thu, Aug 19, 2010 at 12:30 AM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
> On Wed, Aug 18, 2010 at 01:59:42PM -0700, Adam Barth wrote:
>> > Further, protocols inside TLS are already implicitly weakly protected if the
>> > endpoints require authentication.  There isn't any way that my web browser
>> > can carry out an HTTPS cross-protocol attack against an SMTPS server, unless
>> > the attacker already knows the appropriate SMTP credentials or I have client
>> > certs accepted by the SMTPS server loaded in my browser.  Any attempt the
>> > browser makes at authenticating via HTTP mechanisms is going to be ignored
>> > by the SMTPS server.  If I require STARTTLS for SMTP, I'm in an even better
>> > position than if I were using just SMTPS, as the client cert issue is gone.
>> > (Would that the HTTP world actually believed in Upgrade: for starting TLS!)
>>
>> That's not an accurate understanding of how cross-protocol attacks
>> work.  Whether or not we're inside a TLS tunnel, the issues are the
>> same.  One way to understand this is to think about a VPN.  Clearly it
>> doesn't matter whether the cross-protocol attacks are taking place
>> inside an IPv6 tunnel, does it?
>
> 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?

Yes, precisely.

> For concrete example, in the case of P=SMTP and Q=HTTP, M requests that C
> make a POST request to S; S in turn will typically ignore C's HTTP
> verb/object/version line and any headers.  Reason being, HTTP verbs and
> options (which all involve a : before whitespace) don't overlap with the
> SMTP vocabuarly, and so S ignores them as malformed lines.  Note that TLS
> NPN does _nothing_ to help here, since TLS is not involved.  _Every_
> cross-protocol attack I am aware of is of this class; if you can provide
> citations otherwise, I would love to see them.
>
> Now, we can ignore (P,Q) being (SMTP,HTTPS) or (SMTPS,HTTP) since neither
> off-diagonal form is going to be able to bring up the TLS session to
> everybody's satisfaction.
>
> (P,Q)=(SMTPS,HTTPS) with neither C nor S expecting to see authentication
> essentially behaves as (SMTP,HTTP), I agree; TLS NPN helps here.

More precisely, it would if either SMTPS or HTTPS required NPN (which
they don't).  It really helps more with (WebSockets, X) for all X
because WebSockets requires NPN and therefore will neither confuse nor
be confused by any other protocol.

> (P,Q)=(SMTPS,HTTPS) with S expecting C to authenticate will result in a
> cross-protocol attack iff either of the following conditions are met:
>  1. C has a client certificate which S will accept and S does not expect
>     in-band authentication.
>  2. M has been able to specifically craft a P-message involving suitable
>     credentials for C's use in this transmission.
>
> Neither of these are terribly realisitic (in my mostly speculative opinion).

That's the flaw in your reasoning.  Both are certainly possible, but
(2) is more likely.  Consider the case of HTTP attacking FTP, which we
have experience with in the wild.  Even though FTP requires the client
to authenticate (in this case), an attacker can craft an HTTP request
that tricks the server into thinking the request contains FTP
authentication credentials.  (It's a fun exercise to make this work
with your favorite FTP server implementation.)

> Note that if S's knobs are set such that P requires a challenge-response
> authentication pass, that M will, whp, be unable to successfully take option
> 2.  TLS NPN doen't hurt here, but there's not a lot of headroom for it to
> help -- the connection is likely going to fail anyway.

I wouldn't be so sure.  With HTTP keepalive, an attacker might well be
able to read back bytes from the server and then formulate a second
request that contains the response to the server's challenge.  You're
right that this gets harder, but it's quite far from impossible.

Constructing these attacks is a somewhat subtle business.  It feels a
lot like putting a square peg into a round hole, but we have plenty of
evidence that these attacks exist.  (I don't mean to keep harping on
HTTP attacking other protocols, that's just what we have the most
experience with.)

> That was the only claim I was making.

I understand why you came to the conclusions you did, but this
business is a bit more subtle than it appears at first, much like
achieving mutual authentication over an untrusted network.  ;)

> In all, while I have no intrinsic objection to TLS NPN, it seems to me that
> the solution should be independent of the cryptographic provisioning layer,
> since it demonstrably has nothing to do with said functionality.

If you have a solution that works as well as (or better than) TLS+NPN,
the HyBi working group would likely be quite interested in hearing
your proposal.  You're certainly right that one could imagine
implementing this functionality if we had a better extension mechanism
in TCP, but, sadly, we don't.  Currently, TLS+NPN is the best design
I've seen (I suspect because TLS has a forward-looking extension
mechanism, not because of its encryption facilities).

Kind regards,
Adam