Subject: Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

From: Patrick McManus <[email-masked]>
Date: Fri, 2 Jan 2015 07:45:06 -0500

Hi Aeris,

As you've discussed with Ryan and Adam (on spdy-dev) I don't really think
there is a problem with the specification here - it requires that the
connection be considered authoritative for the request.

Neither Firefox nor Chrome support TLSA so the h2 stacks don't consider it
in the authoritative determination. In each case an extension can provide
some of that functionality - but as in this case it appears that the
extension, and likely the extension framework too, aren't quite up to date.
I'm happy to work with you in the mozilla bug tracker or network mailing
lists to close the gap in the best way for your extension.

-Patrick

On Thu, Jan 1, 2015 at 7:53 AM, Aeris <[email-masked]> wrote:

> > ​Chrome does not support TLSA so I'm not sure how the current Chrome SPDY
> > implementation could be breaking TLSA.
>
> As for Firefox, TLSA support is currently provided by a plugin on Chrome :
>         https://www.dnssec-validator.cz/
>
> https://chrome.google.com/webstore/detail/tlsa-validator/gmgeefghnadlmkpbjfamblomkoknhjga
>
> Regards,
> --
> Aeris
>
> Protect your privacy, encrypt your communications
> GPG : EFB74277 ECE4E222
> OTR : 5769616D 2D3DAC72
> https://café-vie-privée.fr/ <https://xn--caf-vie-prive-dhbj.fr/>
>

---

From: Aeris <[email-masked]>
Date: Fri, 02 Jan 2015 15:25:42 +0100

> connection be considered authoritative for the request.

On the current spec, the authority is check only (§9.1.1 and §10.1) by the 
certificate content (subject/alt-subject and RFC2818). Seems not talking about 
TLSA, PKP or everything else.
Or the spec just list some examples of what « authoritative » means, and in 
this case, maybe it will better to clarify this, and/or be more precise on the 
definition, currently very fuzzy.
Actually, the HT2 behaviour about connection reusage is totally implementation 
dependant, with possibly the 2 extrem behaviour : very weak implem checking 
only sub/alt-sub and IP, very strong implem always reopening, with middle 
implem checking for TLSA/PKP/DNSSec/whatever combination…

> but as in this case it appears that the

This is one of my fear for HTTP/2 : must re-dev all extension or HT2 stack 
just to handle new TLS case… :'(

> lists to close the gap in the best way for your extension.

With TLSA or PKP or anything, the fix is very easy : just don’t reuse 
connection :P Because it’s slower/require new channel.

- Verifying for TLSA need DNSSec validation of the TLSA DNS entry and the real 
certificate if such entry. If you have already do all those check, you 
*already* need a new channel open, to fetch the certificate.
- Verifying for PKP need the real content. Same, need a new channel too if any 
PKP header to fetch the real certificate. And using the first channel to check 
for PKP header is possibly insecure if PKP exist and don’t match the cert.
- Verifying for key pinning is not possible without real cert. New channel 
needed too.
- Even if any TLS extension, in *ALL* case, verifying for protocol, ciphers, 
key and certificate to verify this is *exactly* (at least key/cert, better to 
check proto/cipher too) the same as the primary channel require a new channel. 
For key and cert, if domain B declare different key/cert than A, A is *not* 
authoritative for B (not distinguishable to MITM attack if it’s the case).

So in all cases, checking for connection reuse is more expensive/less 
secure/require reopen  than just reopen a channel.

Regards,
-- 
Aeris

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 2 Jan 2015 17:00:29 +0200

> *already* need a new channel open, to fetch the certificate.

Err, why isn't just validating the current certificate against fetched TLSA
records and then opening a new channel if that fails (DNS caches should be hot)
sufficient?

> - Verifying for key pinning is not possible without real cert. New channel 

HPKP is nastier, especially in the non-pinned case.

Another interaction between connection reuse and HPKP: Potentially having to
deal with server trying to pin the reused connections (foo.example pinning
bar.example, when foo.example and bar.example share a connection).

-Ilari

---

From: Aeris <[email-masked]>
Date: Fri, 02 Jan 2015 16:21:45 +0100

> records and then opening a new channel if that fails (DNS caches should be
> hot) sufficient?

Oops. Yes, will be good this way.

> HPKP is nastier, especially in the non-pinned case.

Yep, it’s the worst case. Need new channel in all case, even if not HPKP at 
the end.
Same for proto/ciphers check.

> bar.example, when foo.example and bar.example share a connection).

Could be tricky…

It shows than connection reusage is not trivial at all, and suffer of very deep 
implication on TLS ecosystem and overall security.
Even if fully specified, the code necessary to handle all cases correctly will 
just be a bunch of spaghetti and depends of hundred of parameters (some 
totally external to HTTP2 stack or to browser built-in features), with no 
insurance of better perf or (at least) same security compare to no reusage at 
all.

-- 
Aeris

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 2 Jan 2015 09:27:03 -0800

The requirement to reuse a TLS connection is that the cert is "valid". This
does not simply mean that the cert contains a matching Subject-Alt-Name, it
means that *all* the validity checks are satisfied. For a User-Agent that
supports TLSA it must check TLSA (Chrome does not support TLSA so I'm not
familiar with what they are). In the case of Public Key Pinning, the must
check that the pins are satisfied. Chrome does support pinning and so if
you look at the code which checks to see if an existing connection can be
used for a new hostname, you'll see that it explicitly verifies the pins:

https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/spdy_session.cc&sq=package:chromium&l=568&rcl=1420152226

I think that the requirement in 9.1.1 is sufficient.

---

From: Aeris <[email-masked]>
Date: Fri, 02 Jan 2015 19:10:17 +0100

> means that *all* the validity checks are satisfied.

List *all* those validity checks is impossible, because depends of tons of 
parameters, RFCed or not, built-in or not, custom or not. This is not just a 
case of X.509, TLSA or PKP.
For example, I (and I hope everybody) consider invalid the fact of using a A 
certificate (even if totally X.509 valid) for B domain in case of B domain 
would use B cert if no reusage. With or without PKP/TLSA/whatever. Cause it’s 
the definition of what is MITM TLS attack.
Same if weak protocol or cipher are reuse instead of new strong ones. Cause 
it’s the same behaviour as downgrade attack.

Either IETF allow channel reusage and in this case, must ensure client 
behaviour with strong definition of when reuse and when not reuse, to be able 
to judge if this is at least as secure as TLS without reusage and know very 
well what new TLS attack will be possible. Or more simply to allow an admin 
sys to understantd very well what TLS strength he will have on each content 
(right now taking into account not only the content but also the origin, and 
worse actually, the user-agent the user will use…) he serv.
Or IETF must reject channel reusage, for security purpose.

And even with strong definition, all the chance we have to consider HTTP2 as a 
not secure protocol because reduce overall security or bypass some TLS related 
principle. Cause such strong definition is in fact impossible to find without 
reducing TLS scope/extensibility.
The only strong, testable, not implem dependant, extendable definition is 
« reuse the channel if and only if there is no difference with no reusage ». 
And means impossible to achieve without a real opening to compare current 
parameters with the next ones.

> https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/spdy_ses
> sion.cc&sq=package:chromium&l=568&rcl=1420152226

This is exactly what I say : this « CanPool » method will become just a 
monster with a bunch of spaghetti code, addressing tons of use case, needing 
hooks for browser plugins… And currently with not the same behaviour for all 
user-agent because no precise definition of what « valid » means.

Regards,
-- 
Aeris

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Jan 2015 10:31:18 -0800

> case of X.509, TLSA or PKP.

Ultimately, clients will determine what requirements need to be met in
order to consider an origin authenticated.  There are RFCs to guide
that process, and those aim to establish a baseline (2818 or 6125 +
5280 perhaps being that baseline) but the choice of which RFCs ensures
that there are - as you say - a virtually infinite number of choices.

That is why the draft states that the server needs to be considered
authoritative, and then relies on the definition of that from RFC
7230.

The HTTP/2 draft simply states the conditions under which connections
can be reused.  This is different from HTTP/1.1, which is probably the
source of your angst.

Of course, we have also defined several ways to avoid this happening
if that doesn't suit you.  The 421 status code.  The HTTP_1_1_REQUIRED
error code.

---

From: Aeris <[email-masked]>
Date: Fri, 02 Jan 2015 20:06:21 +0100

> if that doesn't suit you.  The 421 status code.  The HTTP_1_1_REQUIRED

Yep. Or you can disable all HTTP/2 too.
Cases I mention can’t be detected application-side or with very difficulty 
server-side. Simpler/more secure to disable all the HT2 stack.

But HTTP/2 is good for speed and the difference is very noticable.
Too bad the overall security will be such there is no way to use it on a post-
snowden era and/or with critical content…

-- 
Aeris

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Jan 2015 11:12:59 -0800

> snowden era and/or with critical content…

For the record, I disagree with that assessment.  There are strict
security improvements in HTTP/2.  Connection reuse can also provide
non-trivial privacy advantages.

As others have stated, the issues you describe are rooted in
implementation concerns: TLSA validation not being integral, not being
able to assess the security properties of a request, etc...  These
don't require standardization to fix.

---

From: Aeris <[email-masked]>
Date: Sat, 03 Jan 2015 11:22:31 +0100

> security improvements in HTTP/2.

Yep, requiring TLS1.2+ and strong ciphers is cool :)

About this, why requiring P256 elliptic curve [FIPS186] support, which is 
*not* safe (see http://safecurves.cr.yp.to/) and not the safe Curve25519 curve 
for example ?

> Connection reuse can also provide

If it means same behaviour as MITM or downgrade attack…
And currently, I don’t see any of those non-trivial advantages. Do you have 
some example ?

What about TLS client auth with connection reusage ?
If dom A don’t require TLS client auth but B does, how the connection reusage 
will handle this case ? Without TLS renegociation for domain B, the HT2 user-
agent won’t be able to see there is a client certificate to send, no ?

Regards,
-- 
Aeris

---

From: Ryan Hamilton <[email-masked]>
Date: Sun, 4 Jan 2015 10:59:06 -0800

To back up for a second, remember that a server administrator can prevent
connection reuse at will by either:

1) Changing the hostname -> IP mapping so that hosts which should not share
connections are on different address
2) Serving certificates which are not valid for hosts which should not
reuse connections to the current host

As such, any server administrator who is concerned about connection reuse
can simply configure their servers to prevent it from happening.

> If it means same behaviour as MITM or downgrade attack…

​If you can exploit Chrome's connection reuse behavior to lead to a MITM
attack, that would be a critical security bug which we would jump on
immediately. Please let me know if you are able to do so.
​

> agent won’t be able to see there is a client certificate to send, no ?

​In Chrome, we prevent connection reuse to hosts which request client
certificates. HTTP/2 prohibits TLS renegotiation in section 9.2.1.

Cheers,

Ryan

---

From: Aeris <[email-masked]>
Date: Sun, 04 Jan 2015 20:29:08 +0100

> connections are on different address

Not usable on IPv4. There is no more available IPv4, or very expensive.
Currently can’t have 50 IPv4, one for each of my sub-domain…

> reuse connections to the current host

Not available for all CA.
For example StartCom add *always* DNS:domain.com on issued CA, so I can’t 
generate a certificate only valid for A.domain.com and not for domain.com on 
this CA.
Or in my case, have 2 wildcard cert issued by different CA for each domain.

> can simply configure their servers to prevent it from happening.

Not at all. I’m a server administrator. I can’t be able (or can’t afford) for 1 
different certificat for each of my 50 sub-domains…
Do you consider only big company with many money and professional admin sys 
exist on the Internet ? Or worst, only them can have security or choose the 
TLS behaviour they want with HTTP/2 ?

> immediately. Please let me know if you are able to do so.

I don’t say this. I only say HTTP/2 behaviour *can’t be distinguished* from 
real MITM or downgrade attack.
From an IDS point of view for example, you fetch a content with a certificat or 
cipher different of what is expected, exactly the same way current real HTTP/1 
attacks do.

But on our way, I sense connection reuse can ease MITM or downgrade attack. 
You « just » have to poison the DNS to match the target IP and send a A 
content with weak TLS parameters and request targeted content B from A to 
force TLS parameters to what you want for the B content fetching.

> certificates. HTTP/2 prohibits TLS renegotiation in section 9.2.1.

When I say « renegociation », I mean no channel reusage.
If A domain doesn’t require TLS auth but B domain yes, how will you detect the 
need of auth with channel reuse ? Because when the channel will be reused to 
fetch B content, no TLS negociation will be done and so not able to see the 
auth request, am I wrong ? From B to A, there is no problem, but from A to B, 
there is.

Regards,
-- 
Aeris

---

From: Martin Thomson <[email-masked]>
Date: Sun, 4 Jan 2015 13:07:21 -0800

On 4 January 2015 at 10:59, Ryan Hamilton <[email-masked]> wrote:
> 2) Serving certificates which are not valid for hosts which should not reuse
> connections to the current host

Or use the new 421 status code.

---

From: Ryan Hamilton <[email-masked]>
Date: Sun, 4 Jan 2015 15:53:42 -0800

> force TLS parameters to what you want for the B content fetching.

In your example, host A has a valid certificate for host B, but is
configured to have weaker security configuration than host B. Is that
right? If so, then your DNS poisoning attack works just fine with HTTP/1.1,
so HTTP/2 does not make it worse.