>An "antivirus" filter ends up implemented as a man-in-the-middle attack between software I wrote and servers I contract and control, wherein protections that were actively put in place are stripped away in order to increase the attack surface. A reverse proxy is something that I actively implemented as part of my infrastructure, and I am contracting for it and paying for it like anything else I rent.
Those can equally happen the other way around. You might put an antivirus filter in place on your own network. Your hosting provider might set up their own reverse proxy.
> But like, think about it this way: Apache is also an SSL termination point. The code in your website is likely 99% "transform a URL into SQL, then transform the result into HTML": it is just a dumb encoder/decoder, and pretty exactly analogous to an SSL termination point. If you really believe in true end-to-end encryption, then having this webserver in the middle is a bad idea: you should route requests directly to database servers and ensure that at no point does any non-database computer have a decrypted copy of the information that will eventually be rendered to the user.
I agree with that - best to have the database and the web server on the same server, communicating via local socket or shared memory. Better still to compile the web layer and the data layer into the same unikernel. Current best practice (e.g. PCI-DSS) seems to accept having an (encrypted) network connection between distinct web and database servers, but only within a single physically secured rack. You're right that if you do the same thing with a load balancer (have it in the same physically secured rack as your web servers, encrypt connections between it and them) then it's no less secure, but I don't think people would want to be using a load balancer within a single rack anyway, since most of the point of a load balancer is availability and you want separate racks for that. Certainly a third-party reverse-proxy is a substantial weakening of security.
> I don't see many people (though if you are, that's great, and then I'd be really happy ;P) insisting that everyone build their own computers and host them at their office, to make sure decrypted data never touches a computer owned and operated by someone else.
I wouldn't go that far - AIUI PCI-DSS etc. require you have physically secured/access-controlled servers but allow you to rent space/power/cooling from a datacenter operator (though they don't get access to your rack, and possibly have to also be audited themselves).
> Let's say that CDNetworks is failing to check SSL certificates correctly: how exactly are you going to attack that against my website? I mean, sure: if you are a state-level actor, that is going to be easy, but otherwise, that's going to be extremely rough. An "antivirus" filter that, as described in this alert, is failing to correctly check SSL certificates... well, that opens you up to attack by amateur attackers that are "close to you", such as a stalker or an ex-spouse or a corporate competitor.
It's a different risk profile to be sure. Are you more worried about someone making a large-scale attack against the remote service you were connecting to, or just against the Internet in general? Or someone making a small-scale local attack? I think both can be serious; it's not just state-level actors but also large criminal rings or even political groups that would potentially have the resources to execute an attack against a particular service (e.g. a medical provider doing something politically contentious, or just anything that accepts credit cards / personal information).