FireFox re-using HTTP2 connection to a wrong IP address & MITM attacks.

[yur...@gmail.com]

Hi

Steps to reproduce :

host_1.domain.com resolves to IP_ADDR_1 (v4) and IP_ADDR_2 (v6)

host_2.domain.com resolves to IP_ADDR_1 (v4).


both servers support SPDY/ HTTP2 and share the sam wildcard SSL certificate for *.domain.com


User opening secure HTTPS connection to https://host_1.domain.com and FF successfully opening a page, connecting to IP_ADDR_2 (because IPv6 usually preferred over IPv4 connections).

After that user trying to open URL https://host_2.domain.com, but FireFox will NOT connect to IP_ADDR_1 !!!! Instead, FireFox is going to reuse it's existing connection to IP_ADDR_2 (despite the fact it does NOT belong to host_2.domain.com).


There is a bug opened for that (https://bugzilla.mozilla.org/show_bug.cgi?id=1190136), but for some reason Patrick McManus continue to claim that such behaviour is completely normal and by design.

Patrick claims that the fact that both domains are sharing "IP_ADDR_1", it is also "Ok" to assume that all the rest of IP addresses of host_1 can be used to send requests to host_2.

To me it sounds like a complete nonsense and such behaviour most likely will lead to MITM vulnerability.

I would like to move the discussion to here, what do you think should be correct behaviour for FF in described case ?

Regards,
Yuri

[Daniel Stenberg]

On Thu, 9 Jun 2016, yur...@gmail.com wrote:

>
> host_1.domain.com resolves to IP_ADDR_1 (v4) and IP_ADDR_2 (v6)
>
> host_2.domain.com resolves to IP_ADDR_1 (v4).
>
> both servers support SPDY/ HTTP2 and share the sam wildcard SSL certificate for *.domain.com

> User opening secure HTTPS connection to https://host_1.domain.com and FF
> successfully opening a page, connecting to IP_ADDR_2 (because IPv6 usually
> preferred over IPv4 connections).
>
> After that user trying to open URL https://host_2.domain.com, but FireFox
> will NOT connect to IP_ADDR_1 !!!! Instead, FireFox is going to reuse it's
> existing connection to IP_ADDR_2 (despite the fact it does NOT belong to
> host_2.domain.com).

As you know, but not everybody reading this email might be up to speed with,
Firefox does this to keep the number of TCP connections to a minimum when it
speaks HTTP/2. "unsharding" as we sometimes call it! =)

They both have a cert that covers both hosts and they both share at least one
IP address. And they speak HTTP/2, so in the rare occasion that this would be
a wrong assumption the server can return 421.

> Patrick claims that the fact that both domains are sharing "IP_ADDR_1", it
> is also "Ok" to assume that all the rest of IP addresses of host_1 can be
> used to send requests to host_2.

Not only beause of the IP address overlap. The cert also suggests this.

> To me it sounds like a complete nonsense and such behaviour most likely will
> lead to MITM vulnerability.

I don't see how a malicious player can MITM this (in any ways not already
existing). Your scenario in the bug was a bit overboard and involved you
installing a malicous party's CA cert in your browser, and if you do that you
will certainly be a victim of MITM even easier than using this approach. Can
you explain a MITM scenario without you shooting yourself in the foot first?

--

/ daniel.haxx.se

[yur...@gmail.com]

> As you know, but not everybody reading this email might be up to speed with,
> Firefox does this to keep the number of TCP connections to a minimum when it
> speaks HTTP/2. "unsharding" as we sometimes call it! =)
>
> They both have a cert that covers both hosts and they both share at least one
> IP address. And they speak HTTP/2, so in the rare occasion that this would be
> a wrong assumption the server can return 421.

Excellent, then please make it to behave exactly the same way with IPv4 only addresses. Why FF not following the same logic if all IP's are strictly IPv4 ?

Also, let's add to RFC then that all servers must reply with 421 for domains that are not served as FireFox may decide to contact the server regardless of IP addresses returned by DNS. Next step will be enforcing the whole world to implement it.

In a real life, both hosts can be administered by different people / legal entities, even if they are sharing the same parent domain.

You can't say that correct functionality of host_2 depends of what 3rd party (administrator of host_1) configured on his server ?

And if you are right and this behaviour is on compliance with RFC, then why FF is the ONLY browser behaving that way ?

Regards,
Yuri

[Daniel Stenberg]

On Thu, 9 Jun 2016, yur...@gmail.com wrote:

>> They both have a cert that covers both hosts and they both share at least
>> one IP address. And they speak HTTP/2, so in the rare occasion that this
>> would be a wrong assumption the server can return 421.
>
> Excellent, then please make it to behave exactly the same way with IPv4 only
> addresses. Why FF not following the same logic if all IP's are strictly
> IPv4 ?

It does. Or perhaps I should say it should, if you indeed can reproduce a
scenario where it doesn't. IP version is not relevant for this context. IP
address overlap is.

> Also, let's add to RFC then that all servers must reply with 421 for domains
> that are not served as FireFox may decide to contact the server regardless
> of IP addresses returned by DNS. Next step will be enforcing the whole world
> to implement it.

A) 421 is already in the RFC.

B) It is not at all "regardless of IP address" since, again, both hosts share
IP address(es).

> You can't say that correct functionality of host_2 depends of what 3rd party
> (administrator of host_1) configured on his server ?

If the hosts indeed are that different as your explained scenario, and handled
by differenent entities, why do they share cert and IP addresses?

But more importantly: why do you think responding with a 421 when this happens
is that wrong?

Quating section 9.1.1 from RFC 7540:

A server that does not wish clients to reuse connections can indicate that
it is not authoritative for a request by sending a 421 (Misdirected Request)
status code in response to the request (see Section 9.1.2).

Surely a compliant HTTP/2 server responds this and then the problem is sorted?

> And if you are right and this behaviour is on compliance with RFC, then why
> FF is the ONLY browser behaving that way ?

Apart from the mere fact that HTTP/2 is still a fairly new protocol, Firefox
is leading the path in many ways when it comes to HTTP/2 implementations so
there's no surprise that you'll see some behaviors like this in Firefox first.
I think there are reasons to expect others to act similarly in the future.

--

/ daniel.haxx.se

[yur...@gmail.com]

> > Excellent, then please make it to behave exactly the same way with IPv4 only
> > addresses. Why FF not following the same logic if all IP's are strictly
> > IPv4 ?
>
> It does. Or perhaps I should say it should, if you indeed can reproduce a
> scenario where it doesn't. IP version is not relevant for this context. IP
> address overlap is.

No, it doesn't. If all 3 IP addresses are v4 addresses, FF is not re-using IP_ADDR_2 in similar scenario.


Let's look carefully on RFC 7540, Section 9.1.1 (Connection Reuse)

A connection can be reused as long as the origin server
is authoritative (Section 10.1). For TCP connections without TLS,
this depends on the host having resolved to the same IP address.

Forget about TLS for the moment. FF will NOT reuse existing connection for regular HTTP connection. Why ?

Because it would be wrong behaviour and will definitely lead to very easy MITM attacks, or you think FF _should_ reuse existing connection in this case as well ?


"For "https" resources, connection reuse ADDITIONALLY depends on
having a certificate that is valid for the host in the URI."


As you may see, RFC clearly states that valid certificate is an ADDITIONAL condition. In other words, if existing connection CAN be reused for HTTP, only then you should check for additional requirement - certificate should be valid.

I.e. There is a chance that connection which is good to be reused for HTTP will not be suitable for HTTPS. But not the opposite.

In case of FF what happens is exactly the opposite - FF will not reuse the connection for HTTP, but believe it's good for HTTPS.

[Daniel Stenberg]

On Thu, 9 Jun 2016, yur...@gmail.com wrote:

> Forget about TLS for the moment. FF will NOT reuse existing connection for
> regular HTTP connection. Why ?

A) Because Firefox doesn't do HTTP/2 at all without TLS

B) Without TLS there's no certificate that provides that extra hint so it
gives the browser less confidence. But really, see (A).

> Because it would be wrong behaviour and will definitely lead to very easy
> MITM attacks,

HTTP (*not HTTPS*) isn't exactly known for being effective againts MITM
attacks!

> As you may see, RFC clearly states that valid certificate is an ADDITIONAL
> condition. In other words, if existing connection CAN be reused for HTTP,
> only then you should check for additional requirement - certificate should
> be valid.

So you're now arguing that if a browser would speak HTTP/2 over plain TCP you
think it should reuse connections for this setup even when there's no certs
involved?

That seems like a side track we don't need to take right now. Let's instead
focus on what we think Firefox should and shouldn't do.

> In case of FF what happens is exactly the opposite - FF will not reuse the
> connection for HTTP, but believe it's good for HTTPS.

Firefox speaks HTTP/1.1 over TCP and HTTP/2 over HTTPS, that's the bigger and
important diference here.

I think we're mostly moving in circles. You think Firefox acts wrongly, and
I've tried to explain the reasoning behind its behaviors. I think Firefox
follows the spec both as written as well as in spirit.

I've not seen you explain how this causes actual real-life problems (in a
scenario where you don't install a malicous party's CA cert yourself). Can you
help me understand?

--

/ daniel.haxx.se

[yur...@gmail.com]

> > As you may see, RFC clearly states that valid certificate is an ADDITIONAL
> > condition. In other words, if existing connection CAN be reused for HTTP,
> > only then you should check for additional requirement - certificate should
> > be valid.
>
> So you're now arguing that if a browser would speak HTTP/2 over plain TCP you
> think it should reuse connections for this setup even when there's no certs
> involved?
>

No, I'm 100% sure the browser MUST NOT reuse connection to IP_ADDR_2 while speaking to host_2.domain.com, if host_2.domain.com doesn't have A or AAAA record matching IP_ADDR_2. Regardless of HTTP or HTTPS being used.

> I think we're mostly moving in circles.

Yep, looks like we are.

> I've not seen you explain how this causes actual real-life problems (in a

> scenario where you don't install a malicious party's CA cert yourself). Can you
> help me understand?


Real life example.

Corporate intranet. Intranet sites are accessible via TLS encrypted connections, all of them are sharing wildcard certificate, something like *.intranet.company.com

The certificate is not malicious, this is legitimate certificate.

Host_1.intranet.domain.com have 2 mirrors - one on the server with IP_1 _v4 and IP_2_v6
2nd mirror is on another server, which has only v4 address : IP_3_v4


Host_2.intranet.domain.com is a smaller web site, which is hosted only on one single IP_3_v4.


What happens is that users are unable to access host_2.intranet.domain.com using FireFox because FF always trying to re-use connection to IP_2_v6.



We are arguing about RFC interpretation. I can see several places in the RFC proving your implementation is wrong :

Section 9.1
Clients SHOULD NOT open more than one HTTP/2 connection to a given
host and port pair, where the host is derived from a URI, a selected
alternative service [ALT-SVC], or a configured proxy.

Let's look at the URI https://host_2.intranet.company.com/ . The only possible host and port pair that can derive from that URI is IP_3_v4:443 . Therefore the browser must open a new connection and not try to reuse old one to IP_2_v6.



Section 9.1.1

As I said before, valid certificate is an ADDITIONAL condition (which is clearly stated in RFC) for HTTPS connections. I.e. certificate should be considered only if all the rest of conditions are met and authority of the server is established.

I.e. presence of wildcard certificate can't be a REASON why connection is reused. It's just an additional condition to determine if connection can be reused or not.

[siava...@gmail.com]

Сам ломаю голову над этой бедой Firefox. Что интересно, так Chrome без каких-либо проблем работает с этой ситуации и не отдаёт содержимое первого поддомена при обращении ко второму по ipv6.