7 ms·

I’m really not comfortable with how they resolved this as invalid. This seems like it could be ripe for abuse when the host is behind a Cloudflare like service

I’m really not comfortable with how they resolved this as invalid. This seems like it could be ripe for abuse when the host is behind a Cloudflare like service, or a CDN with a shared anycast infrastructure. Often times these services will use the host name in the initial connection to determine the origin. While it would be very difficult to turn this into a targeted attack, I could imagine that spraying a number of discrete domains across those services may result in finding one or more interesting hosts. This could also cause some quite unexpected behavior if your applications/infrastructure sits behind a common reverse proxy where all hosts share a *.host.tld certificate pointing to the same reverse proxy. Imagine static.host.tld serving you the login page, which also tries to make a request to api.host.tld which shares the same certificate and IP but with the given host name would have been proxied to a different backend server.

tialaramex 4y ago
> This could also cause some quite unexpected behavior if your applications/infrastructure sits behind a common reverse proxy where all hosts share a *.host.tld certificate pointing to the same reverse proxy. Imagine static.host.tld serving you the login page, which also tries to make a request to api.host.tld which shares the same certificate and IP but with the given host name would have been proxied to a different backend server. If your static.host.tld cheerfully claims to be api.host.tld and you gave it a certificate testifying to this claim, then it's really your fault when it can't serve API queries right? Outfits like Cloudflare handle the mapping properly, even if they have arranged a single certificate for this.example, that.example and the-other.example, they care whether a particular TLS session says it's for this.example or that.example and the transactions will accordingly go to the correct place. This Mozilla behaviour doesn't cause any problems. This is something a crappy bulk host probably gets wrong using Apache httpd since Apache doesn't make even the bare minimum effort to actually implement this correctly by default (When a TLS client says "Hi I want to talk to api.host.example" and there is no such host configured, Apache just figures the default host can handle it even though the standard explicitly says that's wrong...). Fortunately the crappy bulk host is almost certainly just mapping everything through a bunch of VirtualHost rules and you probably can't exploit it in the way you describe these days, although they should probably really use an HTTP server from somebody competent.
- xg15 4y ago
  > they care whether a particular TLS session says it's for this.example or that.example and the transactions will accordingly go to the correct place. This Mozilla behaviour doesn't cause any problems. Indeed they do - via the SNI header, which is set once per TLS connection, not once per HTTP request. I would think initializing a connection for one domain and then reusing it for a different domain could absolutely cause problems.
- voidwtf 4y ago
  I think your missing the part of the bug report where Firefox is REUSING the existing TLS connection, which was established with a completely different SNI. If I have a load balancer handling all these connections, and I routed a connection through to static-backend-1 then Firefox “cheerfully” decided to reuse this connection for api.host.tld, how is my load balancer which has already handed off the connection to static-backend-1 going to do anything about that?
  - tialaramex 4y ago
    Mozilla are doing this for HTTP/2 which transports the entire URI, not like HTTP/1.0 where people just figure hey, I needn't send the server's name. So, the request for api.host.tld says "api.host.tld" on it. If your static server receives this request, but isn't able to service api.host.tld requests the HTTP/2 specification provides an HTTP error code to return 421, saying, oops, I can't help you with that - and the specification tells clients that in this case they might try asking via another route.
Matthias247 4y ago
CDNs with shared infrastructure make use of domain-fronting checks. Those validate that the target of every single request (identified by the Host or :authority header) is valid for the SNI and associated TLS certificate that was used to establish the connection, and otherwise reject the request. That is actually independent of HTTP/1.1, /2 or /3, since all of those allow for multiple requests targetting different authorities on the same connection. If you build your multi-tenant webserver yourself you however obviously have to be careful regarding getting this right.

tialaramex 4y ago

> This could also cause some quite unexpected behavior if your applications/infrastructure sits behind a common reverse proxy where all hosts share a *.host.tld certificate pointing to the same reverse proxy. Imagine static.host.tld serving you the login page, which also tries to make a request to api.host.tld which shares the same certificate and IP but with the given host name would have been proxied to a different backend server. If your static.host.tld cheerfully claims to be api.host.tld and you gave it a certificate testifying to this claim, then it's really your fault when it can't serve API queries right? Outfits like Cloudflare handle the mapping properly, even if they have arranged a single certificate for this.example, that.example and the-other.example, they care whether a particular TLS session says it's for this.example or that.example and the transactions will accordingly go to the correct place. This Mozilla behaviour doesn't cause any problems. This is something a crappy bulk host probably gets wrong using Apache httpd since Apache doesn't make even the bare minimum effort to actually implement this correctly by default (When a TLS client says "Hi I want to talk to api.host.example" and there is no such host configured, Apache just figures the default host can handle it even though the standard explicitly says that's wrong...). Fortunately the crappy bulk host is almost certainly just mapping everything through a bunch of VirtualHost rules and you probably can't exploit it in the way you describe these days, although they should probably really use an HTTP server from somebody competent.

xg15 4y ago
> they care whether a particular TLS session says it's for this.example or that.example and the transactions will accordingly go to the correct place. This Mozilla behaviour doesn't cause any problems. Indeed they do - via the SNI header, which is set once per TLS connection, not once per HTTP request. I would think initializing a connection for one domain and then reusing it for a different domain could absolutely cause problems.
voidwtf 4y ago
I think your missing the part of the bug report where Firefox is REUSING the existing TLS connection, which was established with a completely different SNI. If I have a load balancer handling all these connections, and I routed a connection through to static-backend-1 then Firefox “cheerfully” decided to reuse this connection for api.host.tld, how is my load balancer which has already handed off the connection to static-backend-1 going to do anything about that?
- tialaramex 4y ago
  Mozilla are doing this for HTTP/2 which transports the entire URI, not like HTTP/1.0 where people just figure hey, I needn't send the server's name. So, the request for api.host.tld says "api.host.tld" on it. If your static server receives this request, but isn't able to service api.host.tld requests the HTTP/2 specification provides an HTTP error code to return 421, saying, oops, I can't help you with that - and the specification tells clients that in this case they might try asking via another route.

Matthias247 4y ago

CDNs with shared infrastructure make use of domain-fronting checks. Those validate that the target of every single request (identified by the Host or :authority header) is valid for the SNI and associated TLS certificate that was used to establish the connection, and otherwise reject the request. That is actually independent of HTTP/1.1, /2 or /3, since all of those allow for multiple requests targetting different authorities on the same connection. If you build your multi-tenant webserver yourself you however obviously have to be careful regarding getting this right.