Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
Alfredo Pironti <alfredo@pironti.eu> Mon, 09 December 2013 16:40 UTC
Return-Path: <alfredo@pironti.eu>
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 260981AE30B for <tls@ietfa.amsl.com>; Mon, 9 Dec 2013 08:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
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 e_S2BKNWLGeN for <tls@ietfa.amsl.com>; Mon, 9 Dec 2013 08:40:43 -0800 (PST)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6411AE359 for <tls@ietf.org>; Mon, 9 Dec 2013 08:40:42 -0800 (PST)
Received: by mail-ob0-f170.google.com with SMTP id wp18so4020584obc.29 for <tls@ietf.org>; Mon, 09 Dec 2013 08:40:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TImCgECTtdKxvu6tTWVcMsFNz976GQhgLM7qe/UW2Ds=; b=gw7YZOd8NU/S8eacwd10dm3ns/+AmiWDB6AYpd/o/d9Liw6yr1cAKzRGtuOuHZHqct +qbsJEl4tlgfU4+rWImhuMLvTO4we2/O7RHFAjlNUPFeo1TrPu1LPYg75eHqXrNJLc9V BL7u89mRn72DfNP7ifvtgwmmGyBvDSp+RXurk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TImCgECTtdKxvu6tTWVcMsFNz976GQhgLM7qe/UW2Ds=; b=eZcg9DtDQyZ2/3z1k7d3AoDoPXRj06x9SJmLP5tZQxvJch6s2mCtsp0mdch4qTt8E9 RmhLGoL7a1UT0Ss/a4r176zHCfBztV0ua7ss0j4uAAI66vcpJJOHVdC/vhQPPAWdaDSG vg8gG3l0SIOTFOnj+udBftOJwHZ3/WzDdgCGAr5Ong1P6CstDrKBSqs5UqDKVEkx2jDT DdhGBjJBachMTmjRXXI/2jChO6pn1A7WqEOozBA+XzZJWjufnYYittJaBcdxaNd28w8m 3ZhQNoZvmRiCS8oStB4EorMStkZ7dDYNhwymmhyOmjohq1uYgojdMZ7nMhrTcRiWXiqF JuIg==
X-Gm-Message-State: ALoCoQm140cN079zTIBbjTczbwvQrUDp2oxCKAZVLcjmNuZpPkHtobIS0/MvCfr3z7gdczV+XpLd
MIME-Version: 1.0
X-Received: by 10.60.79.168 with SMTP id k8mr13378604oex.7.1386607237855; Mon, 09 Dec 2013 08:40:37 -0800 (PST)
Received: by 10.76.180.193 with HTTP; Mon, 9 Dec 2013 08:40:37 -0800 (PST)
X-Originating-IP: [128.93.188.195]
In-Reply-To: <CAFewVt4ws683eN8tzh1h2O+BGveEH-Efnyat4bHgkExMfX5trg@mail.gmail.com>
References: <CAFewVt5fNk9HF0uuE1Z_wD=8cme1eCuU8=VJU3RaLLCoPi2p+w@mail.gmail.com> <CALR0uiLivdKPbvWtNZCWaiFM0UFSJ-UBb2=wOc+vSodqEqgWFw@mail.gmail.com> <CAFewVt4ws683eN8tzh1h2O+BGveEH-Efnyat4bHgkExMfX5trg@mail.gmail.com>
Date: Mon, 09 Dec 2013 17:40:37 +0100
Message-ID: <CALR0uiL29jnew_pgGui8sTo6HnsPoQJy=iSESbCVEF7RF9onbg@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset="UTF-8"
Cc: Peter Gutmann <p.gutmann@auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [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 16:40:45 -0000
Hi Brian, Thanks for clarifying, I now understand the use case you were referring to. I especially missed case 1. I have further comments, that I put inline. On Mon, Dec 9, 2013 at 5:10 PM, Brian Smith <brian@briansmith.org> wrote: > On Mon, Dec 9, 2013 at 7:23 AM, Alfredo Pironti <alfredo@pironti.eu> wrote: >>> 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. >> >> I think this pre-condition makes your counter-example invalid. >> A client that only accepts valid certificates is in practice only >> implementing http2, not http2-tls-relaxed, in that client's behavior >> doesn't change. > > Let's say the client is connecting to example.org:443 using TLS. There > are two interesting possibilities: > > 1. The client could be resolving an http:// link that uses > opportunistic encryption. In this case, if the client supports > opportunistic encryption, the client would support "http2-tls-relaxed" > and "http2-tls" (and "http1-tls") and a MitM attack, if attempted, > would succeed. > > 2. The client could be resolving an https:// link. In this case, the > client would only support "http2-tls" (and "http1-tls") and a MitM > attack, if attempted, would fail in a end-user-notable way. > > With ALPN, it is trivial for the MitM to determine which case it is > and act accordingly. With NPN, it is not trivial (it requires > correlating data from multiple connections) and in many cases it may > be impossible (e.g. when an HTTP cache has stored the response with > the alternate-service upgrade header). With ALPN, the client could always send both "http2-tls-relaxed" and "http2", making its behavior indistinguishable in cases 1 and 2. Isn't this enough to make your attacker desist? For functionality, you may say that allowing "http2-tls-relaxed" in case 2 may lead the server to send an invalid certificate when it could have sent a valid one (and so one needs to distinguish the two cases). Do we have a realistic scenario of this? I mean: a server that prefers a "mitm-able" connection over a more secure one. A case where the server would send a invalid certificate to disguise its identity doesn't seem to work, because any further "http2"-only connection (from any unauthenticated client) may reveal its identity anyway. (I don't want to defend ALPN at all costs, but maybe what I propose is enough to satisfy your use case? I'd prefer to conceal the upper protocol from the attacker, but this has to be done at the same security that other TLS-protected data get, and I find NPN does not quite achieve this.) Cheers, Alfredo > >> Indeed, but under the assumption that only valid certificates are >> accepted, the behaviors coincide to "http2". > > In the case of opportunistic encryption, we would support both valid > and invalid certificates. In the case of normal "http2-tls" and > "http1-tls", we would support only valid certificates. > > Cheers, > Brian > > > -- > Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
- [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