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

151–160 of 268 posts

Re: Why Static Websites Need HTTPS

#151

Post by austincheney »

AgentME wrote: post #123
austincheney wrote: post #17

Earlier quoted context omitted.

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

If evil.com serves the proper CORS headers, then any site is allowed to make AJAX calls to it. Also, the attacker could inject tags with a src attribute pointing to " https://evil.com?userdata=..." . Also, if the attacker is already man-in-the-middle attacking yoursite.com, they could make the site's code make ajax calls to "yoursite.com/nothing-to-see-here". Users looking at the network requests may not notice anyth…

CORS requires an HTTP header white listing allowed domains. If the attacker can modify the HTTP headers they don't need to modify the HTTP body in order to perform an attack.

> Also, the attacker could inject tags

First, the image needs to be requested using the same protocol that requested the page or it will notify the user of insecure assets. Second, but they would have to write a custom script to gather the data to append as the URI query string. Third, the image would need to be injected after the user has manually entered information to the site, which eliminates static images in the HTML source. Fourth, actually test this. When I test it I get a CORS error in the browser. Strangely, Chrome reports this as a warning instead of as an error, but the request is blocked and it never leaves the browser.

> Also, if the attacker is already man-in-the-middle attacking yoursite.com, they could make the site's code make ajax calls to

No, that is not allowed by the browser and will throw an error. It violates same origin policy. If you can figure out how to break same origin policy Google will pay you $5000 for reporting a significant issue to their bug bounty.

Re: Why Static Websites Need HTTPS

#152

Post by austincheney »

dragonwriter wrote: post #96
austincheney wrote: post #86

Earlier quoted context omitted.

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

> Just because you could modify page content does not mean you could transmit that content to an alternate location. Yes, if I can masquerade as your domain, I can have the data transmitted back to the same server conducting the attack (which is the “same origin”), which can then send it anywhere else.

> Yes, if I can masquerade as your domain

How would you do that? If you could do that you could also masquerade the HTTPS connection and simply run HTTPS at the spoofed server using the spoofed X.509 cert from the legitimate web server.

Re: Why Static Websites Need HTTPS

#153

Post by derefr »

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…

You know what's even easier than a simple Nginx server setup? A simple https://caddyserver.com server setup. Which will automatically provision a LetsEncrypt cert for you, no configuration required.

Or, let's go even simpler: no server of your own at all. Anyone who uses GitHub Pages for their static site, gets an automatic LetsEncrypt cert provisioned for their custom domain if they set one. (I'm honestly surprised that other SaaS hosts that set you up with some service on a subdomain, and allow you to map it to a custom domain, haven't followed along and done the same. It's an easy feature to offer!)

Deploying Nginx is a uniquely-bad example to use right now for TLS ease-of-use. There are all sorts of setups where TLS "just happens"—some of which web-development novices will likely encounter before they become experienced enough to consider "deploying their own web server" to be a sensible action.

Re: Why Static Websites Need HTTPS

#154

Post by austincheney »

AgentME wrote: post #126
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…

A malicious router (or any entity between you and the site you're trying to connect to) redirecting your traffic is the exact situation that HTTPS protects against.

It does not. Redirection from the router involves only TCP and DNS actions. HTTPS does not encrypt TCP. HTTPS is an encrypted tunnel that rides over TCP. HTTPS is a layer 7 protocol while TCP is a layer 4 protocol. You can encrypt TCP as well if you are using IPSEC. IPSEC is built into IPv6 by default, but it fails with NAT over IPv4, which is still most of the internet.

None of that is what HTTPS is for though. The primary function of HTTPS is to prevent HTTP traffic from being sent in the clear so that anybody could read it.

Re: Why Static Websites Need HTTPS

#155

Post by schoen »

jancsika wrote: post #137
trash_panda wrote: post #115

Earlier quoted context omitted.

Of course, you're right. My phrasing was not the best. 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. Totally agree with your point about trust being a very hard problem to solve, tha…

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

Re: Why Static Websites Need HTTPS

#156

Post by austincheney »

jakelazaroff wrote: post #88
austincheney wrote: post #83

Earlier quoted context omitted.

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.

You really didn't read what I wrote. If the malicious site uses the valid domain and a spoofed cert for that domain it cannot tell the difference and will establish the very same trust. The browser has no way of knowing if the requested domain is hosted from the appropriate IP address. This is all handled by the DNS system. DNS lookups and caching are not a function of the browser.

Perhaps you will take it more seriously if it comes from Wikipedia: https://en.wikipedia.org/wiki/Certificate_authority#Validati...

Re: Why Static Websites Need HTTPS

#157

Post by Groxx »

kelnos wrote: post #147
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…

The worry is well-founded too, as e.g. tons of hotels I've visited have added junk, even recently, as have some coffee shops (mostly prior to widespread wifi-ification though, I haven't seen it in a while). Airplane / airport wifi has as well.

HTTP feeds this kind of hostile behavior.

Re: Why Static Websites Need HTTPS

#158

Post by austincheney »

xfer wrote: post #71
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…

That's not how TLS works, your browser has a list of CA(certificate authority)s it can trust, unless a CA gone rogue(which has happened before), you can't change traffic and make it appear from someone else(read on public-key signing).

Where is the key signed? It is signed at the web server providing the HTTPS response. It isn't signed by the CA. The CA provides a digital signature to the certificate to validate the certificate using cryptography (X.509 standard). Digital signature algorithms are very different from the encryption algorithms used in the PKI model.

Wikipedia also explains this limitation with regard to breaking DNS: https://en.wikipedia.org/wiki/Certificate_authority

Re: Why Static Websites Need HTTPS

#159

Post by austincheney »

untog wrote: post #53
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…

It's far more common for this to happen beyond the router. A few years ago there was a spate of ISPs injecting ads onto sites they don't control, because HTTP doesn't prevent them from doing so. HTTPS does.

I remember that and defacement is a valid and important concern. This is probably the most realistic and valid concern raised here.

These attacks would work well for advertising because the ISP would inject an iframe into the page that sources unique content and beacons data back to the source of the iframe. This breaks anonymity, but it doesn't break privacy since the code in the iframe cannot access the surrounding page.

Re: Why Static Websites Need HTTPS

#160

Post by austincheney »

pixl97 wrote: post #119
austincheney wrote: post #16

Earlier quoted context omitted.

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

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.
Post reply on HN