[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
- [TLS] How ALPN makes the http2-tls-relaxed option… Brian Smith
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Alfredo Pironti
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Brian Smith
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Alfredo Pironti
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Watson Ladd
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Stephen Farrell
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Martin Thomson
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Andrei Popov
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Martin Thomson
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Eric Rescorla
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Brian Smith
- Re: [TLS] How ALPN makes the http2-tls-relaxed op… Martin Thomson