3 ms·

I might just be stupid but I'm not quite seeing the full issue I think. From my reading this is a problem if: 1. Your CDN/Load balancer allows for HTTP/1.1 co

I might just be stupid but I'm not quite seeing the full issue I think. From my reading this is a problem if: 1. Your CDN/Load balancer allows for HTTP/1.1 connections 2. You do some filtering/firewalling/auth/etc at your CDN/Load balancer for specific endpoints I'm sure it's more than that, and I'm just missing it. If you do all your filtering/auth/etc on your backend servers this doesn't matter right? Obviously people DO filtering/auth/etc at the edge so they would be affected but 1/3rd seems high. Maybe 1/3rd of traffic is HTTP/1.1 but they would also have to be doing filtering/auth at the edge to be hit by this right? Again, for the 3rd time, I'm probably missing something, just trying to better understand the issue.

mhitza 1y ago
If it's similar to a vulnerability reported a couple of years back, the gist of it would be. Some load balancers fronting multiple application connection through multiplexed requests on a single HTTP 1.1 connection, and bugs occur with the handling (generally handling request boundaries). For example you can have a HTTP 1.1 front connection that behind the scenes operates a separate HTTP 1.0, 1.1, 2 or 3 connection. When smuggling additional data through the request you trip up the handler at the load balancer handler to inject a response that shouldn't be there, which will be served for one of the clients (even the wrong client request). Similar to HTTP response splitting attacks of the past. Eg. 3 requests come into the load balancer, and request 2 smuggles in an extra response that could be served as a response to request 1 or 3. That's how I understood the last such attack.
bkallus 1y ago
Cache poisoning is also possible. See https://youtu.be/aKPAX00ft5s?feature=shared&t=8730 https://youtu.be/aKPAX00ft5s?feature=shared&t=8730 for a relevant demo. You can also (in principle) steal responses intended for other clients, and control responses that get delivered to other clients.

mhitza 1y ago

If it's similar to a vulnerability reported a couple of years back, the gist of it would be. Some load balancers fronting multiple application connection through multiplexed requests on a single HTTP 1.1 connection, and bugs occur with the handling (generally handling request boundaries). For example you can have a HTTP 1.1 front connection that behind the scenes operates a separate HTTP 1.0, 1.1, 2 or 3 connection. When smuggling additional data through the request you trip up the handler at the load balancer handler to inject a response that shouldn't be there, which will be served for one of the clients (even the wrong client request). Similar to HTTP response splitting attacks of the past. Eg. 3 requests come into the load balancer, and request 2 smuggles in an extra response that could be served as a response to request 1 or 3. That's how I understood the last such attack.

bkallus 1y ago

Cache poisoning is also possible. See https://youtu.be/aKPAX00ft5s?feature=shared&t=8730 https://youtu.be/aKPAX00ft5s?feature=shared&t=8730 for a relevant demo. You can also (in principle) steal responses intended for other clients, and control responses that get delivered to other clients.