Hacker News Reader

Comment by huuuz | Hacker News Reader

How are downloads performed over http "potentially malicious"?

This would be massively annoying for my local network. I trust that I do not mitm myself for malicious reasons and really do not feel like setting up certs on my lan...

Talking about certs, nowadays it seems browsers want to make you believe that self signed certs are some diabolical work straight from hell. Using self signed certs with websockets on Firefox is actually nearly impossible [1].

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1187666

The push to demonize self-signed certs literally makes me think browsers are in the pocket of BigCert

Certificates from Let's Encrypt are free.

Thanks man, but I don’t remember asking anything?

I do wish there was a way to disable all those https-only protections in a browser for development on the local machine. Yes I know for localhost they are sometimes disabled (but not always, like e.g. samesite=none cookies), but sometimes you want to test cross-domain interactions using a tool like dnsmasq, and it gets to be a real hassle

https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlo...

> Targeted users in Turkey and Syria who downloaded Windows applications from official vendor websites including Avast Antivirus, CCleaner, Opera, and 7-Zip were silently redirected to malicious versions by way of injected HTTP redirects. This redirection was possible because official websites for these programs, even though they might have supported HTTPS, directed users to non-HTTPS downloads by default.

A MitM (e.g. an untrusted WiFi network) could replace a download by a malicious version.

In that case the html text of the page could be replaced by the attacker so the download link points to an https link.

It’s for https sites that link http downloads.

This absolutely can happen. A few years ago I discovered [0] Atlanta Airport's public WiFi was injecting ads into non-https pages. A malicious actor changing download links is not a far fetched possibility.

[0] https://twitter.com/codelemur/status/1052285395575164929?s=2...

At least it can't be an HTTPS link to the same domain. But even if a user notices this, it's not worth a lot in the age of CDNs on weirdly abbreviated separate domains...

Firefox already aggressively alerts if you're not on an SSL secured page. They didn't for downloads.

They can be MITM'd by anyone on a hop between you and the server, and unless they're an authenticode-signed exe they could also have been subtly tampered with at rest

Mind you, HTTPS doesn't mean downloads are safe. Not remotely so. HTTP just means they're way less safe, and if you're on a HTTPS website it definitely should not be serving downloads over HTTP

I wonder what "insecure connection" means. Does that include `http://localhost`?

I would expect the same rules as for secure contexts [1], namely "Locally-delivered resources such as those with http://127.0.0.1 URLs, http://localhost and "http://*.localhost URLs (e.g. http://dev.whatever.localhost/), and file:// URLs are also considered to have been delivered securely."

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

The browser can’t know if the download was modified in flight and actually came from the server you requested it from.

Mozilla is foolish to buy into Google's bad faith attempt to create barriers to entry for small/old sites and further centralize the web.

Yeah how dare Mozilla force sites to pay for TLS certificates! It’s a racket I tell you! If they’re going to be required in order to be on the internet they should be free

Mozilla: Okay, done.

Time is money, I'm sure some users visiting websites that don't have the luxury of being maintained by multinational corporations will experience issues as a result of this change. TLS certificates are also not trivial to set up or renew if you require a wildcard certificate.

Wildcard certificates are the much much easier case. You don't have to mess with your web server or routes at all. You just hook up certbot with your DNS provider and say "get me a cert for '*.mydomain.business", run the renew in a cronjob (which certbot does automatically by default now) and never touch it again. I've had certbot running for like 4 years with no interruption with this setup.

The Venn Diagram of people who forgo managed hosting with SSL built-in and set up their own servers to host HTML pages on the internet and the people capable of following a guide to configure certbot is a circle.

Not all DNS providers are supported by certbot, so sometimes it's impossible to automate. It's not infrequently that I come across sites with expired certificates nowadays.

And what of those who have left their old site (that has no need for TLS) online for years without ever knowing 'insecure' HTTP is being deprecated? I don't think their sites breaking and showing warnings should be acceptable when the security benefits are so marginal.

It doesn’t really matter if all DNS providers are supported because you can just delegate your _acme_challenge zone to any DNS provider that is, like Route53 or to your own DNS server.

> Time is money

Let's Encrypt has made installing a cert a 5 minute process, including setting up automated renewals.

Even at lawyer rates ($200/hour), that's still less than a one time $20 "cost".

You should see what godaddy charges to manage SSL for a WP site!

Let me see if I understand this, SSL is bad because one very well known to be shitty hosting provider charges lots of money for it? And we should hold back securing web traffic on the internet until such time as GoDaddy changes their pricing structure?

Look I get it, if I hosted sites on shitty providers and couldn’t change because of corporate BS I would be frustrated too. But “everyone else should change to accommodate my problems” isn’t the right response. It’s the same with crappy SSL middleboxes, I feel for people who have to deal with broken sites because of them but breaking TLS as a workaround can’t be the way forward.

I think you misunderstood me and are reading a lot more into my post than I intended. I was just making the point that godaddy's annoyingly large fee is an example of a contributing factor to the plague of non-SSL sites.

Encrypting web traffic is a necessary step in making dragnet surveillance impossible.

I don't care if they 'dragnet survey' my users who are just looking for 20-year-old data sheets. Fact is, not everything needs unbreakable encryption, or a warning label for lacking it.

Reply on news.ycombinator.com