[TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)

Brian Smith <brian@briansmith.org> Mon, 09 December 2013 13:56 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1B1ADF85 for <tls@ietfa.amsl.com>; Mon, 9 Dec 2013 05:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmdDyG8K7cvs for <tls@ietfa.amsl.com>; Mon, 9 Dec 2013 05:56:46 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C91ADF52 for <tls@ietf.org>; Mon, 9 Dec 2013 05:56:46 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id gc15so2794807qeb.7 for <tls@ietf.org>; Mon, 09 Dec 2013 05:56:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=/Mcedk7VTs/j3O/yStUrRviZ3alJloq6Ql4QsL3Iv4A=; b=SxNt0QIO98LZRLOff6VudCb7f69+xiZwbn06cYVVXLi3pAdHfG3H9RDG8ispBbFS0h Fe+ZM6xpFtd0iI0xojbBbRARo5hqtaYZZaZGFsw4LnYRc2tS8AO9OiQUfnD4jtEggliz lSISMjC1wz1XTVVNCMaBhoPZBFCRk6AnOb74XezNs6iMNYNfTAK6M+G2WSwPVOH6d4+H 8TIoeOrYXfA3e3GpyLaTwehZPVkArSFbIewuwN5yfoF6r9yz99NB/oDomRIFFEUXpMox HafwWoQukyvJ51WsMlDKJido0HcAad78pFntXps6v81EepxWXgntjFVuK6D2PBQqGf/2 8QNg==
X-Gm-Message-State: ALoCoQmbsZX87Y6xeQQ51Y6iCzcLcXZ/6WGCY34zPBqyCaGSwzIboF4ByqiS7F1IJTSM62vIG9Y6
MIME-Version: 1.0
X-Received: by 10.224.66.5 with SMTP id l5mr33928620qai.31.1386597401535; Mon, 09 Dec 2013 05:56:41 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Mon, 9 Dec 2013 05:56:41 -0800 (PST)
X-Originating-IP: [12.216.141.3]
Date: Mon, 09 Dec 2013 05:56:41 -0800
Message-ID: <CAFewVt5fNk9HF0uuE1Z_wD=8cme1eCuU8=VJU3RaLLCoPi2p+w@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Xiaoyong Wu <X.Wu@f5.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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: Mon, 09 Dec 2013 13:56:50 -0000

On Mon, Nov 18, 2013 at 9:58 PM, Brian Smith <brian@briansmith.org> wrote:
> I think that in many cases, traffic analysis that relies on timing
> information will be able to tell with a high degree of accuracy which
> protocol has been selected for use on the connection. However, traffic
> analysis cannot tell us what protocols were offered but *not*
> selected.

I have found a particularly interesting case where ALPN is less secure than NPN.

Please see http://tools.ietf.org/html/draft-nottingham-http2-encryption-01#section-2.1
(read the whole document, but section 2.1 is especially interesting).
That document defines a mechanism wherein, through protocol
negotiation, a web browser and server can agree on a "relaxed" form of
TLS for HTTP where the client does not authenticate the server's
certificate. The goal is to enable a form of opportunistic encryption
to HTTP.

The case where the server does not use a certificate that the client
would verify correctly as it would in the "normal" HTTPS case is not
interesting. However, the case where opportunistic encryption is being
used with a certificate that *is* valid (as defined by RFC5280, et
al.) is interesting.

Consider the case of an attacker that is willing and able to actively
MitM traffic but does not want to get caught, so they are only willing
to actively MitM traffic when they know they can get away with it. I
believe this describes a lot of attackers, including the ones that are
motivating the perpass effort.

Consider a client that uses the ALPN extension to advertise that it
supports http2-tls-relaxed and regular http2. The presence of the
"http2-tls-relaxed" token in the ALPN extension in the ClientHello is
effectively saying "You will get away with performing an active MitM
attack against me" i.e. "Please MitM me, sir." The type of attacker
describe above simply needs to MitM any/all such connections, choosing
the "http2-tls-relaxed" protocol for all of them, while leaving alone
all connections that do not advertise the http2-tls-relaxed protocol.

Now, consider a client and server that agree to use NPN to negotiate
between "http2-tls-relaxed" and regular http2. In NPN, the server
advertises which protocols it supports, and the client chooses which
protocol to use. Thus, the MitM does not have ultimate control over
which protocol is selected. If the active MitM tries to offer only
"http2-tls-relaxed" on a connection to force a MitM-able connection,
it runs the risk of getting caught if/when the client doesn't support
"http2-tls-relaxed".

Further, in the NPN case, a pssive MitM cannot even learn whether
http2-tls-relaxed or regular authenticated http2 was negotiated on the
connection, because the client's choice of "http2-tls-relaxed" vs
"http2" was hidden from the passive MitM. Thus, a passive MitM cannot
even learn whether a particular client supports the
"http2-tls-relaxed" option or not. Hiding this from the attacker is
useful because it makes it harder for the attacker to coordinate
future (active) attacks.

Note that the choice between "http2-tls-relaxed" and "http2" only
affects (AFAICT) the validation of the certificate. It doesn't change,
in a detectable way, the data that is sent on the connection.
Consequently, traffic analysis cannot be used to differentiate
"http2-tls-relaxed" from "http2". Thus, we've found a counterexample
to disprove the claim that we don't need to hide what protocol was
used because traffic analysis can always be used to determine which
protocol was negotiated.

Cheers,
Brian