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

201–210 of 268 posts

Re: Why Static Websites Need HTTPS

#201

Post by parliament32 »

nofunsir wrote: post #100
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.

Do we have conclusive evidence yet that LE is not a honey pot? I mean, if I were the NSA...

It's a valid question, with two possible threat models:

1) the honeypot uses your private keys to MITM connections

Let's Encrypt doesn't handle your private keys. You generate them yourself, and submit a CRL to LE to get a cert issued. They have no knowledge of your private key.

2) the honeypot issues fake certs

Let's Encrypt submits a log of every cert issued, see https://crt.sh/ . To verify, it'd be pretty trivial to create a browser extension (if one doesn't exist already) that checks whether certs you encounter appear in the certificate log.

Re: Why Static Websites Need HTTPS

#202

Post by [deleted] »

iamben wrote: post #62

Two stories. Firstly, I had a fair amount of websites with a now EIG owned company for about 10 years. It was just a shared host, but they're all low traffic, and I could easily add a domain name and spin up a blog/project. A few years back I needed https for an API I was working with - the cost was something like $40 a year for the domain, for a project that wasn't a money spinner. So I found another (read: free) wa…

[deleted]

Re: Why Static Websites Need HTTPS

#203

Post by fwip »

Avamander wrote: post #133
EGreg wrote: post #74

People here are bringing up the difficulty for a regular user to set up HTTPS. I want to go one further: WHY does a regular user need to buy a human-readable domain name, maintain it, and pay for a hosting company to host on that domain? It used to be worse - you had to have your own machine or use some crappy shared hosting service. Amazon figured out that letting people share managed virtual machine instances was g…

> I want to go one further: WHY does a regular user need to buy a human-readable domain name, maintain it, and pay for a hosting company to host on that domain? Because there's no interest in that. Getting a domain name is already cheap and easy. > Storing chunks of encrypted data using Kademlia DHT or similar [...] I've yet to see any P2P system have low latency, high speed and high reliability. > All underlying URL…

I'm not trying to advertise, but Beaker browser does a real good job of making p2p delivery transparent to the end user. It's probably slower than most sites in normal usage, but certainly acceptable speeds for static sites, and it performs better under the hug-of-death a site gets when posted on Hacker News. :)

Plus, it already has existing methods to map DNS records or servers to the p2p records, so I can access dat://beakerbrowser.com/ or dat://epa.hashbase.io/ and get it served across the p2p network or pull it up offline if I've viewed it before.

Re: Why Static Websites Need HTTPS

#204

Post by icebraining »

austincheney wrote: post #166
gsnedders wrote: post #5

Earlier quoted context omitted.

> One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate. 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. I would argue this model of application is substantially m…

> and then sends it to evil.com. How would a man in the middle attack grant you that? This is the reason same origin policy exists. It is the foundation of web security. If can break SOP and prove it in a demonstration you can report this issue to Google as a defect in the top tier of their bug bounty for a sizable reward.

Without SSL, I can inject code directly into the main HTML, in the same origin context as yours.

Re: Why Static Websites Need HTTPS

#205

Post by fmpwizard »

nanoscopic wrote: post #193

I admin a number of different websites. The majority of them are static. I have forced https redirect on some of them. On others I do not. The only benefit of https I perceive in the case of static public content is that ISPs cannot easily monitor which specific pages on my domains are being visited. With plain http they could. I don't particularly care if people get MITM'ed when visiting my static sites. If they did…

> generally is because they chose to use unsafe public access points

It sounds like you are penalizing users for not using a vpn or some other method when out of their homes. Yes, people can do that, but in 2018 having https on the sites you manage is a lot easier than asking every possible visitor to use a vpn. I hope you would reconsider and enable https on all the sites you are an admin.

> If your ISP is MITMing you, I think you have bigger problems then whether they change the content of my static site when you visit it. If they were, they could potentially target your initial download of your browser and downgrade to http to infect your browser so that you never realize after that that https is faked out...

They could, and maybe in countries other than the US you have plenty of ISP choices, but in many places in the US, you are stuck with just one ISP.

And so far, we know that ISPs are manipulating http traffic but so far they haven't gone all the way to give you an infected browser. Again, it is possible, but I think that a better approach is if we all do as much as we can to help each other, the internet could be a better place.

Re: Why Static Websites Need HTTPS

#206

Post by icebraining »

austincheney wrote: post #182
AgentME wrote: post #169

Earlier quoted context omitted.

>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. The attacker owns evil.com. They can make it have any headers they want, and then javascript on yoursite.com or any other site is allowed to make ajax requests to it. (Of course, they'd still need to do a man-in-the-middle attack on yoursite.co…

> The attacker owns evil.com. They can make it have any headers they want, and then javascript on yoursite.com or any other site is allowed to make ajax requests to it. Only if the page is originally requested from evil.com or if evil.com is listed in the CORS http header from the legitimate domain. In order for this attack to work evil.com needs to be added to the CORS list in the http header and JavaScript needs to…

if evil.com is listed in the CORS http header from the legitimate domain.

That's not how CORS works; the header is read from the domain being called from JavaScript, not from the domain where the JavaScript came from. So in this case, the injected JS will call evil.com, and so the CORS headers will be read from evil.com.

Re: Why Static Websites Need HTTPS

#207

Post by icebraining »

austincheney wrote: post #148
dragonwriter wrote: post #32

Earlier quoted context omitted.

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

They would need configuration access to a router in the path to perform DNS actions in order to accomplish this.

Nope, they just need to poison its ARP cache. You can do that easily with a tool like Ettercap, if the router is in the same LAN as your machine. Every request (DNS, HTTP, etc) from the victim machine will now go to yours, and you control the responses it gets.

Note that they aren't impersonating the domain to the whole world (hence they can't get a valid certificate, since no CA will accept their request), only to a local computer.

Re: Why Static Websites Need HTTPS

#208

Post by peterwwillis »

ezekg wrote: post #195
peterwwillis wrote: post #194

Earlier quoted context omitted.

Most of the content on the web is intentionally open to the world.

But our personal data is not. So much data is potentially made available from an unencrypted HTTP request.

Nobody is saying that personal data should be unencrypted.

Re: Why Static Websites Need HTTPS

#209

Post by icebraining »

austincheney wrote: post #152
dragonwriter wrote: post #96

Earlier quoted context omitted.

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

You can't "spoof" a cert, that's its whole point. If you create a new, it won't have a valid signature, and if you copy the original, you won't have the associated private key to create valid responses.

Re: Why Static Websites Need HTTPS

#210

Post by icebraining »

austincheney wrote: post #165
pc86 wrote: post #27

Earlier quoted context omitted.

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.

> You can break/disable SOP when it's trivially easy to edit the code. How? SOP isn't related to the code. It is only concerned with the page address.

The point is that you can put the code wherever you want, including inside the same origin context (e.g. right in the main HTML).
Post reply on HN