On Thu, 9 Jun 2016, [email protected] 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
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
