3 ms·

In theory, we can still enable end-to-end encryption while forward proxying by a separate service provider, but it might not be easy to implement. The browser w

In theory, we can still enable end-to-end encryption while forward proxying by a separate service provider, but it might not be easy to implement. The browser would need to be smart enough to route packets through the website and verify SSL coming out of the PCI environment. This will require modifications to the OS to dynamically add static routes for dependencies. 1. Browser loads the shopping cart page on example.com to transmit credit card details 2. User enters credit card details in to the form and hits enter. 3. The browser resolves the IPs for domain api.creditmerchant.net and adds static routes for those IPs pointing to example.com 4. The browser initiates SSL connection to api.creditmerchant.net using example.com as a static route 5. The browser verifies the authenticity of the certificate and chooses ciphers for the conversation 6. The credit card details are encrypted and transmitted to api.creditmerchant.net without being exposed to example.com 7. The purchase is complete and example.com is not in scope for PCI. *. If the example.com is set as the static route for any unknown dependencies, the traffic is null routed

xg15 7y ago
But then, what exactly was won? Seems to me, the request to api.creditmerchant.net is still a mostly ordinary cross-site requests, except the packets are routed through example.com - but example.com can't do anything with the packets, because they are encrypted. So api.creditmerchant.net could still inject all kinds of malicious or buggy scripts and example.com can't do anything about it. The one difference I see is that api.creditmerchant.net could restrict it's endpoints to only accept packets from example.com addresses - as they should never be called directly from a browser. This sounds like some ad-hoc CSRF protection. Was that the intention?
- birdyrooster 7y ago
  Yes I think that was the intention. You reduce the attack surface for injection attacks because the injected code must route all requests through example.com. Example.com will implicitly trust api.creditmerchant.net as it does today, but that dependency once loaded won’t be able to make requests to untrusted resources categorically because it must route thru example.com. It seems like a spoiler for chaining attacks.

xg15 7y ago

But then, what exactly was won? Seems to me, the request to api.creditmerchant.net is still a mostly ordinary cross-site requests, except the packets are routed through example.com - but example.com can't do anything with the packets, because they are encrypted. So api.creditmerchant.net could still inject all kinds of malicious or buggy scripts and example.com can't do anything about it. The one difference I see is that api.creditmerchant.net could restrict it's endpoints to only accept packets from example.com addresses - as they should never be called directly from a browser. This sounds like some ad-hoc CSRF protection. Was that the intention?

birdyrooster 7y ago
Yes I think that was the intention. You reduce the attack surface for injection attacks because the injected code must route all requests through example.com. Example.com will implicitly trust api.creditmerchant.net as it does today, but that dependency once loaded won’t be able to make requests to untrusted resources categorically because it must route thru example.com. It seems like a spoiler for chaining attacks.