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

81–90 of 268 posts

Re: Why Static Websites Need HTTPS

#81

Post by grosjona »

yjftsjthsd-h wrote: post #75
zzzcpan wrote: post #54

Here's the truth about security: people are clueless about it and so corporations and governments abuse that by pushing their own agendas, not related to security. Same corporations that tell you to "secure" your unimportant static website with https also want to force you to run random javascript in your browser from unknown parties, identify you at all times, link everything to your phone number, etc. In the end we…

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.

Re: Why Static Websites Need HTTPS

#82

Post by austincheney »

majewsky wrote: post #45
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.

> 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 woul…

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

Re: Why Static Websites Need HTTPS

#83

Post by austincheney »

jakelazaroff wrote: post #50
austincheney wrote: post #41

Earlier quoted context omitted.

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.

That is true after the certificate chain is validated by the browser, but not before. A malicious router attack could just as easily modify the initial http request so that the user is directed to the domain on a spoofed IP before HTTPS trust violation. The malicious http server would also have to spoof the original cert though, but then they get malicious trusted https on the trusted domain that returns similar looking code.

Re: Why Static Websites Need HTTPS

#84

Post by gsnedders »

austincheney wrote: post #82
majewsky wrote: post #45

Earlier quoted context omitted.

> 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 woul…

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 page (and f.contentDocument will then be null) is irrelevant, because the data loss has already happened.

Re: Why Static Websites Need HTTPS

#85

Post by crtasm »

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…

High bill because someone walked in and watched TV for three days? (I'm guessing it was actually due to heating/aircon)

Re: Why Static Websites Need HTTPS

#86

Post by austincheney »

dragonwriter wrote: post #26
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 tha…

> if there is no content, you have no site, so the issue is moot.

That isn’t true either as TLS protects http headers in addition to the http body.

Modification of requested content does not void the same origin policy. Just because you could modify page content does not mean you could transmit that content to an alternate location.

Re: Why Static Websites Need HTTPS

#87

Post by tialaramex »

skuzye wrote: post #3
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…

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's a corner case where, surprisingly, your parent's point kinda works, SRI:

https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

If a site exists just to host resources protected with SRI then you can in principle use HTTP, the resource integrity protection will fire and so long as the main page's origin was genuine (e.g. protected with HTTPS) you come out OK...

But SRI isn't even implemented at all in Safari or IE. So, there's a good chance if you have Mac or Windows users they're screwed.

This really is a corner case, even if some day Safari and IE get SRI, you should always just use HTTPS to actually protect resources in flight. The purpose of SRI is more around not fully trusting a sub-resource you've intentionally linked not to be changed.

Re: Why Static Websites Need HTTPS

#88

Post by jakelazaroff »

austincheney wrote: post #83
jakelazaroff wrote: post #50

Earlier quoted context omitted.

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.

That is true after the certificate chain is validated by the browser, but not before. A malicious router attack could just as easily modify the initial http request so that the user is directed to the domain on a spoofed IP before HTTPS trust violation. The malicious http server would also have to spoof the original cert though, but then they get malicious trusted https on the trusted domain that returns similar look…

It doesn't matter. The browser can use the SSL certificate and the corresponding public key to verify that the contents of the connection originated from the server at the domain it expects. Unless the server's private key or browser's root certificates are compromised, the connection cannot be spoofed without being detected.

Re: Why Static Websites Need HTTPS

#89

Post by Qub3d »

I'm going to sorta break the prime directive and link the n-gate rebuttal to these articles: http://archive.fo/xcQ5j

Its a bit heavy-handed, but it does bring up a good point: A lot of this argument for HTTPS-by-default is all on top of assumptions about who is responsible for data security. We're doing a lot and things are improving, but the general public still are all yelling at websites for misusing data that we willingly gave over in the first place [0].

[0]:https://xkcd.com/743/

Re: Why Static Websites Need HTTPS

#90

Post by yjftsjthsd-h »

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.

I would think that there are enough competing vendors, and they are sufficiently interchangeable, that one vendor having low prices will drag the whole market down. That is, I believe that CAs are actually a nearly efficient market.
Post reply on HN