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

171–180 of 268 posts

Re: Why Static Websites Need HTTPS

#171

Post by Aaron1011 »

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 believe you're think RFC 6018: https://tools.ietf.org/html/rfc6108

Related HN discussion: https://news.ycombinator.com/item?id=15890551

Re: Why Static Websites Need HTTPS

#172

Post by schoen »

3pt14159 wrote: post #125
tambourine_man wrote: post #29

Let's Encrypt is one of the best things that happened to the web recently. I wish we had more choices though. Relying so much on a single party is unnerving.

It is good, but it is annoying that it came out before we were able to properly lock down domains to cert authorities via DNS. It used to be that a malactor had to buy a new cert when they owned part of your backend if they weren't able to get your private keys. Now they can just use Let's Encrypt.

Can you clarify what restrictions you'd like to see in place? I didn't quite follow this, but if you can describe what you want to see, I might be able to describe a way to do it or request that it be created.

Re: Why Static Websites Need HTTPS

#173

Post by gsnedders »

austincheney wrote: post #146
gsnedders wrote: post #84

Earlier quoted context omitted.

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…

That isn't the SOP stopping this from working—it's CSP.

And CSP vitally is opt-in: if I've performed a MITM attack on example.com I can send whatever CSP header I want, and I obviously control evil.com and therefore can send whatever CSP header I want there.

There are two things that stop that (from here to https://cnn.com) from working: firstly, HN sets:

    Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://cdnjs.cloudflare.com/; frame-src 'self' https://www.google.com/recaptcha/; style-src 'self' 'unsafe-inline'
The vital part here is "frame-src 'self' https://www.google.com/recaptcha/": this allows only two sources to be embedded within a frame (the current origin, i.e., https://news.ycombinator.com/ and the exact path https://www.google.com/recaptcha/).

I can't actually see that CSP header you're getting on https://cnn.com/ (probably because I immediately get redirected to their international edition, which sets a very different CSP header!), but your quote of the error message says what you need to know: it sets a "frame-ancestors" policy (i.e., it can't be put inside a frame except from those sources).

But again—CSP is opt-in, if I control http://example.com and http://evil.com (either directly or through a MITM) I can control what CSP header gets sent on both and therefore CSP provides no defence against such an attack (it does, however, provide a defence-in-depth against XSS and similar attacks, as it makes such an attack as this impossible).

As some evidence the SOP doesn't prevent form submission: https://developer.mozilla.org/en-US/docs/Web/Security/Same-o... says "Cross-origin writes are typically allowed. Examples are links, redirects and form submissions."

If you want more detail about such a thing working, you can follow the form submission algorithm in all of its gory detail: https://html.spec.whatwg.org/multipage/form-control-infrastr...

If you want my promise, as someone who's worked on browsers for around a decade, often around JS and DOM, and dealt with some of the triaging of crossfuzz issues, this absolutely does not violate the SOP and does work with no CSP headers in use.

Re: Why Static Websites Need HTTPS

#174

Post by AgentME »

austincheney wrote: post #160
pixl97 wrote: post #119

Earlier quoted context omitted.

Uh, a MiTM will just show an entire fake site, or it can drop your content and just send a redirect header to any website it wants.

Man in the middle attacks allow an attacker to read data over the wire. It does not mean the attacker and modify that data. It certainly doesn't mean the attacker can move traffic to a different end point.

Usually man in the middle attack refers to an attack where someone controls a connection between you and the server and is able to freely control the connection including modifying or completely fabricating any packets coming through. Your ISP and whoever controls the wifi router you connect to can modify any data coming through like this.

Re: Why Static Websites Need HTTPS

#175

Post by [deleted] »

schoen wrote: post #155
jancsika wrote: post #137

Earlier quoted context omitted.

> The rogue CA would need to perform a classical MiTM as all the other mortals do, having access to the signing keys does not give you special MiTM powers, other than when you actually are able to conduct a MiTM through other means, you'll have valid certs to intercept the connection. But this thread is operating under the thought experiment that the NSA already owns LetsEncrypt. And in reality-- at least according t…

> (Can't remember which program it was that was using some node between the user and the desired server to send back a forged response that would almost always beat the server to the punch.) These were called QUANTUM (with various sub-projects related to specific applications of that capability).

[deleted]

Re: Why Static Websites Need HTTPS

#176

Post by kodablah »

trash_panda wrote: post #108
schoen wrote: post #103

Earlier quoted context omitted.

What would you do with this power? Let's Encrypt certificates are public and don't involve any knowledge of subscribers' private keys.

You don't need to have private keys to exploit this scenario. Let's say you own example.com, and you add a certificate by Let's Encrypt. If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. The value of a CA is that it's a trusted 3rd party that holds a private key used t…

> If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate.

And if they were able to turn off certificate transparency logs or targeted users only without it (or a hacked browser or whatever) to keep site owners from knowing about invalid certs being given.

Re: Why Static Websites Need HTTPS

#177

Post by Sol- »

mrfredward wrote: post #76
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…

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…

I guess one problem with risks on the web when compared to your house analogy is that automation can make all the difference there. For the specific MITM example automation might be less likely, but on computer networks, even very unlikely risks can get amplified by the fact that someone can just automate the exploitation.

If automated drones roamed the country looking for open doors to break into, people might be more worried about their home security. Fortunately, the physical world protects us from wide-scale exploitation.

Re: Why Static Websites Need HTTPS

#178

Post by greglindahl »

jakelazaroff wrote: post #145
trash_panda wrote: post #132

Earlier quoted context omitted.

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.

Not only is the coffee shop using an ISP that is likely MITMing you, insecure coffee wifi routers can be exploited at scale to MITM a lot of coffee shops at once.

Re: Why Static Websites Need HTTPS

#179

Post by SahAssar »

3pt14159 wrote: post #125
tambourine_man wrote: post #29

Let's Encrypt is one of the best things that happened to the web recently. I wish we had more choices though. Relying so much on a single party is unnerving.

It is good, but it is annoying that it came out before we were able to properly lock down domains to cert authorities via DNS. It used to be that a malactor had to buy a new cert when they owned part of your backend if they weren't able to get your private keys. Now they can just use Let's Encrypt.

IIRC Let's Encrypt are more strict in their validation (HTTP, DNS and SNI) than the least onerous authorities before them. The difference is that they are automated and free, but I don't think that I can get any cert I couldn't get before (either for payment or free).

Re: Why Static Websites Need HTTPS

#180

Post by peterwwillis »

If browsers supported a method to provide content securely without the need to encrypt everything, lots of uses of the web would not be hampered by the TLS-everything-that-moves movement. The limitations we have accepted in our browsers are what causes these conflicts. But we don't have to accept them. We could do with less propaganda and more compromise and innovation.
Post reply on HN