1553059 - connection reuse ipv4 / ipv6 gone wrong

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect)

Description

[Christian Schmitt]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3794.0 Safari/537.36 Edg/76.0.161.0

Steps to reproduce:

Actually there is a bug for that already, however it got closed long ago as won't fix (https://bugzilla.mozilla.org/show_bug.cgi?id=1190136). But the behavior is completely broken for several reasons. I came here only because on HackerNews somebody came up with it https://news.ycombinator.com/item?id=19964852. I tried to debug the issue a pretty long while and had no idea what was happening.

We actually live in a world where a lot of companies still have a single IPv4 and try to migrate over to IPv6 addresses, most of these companies have a single wildcard certificate because of cost reasons. They employ a lot of windows and letsencrypt isn't that wildly adopted.
Most companies have a IPv4 LoadBalancer, but try to use the native IPv6 of these services. As soon as IPv4 will go away, the LoadBalancer will go away.

Currently the bug is easily to describe (https://www.trullala.de/firefox-http2-ipv6-pitfall/). I will actually copy paste from the site above, because he describes it so well.

Conditions
two (or more) subdomains (same domain)
…share a common wildcard ssl certificate
on the same host (same IPv4-address)
but with different IPv6-addresses
client: Firefox (only Firefox has this behavior)
use HTTP/2
use IPv6

Actual results:

Requests for the second host (bar) go to the first host (foo).

Expected results:

foo.example.com in location bar shows foo.example.com
bar.example.com in location bar shows bar.example.com

the problem here is that firefox tried to actually mix IPv4 resolving with IPv6 resolving to just save a connection. While the idea of connection re-use is a good idea, it's really stupid when thinking about IPv6 and IPv4.

Most of the time it does not matter if a domain has the same IPv4, while the resolving is done over IPv6.
Connection reuse should either take ALL IPs into play or it should be IPv6 aware.
The current behavior will actually hinder IPv6 or http2 adoption since it breaks some websites that want a sane migration path (no NAT, no LB that isn't useful in some scenarios, etc..)

Comment 1

[Valentin Gosu [:valentin] (he/him) {{ PTO until 21 Apr }}]

I am inclined to dupe this to bug 1190136.
Dragana, do we have any intention to change our coalescing algorithm?

Comment 2

[c.schmitt]

(uf just found out that I have another bugzilla account...)

basically I think the current way leads to really undefined behavior.
I think a good way of handling that would actually do the following:

1. if the first connection was done via IPv6 and SANS/wildcard certs contains the same hostname it should resolve a.example.com and b.example.com AAAA entries, if they are requal, coalesce
2. if they are unequal create a new connection
3. if IPv4 was used and new connection was IPv6 it should RESOLVE all IPv4 and check if all pairs match.

the behavior that the connection was done via IPv6 but the equality check is only over the IPv4's is totally broken. It's also impossible to debug.

Comment 3

[Dragana Damjanovic [:dragana]]

(In reply to PTO until September 9th from comment #1)

I am inclined to dupe this to bug 1190136.
Dragana, do we have any intention to change our coalescing algorithm?

this is a dup of 1190136. WE are not planning to change our coalescing algorithm.
Also think about using 421 response code.