From:  Daniel Stenberg <>
Date:  09 Jun 2016 19:08:45 Hong Kong Time

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


On Thu, 9 Jun 2016, 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.