> One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate.
If there is no content, you have no site, so the issue is moot.
> My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code.
The application is content, and the thing you need HTTPS to protect. Otherwise, the application the user actually runs could be anything an attacker wants.
> I would argue this model of application is substantially more secure that sending data across the wire regardless of whether that transmission is encrypted.
It's not, because the code you send controls what happens with the data.
> A man in the middle attack can void the integrity of data crossing the wire, but it cannot trivially break privacy with simple modifications to code.
It can, because in an MITM the attacker impersonates your site. The therefore can bypass any protection offered the same origin policy, because they own your origin.
> if there is no content, you have no site, so the issue is moot.
That isn’t true either as TLS protects http headers in addition to the http body.
Modification of requested content does not void the same origin policy. Just because you could modify page content does not mean you could transmit that content to an alternate location.
> Just because you could modify page content does not mean you could transmit that content to an alternate location.
Yes, if I can masquerade as your domain, I can have the data transmitted back to the same server conducting the attack (which is the “same origin”), which can then send it anywhere else.
How would you do that? If you could do that you could also masquerade the HTTPS connection and simply run HTTPS at the spoofed server using the spoofed X.509 cert from the legitimate web server.
You can't "spoof" a cert, that's its whole point. If you create a new, it won't have a valid signature, and if you copy the original, you won't have the associated private key to create valid responses.
To be more clear a malicious website can rely on fraudulently issued certificates to validate a spoofed domain. This is a bad cert that appears to be valid and establishes the same level of trust. That is why revocation lists and OCSP are necessary.
If there is no content, you have no site, so the issue is moot.
> My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code.
The application is content, and the thing you need HTTPS to protect. Otherwise, the application the user actually runs could be anything an attacker wants.
> I would argue this model of application is substantially more secure that sending data across the wire regardless of whether that transmission is encrypted.
It's not, because the code you send controls what happens with the data.
> A man in the middle attack can void the integrity of data crossing the wire, but it cannot trivially break privacy with simple modifications to code.
It can, because in an MITM the attacker impersonates your site. The therefore can bypass any protection offered the same origin policy, because they own your origin.