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

141–150 of 268 posts

Re: Why Static Websites Need HTTPS

#141

Post by plopz »

trash_panda wrote: post #132
jakelazaroff wrote: post #130

Earlier quoted context omitted.

> To exploit a MiTM you need to be on the same network, this could be achieved through your local-cafe's WiFi or by compromising an internal system of a local network. Or, say, your ISP injecting ads and tracking scripts into unencrypted pages your browser requests.

Holy, I forgot about that one! You're totally right and I'm surprised it's not one of the main arguments for this push for HTTPS.

I think thats why google has been pushing so hard for https, isps were able to do tracking just as well under http, so google wants to shut that door.

Re: Why Static Websites Need HTTPS

#142

Post by saryant »

th3l3mons wrote: post #60
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…

The other side I would pose is: do you want anyone to alter your responses? I'm currently trying to find the RFC, but I recall an ISP defining an RFC for tampering with HTTP responses in-transit. In addition, I also recall seeing Comcast (I believe) injecting JS to users that they are approaching their plan limits. Obviously, not the end of the world. But do you want any third party to easily alter the response from…

I've also seen airlines do this with their in-flight wifi. Looking at you, Icelandair.

Re: Why Static Websites Need HTTPS

#143

Post by yardstick »

dragonwriter wrote: post #95
mrfredward wrote: post #76

Earlier quoted context omitted.

My house is insecure. There's no alarm, so anyone could just smash a window and steal my TV. But replacing my TV costs a lot less than an alarm system, and the risk of being caught for theft is greater than the TV's value. My landlord sent a handyman in while I was on vacation once, and the handyman didn't close the front door all the way (or try to lock it). My door was open for 3 days, visible from the street, and…

> A MITM attack on a static site is definitely possible, maybe even easy, but I'm not going to worry about it unless I have something important to protect. HTTPS doesn't protect the content of your site from being stolen, it protects your users from hostile third-party content masquerading as yours.

> HTTPS doesn't protect the content of your site from being stolen, it protects your users from hostile third-party content masquerading as yours.

Hostile third party content is only hostile because the client used to access the content does not take client security seriously.

Food for thought: As an end user consumer visiting random, benign websites, I want my browser to be protecting me against hostiles, rather than relying on website operators to do that for me. Just like I run antivirus on my machines instead of relying on everyone else to run it.

Re: Why Static Websites Need HTTPS

#144

Post by [deleted] »

grosjona wrote: post #81
yjftsjthsd-h wrote: post #75

Earlier quoted context omitted.

How are those related? Letsencrypt doesn't try to identify anyone, and certainly doesn't run JavaScript on your site.

I wonder what would happen if Let's Encrypt started charging for their service AFTER HTTPS became compulsory. Seems like a great (but evil) business strategy. All these CAs could just start increasing their prices and we'd all be forced to pay. If you understand human behavior, then you know that this WILL happen eventually.

[deleted]

Re: Why Static Websites Need HTTPS

#145

Post by jakelazaroff »

trash_panda wrote: post #132
jakelazaroff wrote: post #130

Earlier quoted context omitted.

> To exploit a MiTM you need to be on the same network, this could be achieved through your local-cafe's WiFi or by compromising an internal system of a local network. Or, say, your ISP injecting ads and tracking scripts into unencrypted pages your browser requests.

Holy, I forgot about that one! You're totally right and I'm surprised it's not one of the main arguments for this push for HTTPS.

IMO it's really the only compelling argument for HTTPS on sites that don't deal with traffic worth intercepting. Other than that, I agree with you re café Wi-fi, etc: the man-in-the-middle risk is so small and localized that it may as well not exist.

Re: Why Static Websites Need HTTPS

#146

Post by austincheney »

gsnedders wrote: post #84
austincheney wrote: post #82

Earlier quoted context omitted.

The iframe is still limited by same origin. The browser won’t let you cross the frames border if the domains are different. There is no attack there

In the form case that's easy: var f = document.createElement("iframe"); f.style.display = "none"; document.body.appendChild(f); // note that the iframe has now synchronously loaded about:blank, which is treated as same-origin var f_doc = f.contentDocument; f_doc.innerHTML = " "; f_doc.querySelector("form").submit(); f_doc = null; // allow the old document to be GC'd The fact the iframe navigates to a cross-origin pag…

Did you try that code? I tried it in the browser console on this very page and it throws a security error in Firefox. It throws a null error in Chrome, so I modified the code so that the form actually has a method and an action, but it still fails. Chrome throws valid error messaging if the iframe action is not https but the actual page is. Otherwise Chrome still throws an error, but the response is not intelligible if the domain has no HTTP content security header. If the site has a content security header then the error message is valid:

  Refused to display 'https://www.cnn.com/' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' https://*.cnn.com:* http://*.cnn.com https://*.cnn.io:* http://*.cnn.io:* *.turner.com:* courageousstudio.com".
Cross origin still applies. This is not something the browser will let you bypass.

Here is the code I tested with:

  var f = document.createElement("iframe"); f.style.display = "none"; document.body.appendChild(f);var f_doc = f.contentDocument; f_doc.getElementsByTagName("body")[0].innerHTML = ""; f_doc.getElementsByTagName("body")[0].getElementsByTagName("form")[0].submit(); f_doc = null;
I know everybody on here is a CCIE, CISSP, and a client side JavaScript expert, but I promise none of these violations work. If they did work the malicious actor would be stealing far more than simple form data and the web would be completely broken.

HTTPS is important because it prevents data from moving across the wire as plain text for everybody to see. It isn't magic.

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

Re: Why Static Websites Need HTTPS

#147

Post by kelnos »

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…

As a website visitor, if I don't see HTTPS, I worry -- ever so slightly -- that someone has added some junk to the content along the way, whether it's my ISP or someone with a fake AP in a coffee shop.

I also just don't want ISPs etc. knowing what content I read, in minute detail. No, I don't "have something to hide", but I'm sick of it being so easy for companies to build detailed profiles of my habits and then sell that information to people who want to sell me things. No thanks.

Sure, I could run a VPN all the time. But I think to be a good web citizen, site operators should do all they can to protect their users from malicious actors out there. TLS is just one piece of that.

And honestly, for a modest static blog site, you can set up Let's Encrypt in less than an hour.

Re: Why Static Websites Need HTTPS

#148

Post by austincheney »

dragonwriter wrote: post #32
austincheney wrote: post #17

Earlier quoted context omitted.

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

How is the same origin policy helping when the attacker is impersonating your domain to the target?

How would the attacker impersonate your domain? They would need configuration access to a router in the path to perform DNS actions in order to accomplish this. If they had that would they would have their eye on much bigger prizes than merely impersonating an Apache server. If they did actually have that they could impersonate your domain, your site content, and your HTTPS trust with a spoofed cert. In that case HTTPS is more harm than good because you are still completely compromised, but with a false trust relationship.

Re: Why Static Websites Need HTTPS

#149

Post by austincheney »

mechanicalpulse wrote: post #37
austincheney wrote: post #17

Earlier quoted context omitted.

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

Yes. https://en.m.wikipedia.org/wiki/Cross-origin_resource_sharin...

CSRF works the same whether the site is served via HTTP or HTTPS. CSRF attacks the server from the client, so HTTPS doesn't protect from this. HTTPS is an end-to-end encrypted tunnel.

Re: Why Static Websites Need HTTPS

#150

Post by austincheney »

untog wrote: post #44
austincheney wrote: post #28

Earlier quoted context omitted.

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.

How would that help? See this: https://news.ycombinator.com/item?id=17861667
Post reply on HN