10 ms·
As far as I can tell this is only done if the certificate if valid for the new domain, so this seems only exploitable if you have stolen the certificate public
by devit 4y ago
As far as I can tell this is only done if the certificate if valid for the new domain, so this seems only exploitable if you have stolen the certificate public keys.
It might allow to do traffic interception after stealing the private keys without MitMing the connection, but in general you have to assume the adversary is all-powerful and can MitM anything and thus that a stolen certificate private key is catastrophic, so it doesn't really change anything in the worst case.
It also appears that it needs an address in common, so it doesn't even seem a problem from a correctness perspective, since if you were fine getting traffic for both domains on the same IPv6 address (and thus the same endpoint), then why would you not support getting it on the same IPv4 address, or viceversa.
Although it's not clear whether it's a good idea, it seems it might be better to require that the domains actually have the address that was connected to in common rather than any address.
- tialaramex 4y ago> if you have stolen the certificate public keys. [nitpick] Private keys. The public keys are published right inside the certificate of course.
- jsmith45 4y agoI could see this perhaps being exploitable against some cloudflare clone or shared hosting provider where the following setup is used: One server hosts multiple sites from different end entities, with a shared IPv4 address (since those are scarce), and obviously a cert that contains SANs for all the sites this server instance hosts. On IPv4 the server is configured to look inside the request to know which virtual site to serve up. But for IPv6, they let the each site have a seperate ip address, and bind the virtual sites based only on IP address, since each one is unique, and we can avoid extra overhead of parsing the domain before dispatching this way. They continue to reuse the multi-san Cert for these addresses, because having to manage extra certs when you already have one that works for all the sites would be silly. Now if a connection is open to the attackers site via ipv6, and then Firefox tries to open the victim site, resolves the IP address, notices that it has an IPv4 match with the attackers site, so assumes it can just use the attacker site's IPV6 connection, since it was using a cert that lists the victim domain, and suddenly attacker site starts getting requests intended for the victim site, and can do things like steal credentials. Now perhaps this scenario cannot happen. The bug report does not fully lay out which domains were involved and which ipv4 were assigned to which, and I'm not sure exactly how the reuse logic in Firefox works. I'm also unsure if this proposed setup violates some http/2 RFC MUSTs, or anything like that, but it is not like it is a completely outlandish idea.
- GauntletWizard 4y ago> obviously a cert that contains SANs for all the sites This is where your example falls apart, because that's not a reasonable thing in the real world. Shared hosts should be (and mostly are) using SNI[1], "Server Name Indication". SNI basically adds "Tell me which certificate you want to see" to the protocol, so your browser starts the request with "I'm trying to connect to Site1", and the shared hosting provider will have certificates for each individual site they're hosting, and pick the right one. For a real example of how this is dangerout, see jsmith45's comment above about wildcards and specific sites. [1] https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication