4 ms·

The reporter has discovered that HTTP/2 has a connection coalescing feature. Coalescing requires hosts to share the same valid TLS certificate. As far as the sp

by pornel 4y ago

The reporter has discovered that HTTP/2 has a connection coalescing feature. Coalescing requires hosts to share the same valid TLS certificate. As far as the specs go, this is not a bug, and it doesn't violate security model of HTTP/2. HTTPS is meant to add security on top of unprotected untrustworthy network, so it doesn't concern itself with what happens on the IP layer which is already assumed to be potentially MITMed/spoofed. Here the reporter expects the unprotected network to add security in case HTTPS has been completely defeated. Good luck with that.

untitaker_ 4y ago
As the reporter already stated, just because the HTTP/2 spec permits it, that doesn't make it a good idea. Now Firefox may "resolve" a hostname to a different IP based on whether it might have connected to a different hostname before. I don't want to imagine what bugs this will cause. And for what? To save another (probably already cached) DNS lookup?
- pornel 4y ago
  The time to bikeshed whether it's a good idea was at IETF when HTTP/2 has been designed. This feature has been in production for over 6 years. Note that both hostnames must be in the same TLS certificate. You won't get random hosts coalesced by accident. You have to specifically obtain a TLS certificate that contains multiple of your hosts, and their DNS entries have to have at least one IP address in common. And then the server can still return an HTTP error that tells the browser to stop coalescing and retry with a fresh connection. In practice this feature is commonly used to reuse a single CDN connection to fetch from multiple hosts behind the same CDN (e.g. www.example.com + assets.example.com), and avoids fragmenting per-connection request prioritization in HTTP/2.
  - untitaker_ 4y ago
    >The time to bikeshed whether it's a good idea was at IETF when HTTP/2 has been designed. that's not at all how this works in practice. plenty of bad ideas leave the IETF all the time, and it's up to future standard revisions to follow up with how those are being dealt with in implementations.
  - zerocrates 4y ago
    The utility of reuse is clear, but how often is it actually necessary to "reuse" a connection to an address that's not in the DNS for the hostname you're trying to connect to, as here? Seems like it would be very rare.
    - londons_explore 4y ago
      Isn't it fairly common for hundreds of IP's to be in a DNS zone, but only a random subset is returned to the client as a form of basic loadbalancing?
  - toast0 4y ago
    > You have to specifically obtain a TLS certificate that contains multiple of your hosts, and their DNS entries have to have at least one IP address in common. But oddly IMHO, the IP used to send requests to both need not be in common?
    - pornel 4y ago
      Yes, because IPs are hard to keep exactly in sync even when they reach the exact same machine, e.g. because of sharding/load-balancing done by CDNs.
- zerocrates 4y ago
  It seems like it must actually do a DNS lookup to have established the matching IPv6 address, so you're not even saving that. (edit: Or maybe it just ignores DNS totally at this point and operates off having seeing the second hostname in the certificate it got before? That seems like it would cause more issues though.) I'm not sure I totally buy that the spec does allow it (since the "authoritativeness" rules for HTTPS are defined as being in addition to those for HTTP), but beyond that it is a little hard to imagine what purpose there is to be overly-greedy like this in matching up for reused connections.
xg15 4y ago
Doesn't this have the potential to interact really badly with SNI though? After all, TLS today is not "just" a security layer anymore. With SNI and ALPN it has also taken on quite a bit of routing functionality. E.g. suppose example.com has two subdomains, foo.example.com and bar.example.com. To simplify deployment, the site uses a central TLS gateway to terminate all connections to *.example.com and also uses a single wildcard certificate for all subdomains. The gateway then reads the SNI header to figure out which backend server it should proxy the connection to. This works perfectly fine as long as a browser only uses a connection for the subdomain that it announced in the SNI header. However, if it suddenly starts to make requests for a different subdomain on that connection, because both subdomains share the same IP (of the gateway) and cert (wildcard), requests will be routed to the wrong backend server and things will break. I'm not sure what the exact conditions for connection coalescing are in Firefox. If it's really as you say and the certificates have to be identical, then it's just a safety issue. However, if it's only required that the certs are signed for the same domain, then it could become a security issue as well: All you needed was to be on the same shared hoster as your victim and obtain a fraudulent cert for their domain and you can hijack some of their connections. Edit: Also, if the browser has a connection open to foo.example.com and wants to make a request to bar.example.com, how does it even obtain the cert for bar.example.com to decide if it can reuse foo's connection? It would have to open a new connection with SNI=bar.example.com, grab the cert - and then close the connection again and go back to foo's connection. What would even be gained by that?

by pornel 4y ago

untitaker_ 4y ago

As the reporter already stated, just because the HTTP/2 spec permits it, that doesn't make it a good idea. Now Firefox may "resolve" a hostname to a different IP based on whether it might have connected to a different hostname before. I don't want to imagine what bugs this will cause. And for what? To save another (probably already cached) DNS lookup?

pornel 4y ago
The time to bikeshed whether it's a good idea was at IETF when HTTP/2 has been designed. This feature has been in production for over 6 years. Note that both hostnames must be in the same TLS certificate. You won't get random hosts coalesced by accident. You have to specifically obtain a TLS certificate that contains multiple of your hosts, and their DNS entries have to have at least one IP address in common. And then the server can still return an HTTP error that tells the browser to stop coalescing and retry with a fresh connection. In practice this feature is commonly used to reuse a single CDN connection to fetch from multiple hosts behind the same CDN (e.g. www.example.com + assets.example.com), and avoids fragmenting per-connection request prioritization in HTTP/2.
- untitaker_ 4y ago
  >The time to bikeshed whether it's a good idea was at IETF when HTTP/2 has been designed. that's not at all how this works in practice. plenty of bad ideas leave the IETF all the time, and it's up to future standard revisions to follow up with how those are being dealt with in implementations.
- zerocrates 4y ago
  The utility of reuse is clear, but how often is it actually necessary to "reuse" a connection to an address that's not in the DNS for the hostname you're trying to connect to, as here? Seems like it would be very rare.
  - londons_explore 4y ago
    Isn't it fairly common for hundreds of IP's to be in a DNS zone, but only a random subset is returned to the client as a form of basic loadbalancing?
- toast0 4y ago
  > You have to specifically obtain a TLS certificate that contains multiple of your hosts, and their DNS entries have to have at least one IP address in common. But oddly IMHO, the IP used to send requests to both need not be in common?
  - pornel 4y ago
    Yes, because IPs are hard to keep exactly in sync even when they reach the exact same machine, e.g. because of sharding/load-balancing done by CDNs.
zerocrates 4y ago
It seems like it must actually do a DNS lookup to have established the matching IPv6 address, so you're not even saving that. (edit: Or maybe it just ignores DNS totally at this point and operates off having seeing the second hostname in the certificate it got before? That seems like it would cause more issues though.) I'm not sure I totally buy that the spec does allow it (since the "authoritativeness" rules for HTTPS are defined as being in addition to those for HTTP), but beyond that it is a little hard to imagine what purpose there is to be overly-greedy like this in matching up for reused connections.

xg15 4y ago

Doesn't this have the potential to interact really badly with SNI though? After all, TLS today is not "just" a security layer anymore. With SNI and ALPN it has also taken on quite a bit of routing functionality. E.g. suppose example.com has two subdomains, foo.example.com and bar.example.com. To simplify deployment, the site uses a central TLS gateway to terminate all connections to *.example.com and also uses a single wildcard certificate for all subdomains. The gateway then reads the SNI header to figure out which backend server it should proxy the connection to. This works perfectly fine as long as a browser only uses a connection for the subdomain that it announced in the SNI header. However, if it suddenly starts to make requests for a different subdomain on that connection, because both subdomains share the same IP (of the gateway) and cert (wildcard), requests will be routed to the wrong backend server and things will break. I'm not sure what the exact conditions for connection coalescing are in Firefox. If it's really as you say and the certificates have to be identical, then it's just a safety issue. However, if it's only required that the certs are signed for the same domain, then it could become a security issue as well: All you needed was to be on the same shared hoster as your victim and obtain a fraudulent cert for their domain and you can hijack some of their connections. Edit: Also, if the browser has a connection open to foo.example.com and wants to make a request to bar.example.com, how does it even obtain the cert for bar.example.com to decide if it can reuse foo's connection? It would have to open a new connection with SNI=bar.example.com, grab the cert - and then close the connection again and go back to foo's connection. What would even be gained by that?