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

[Brian Smith <[e-mail]>]

On Mon, Dec 9, 2013 at 7:23 AM, Alfredo Pironti <[e-mail]> 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).

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