3 ms·

Interesting question. Whether it is a good idea is going to depend on a whole bunch of architectural factors. If it's a static JS library, say JQuery, then se

Interesting question. Whether it is a good idea is going to depend on a whole bunch of architectural factors. If it's a static JS library, say JQuery, then self host it seems sensible. You can host on your own CDN if needed. What about if it is, say a credit card processing service? Well now you are dealing with credit card data through your site, so perhaps PCI compliance might apply? Also you are now being the MITM to avoid an evil MITM - so you have more responsibility than every to ensure security. Make sure your proxy is secure as possible. Does it accept bad certificates for example?

birdyrooster 7y ago
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.

birdyrooster 7y ago

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.