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

From: Brian Smith <[email-masked]>
Date: Mon, 9 Dec 2013 05:56:41 -0800

On Mon, Nov 18, 2013 at 9:58 PM, Brian Smith <[email-masked]> 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

---

From: Alfredo Pironti <[email-masked]>
Date: Mon, 9 Dec 2013 16:23:11 +0100

> used with a certificate that *is* valid (as defined by RFC5280, et

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.

> affects (AFAICT) the validation of the certificate.

Indeed, but under the assumption that only valid certificates are
accepted, the behaviors coincide to "http2".

Best,
Alfredo

---

From: Brian Smith <[email-masked]>
Date: Mon, 9 Dec 2013 08:10:27 -0800

> implementing http2, not http2-tls-relaxed, in that client's behavior

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).

> 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)

---

From: Alfredo Pironti <[email-masked]>
Date: Mon, 9 Dec 2013 17:40:37 +0100

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.

> 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

---

From: Watson Ladd <[email-masked]>
Date: Mon, 9 Dec 2013 08:59:55 -0800

Why exactly does the client need to tell the server if it will
validate the cert or not?
Either the server has a cert that will validate, in which case it can
use it always, or not, in which case
there isn't a choice. Why signal to the world "I CAN BE FOOLED"?
Sincerely,
Watson Ladd

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Dec 2013 17:11:40 +0000

> there isn't a choice. Why signal to the world "I CAN BE FOOLED"?

I'm not sure there's that much point in getting into
the specifics of Mark's scheme, since the httpbis wg
haven't decided to go down that road yet. (They might
but then they might do something else, who knows.)

For me (wearing no hats) it seems like standardising
NPN might take away energy from tls1.3 and/or slow
its deployment, which'd be a concern.

I'd also think that in the real case of ALPN and
HTTP/2.0 it'll be entirely obvious which protocol is
being negotiated just from the sizes of the packets
for any tls version <= 1.2 so any privacy loss or
gain is extremely minor to non-existent for now.
(That's because of HTTP/2.0 being binary etc.)

And I'd hope tls1.3 will be where we'd get significant
privacy gains in a more well thought out manner, e.g.
perhaps addressing the kind of application traffic
padding that Alfredo's draft described as a built-in
feature. (Or some equivalent.)

I've not thought through the negotiation thing though,
i.e. as to the impact of clients still having to be
able to do tls1.2 & ALPN for HTTP/2.0 even after tls1.3
is available on both ends. That does sound like its
worth thinking through but I'd hope could be handled
well in tls1.3 while still getting the privacy
benefits.

S.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Dec 2013 09:16:55 -0800

> certificate. The goal is to enable a form of opportunistic encryption

My feedback to Mark on this point was that this negotiation was
completely unnecessary.

A server already has a way to signal that it doesn't care about
certain security properties of a resource.  It does that by omitting
the 's' in the resource URL.

A client is then left to decide whether it cares about those
properties.  What requirements are then placed on the subsequent
interactions are up to the client.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 9 Dec 2013 20:59:54 +0000

To add to Alfredo's points, the problem is that http2-tls-relaxed is explicitly MITM-able by design, and is intended only to prevent passive attacks.

If I understand correctly, an active attacker can prevent http2-tls-relaxed from happening by manipulating Alt-Svc headers, regardless of whether ALPN or NPN is used.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Alfredo Pironti
Sent: Monday, December 9, 2013 8:41 AM
To: Brian Smith
Cc: Peter Gutmann; <[email-masked]>
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)

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 <[email-masked]> wrote:
>>> interesting. However, the case where opportunistic encryption is 
>>> being used with a certificate that *is* valid (as defined by 
>>> RFC5280, et
>>> al.) is interesting.
>>

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

> "http1-tls", we would support only valid certificates.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Dec 2013 13:32:34 -0800

> If I understand correctly, an active attacker can prevent http2-tls-relaxed from happening by manipulating Alt-Svc headers, regardless of whether ALPN or NPN is used.

An active attacker can always exploit a willingness on the part of a
client to settle for something less than their best effort at
authenticating the server, yes.  This goes for Alt-Svc, Upgrade, or
any other scheme where the default behaviour is HTTP/1.1 in the clear.
 As long as the client is willing to do anything without
authentication, they are vulnerable to an active attack of this
nature.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Dec 2013 09:20:56 +0800

> interactions are up to the client.

Exactly so. I don't see an reason why one would wish to advertise this.

-Ekr

---

From: Brian Smith <[email-masked]>
Date: Mon, 9 Dec 2013 18:15:41 -0800

> interactions are up to the client.

Hi Martin,

If the server really doesn't care about the security or privacy
properties of a resource, then it wouldn't implement opportunistic
encryption in the first place, unless it was doing so purely as a
compatibility hack.

I think the point that you are making is that adding the
http2-tls-relaxed negotiation to the TLS handshake is pointless,
because you cannot securely negotiate anything on an insecure
connection. If so, then we'd say that the client MUST NOT advertise
the http2-tls-relaxed ALPN token, in order to avoid tipping off any
MitM that the connection will be unauthenticated. Is that right?

I think this means that, if the client supports opportunistic
encryption, then there would never be any way for the server to
securely know whether the client authenticated the connection or not,
so there's no secure way for a single server on a single port to
support both unauthenticated and authenticated TLS. Is this your
conclusion too?

Cheers,
Brian

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2013 09:03:07 -0800

> encryption in the first place, unless it was doing so purely as a

I don't know that hack is the right word here.

One of the options that is being considered for HTTP/2.0 is the
mandatory implementation of unauthenticated TLS for http: URIs.  If
that were the case, all that a server would have to do is upgrade
their stack.  That sets a pretty low bar.

> we'd say that the client MUST NOT advertise
> MitM that the connection will be unauthenticated.

Yes, but that isn't the reason I'd use for it.  The reason is that
it's not necessary.  It's got absolutely nothing to do with tipping
anybody off.