Live data from Hacker News

Deprecating Non-Secure HTTP

blog.mozilla.org

41–50 of 318 posts

Re: Deprecating Non-Secure HTTP

#41

I agree with trying to phase out HTTP, but I think their method is "annoying." What do features have to do with HTTP Vs. HTTPS? It just seems like an arbitrary punishment. Wouldn't it just be significantly easier to simply change the URL art style to make clear that HTTP is "insecure." Like a red broken padlock on every HTTP page? That has the following advantages: - HTTP remains fully working for internal/developmen…

The actions Mozilla proposes sound awful. I believe that a secure (from the NSA) Internet is the way forward. But this seems so goofy to me. There are legitimate reasons for a site not to be hosted on HTTPS. * It is a static site with no forms or logins * It is non-critical info * The site operator can't afford a certificate (Let's Encrypt is only one site...) As you say: Color-code sites with a bit more granularity.…

What part of this proposal made it seem like static sites with non-critical info would be "crippled" over HTTP?

Re: Deprecating Non-Secure HTTP

#42

I should be happy about this -- who wouldn't want the entire web to be encrypted -- but SSL is so broken for normal people. SSL is expensive (wildcard certificates run $70 a year and up), confusing (how does one pick between the 200 different companies selling certificates?), and incredibly difficult to set up (what order should I cat the certificate pieces in again?). If SSL doesn't change, this move will cut the li…

This is a decision that should span out on several year, while there is Let's Encrypt arriving. I don't see the problem.

Re: Deprecating Non-Secure HTTP

#43

Earlier quoted context omitted.

Can you still serve a static site from AWS' S3 with an SSL cert? Last time I checked, you can't unless you use Cloudfront in front of it.

AFAIK, you can't serve pages from S3 over HTTPS using your own domain name, but https://bucketname.s3.amazonaws.com/ works fine. So if you have some other way of serving your HTML pages, you can include other static assets directly from S3 without triggering browser mixed-content warnings.

[deleted]

Re: Deprecating Non-Secure HTTP

#44

If things like "python -m SimpleHttpServer" don't work then developers will switch browsers. I don't think anyone is seriously considering what it will take to migrate the long tail of development tools that use HTTP on localhost.

And what about testing small applications on remote servers like "dev.my-personal-site.com"? I don't want to pay $15 for an SSL certificate and 15 minutes of my time just so I can get my dumb lunch break tetris HTML app running on the machine I SSH into from my tablet.

Re: Deprecating Non-Secure HTTP

#45

For Tor and I2P hidden services, HTTPS is redundant so I don't really see the point in punishing people for things like this. Loopback sites are an obvious exception to the "HTTPS is better" rule as well.

I'm pretty sure you want to avoid HTTP websites while on TOR. HTTPS encrypts your connection, while TOR anonymizes it.

This makes sense for clearnet stuff. Hidden services are encrypted before transit.

Re: Deprecating Non-Secure HTTP

#46
post #29

For Tor and I2P hidden services, HTTPS is redundant so I don't really see the point in punishing people for things like this. Loopback sites are an obvious exception to the "HTTPS is better" rule as well.

[deleted]

Encryption and server authentication are built into the Tor hidden services protocol. The destination is the exit node.

Re: Deprecating Non-Secure HTTP

#47
This is stupid. There are all kinds of use cases where you don't care who knows what you're looking at, or whether it is authentic.

Say I navigate to some restaurant's web page using HTTP. Even if I used HTTPS, someone spying on my traffic would know what I'm reading, if the IP address is a dedicated server for that web site only. Whether I use HTTP or HTTPS, they could infer that I'm interested in visiting the restaurant.

Secondly, I'm only interested in the opening hours. That is not classified information.

I suppose that a MITM attack could be perpetrated whereby the attackers rewrite the opening hours. I end up going to the place while it is in fact closed (and the area happens to be deserted), making me an easy target for the attackers to rob me.

Okay, okay, please deprecate HTTP; what was I thinking!

And that restaurant better get a properly signed certificate; no "self signed" junk! Moreover, I'm not going to accept it over the air the first time I visit, no siree. DNS could be redirecting me to a fake page which also has a signed certificate. I'm going to physically go the restaurant one time first, and obtain their certificate from them in person, on a flash drive, then install it in my devices. Then I'm going to pretend I was never there and don't know their opening hours, and obtain that info again using a nearly perfectly secured connection!

Re: Deprecating Non-Secure HTTP

#49
This potentially removes the relative anonymity that the entire non-commercial web offers (and in fact was largely built on, post-DARPA). Free DV certificates may help minimize that negative effect, but this entire scheme still further increases reliance on a badly broken CA system.

This seems like a somewhat rushed idea with good intentions but without sufficient community discussion.. rather than put all our eggs in one basket with LetsEncrypt et al, which are noble efforts to fix a broken system, are there things we can do right now in terms of favoring self-authentication of self-signed certs? This whole thing feels a bit like a witchhunt to punish non-HTTP sites.

Re: Deprecating Non-Secure HTTP

#50
post #5

I'm very glad to see this. It's embarrassing to think that, just a few years ago, many major websites used HTTP for all but their login pages, and it took Firesheep to get them into gear. > For the first of these steps, the community will need to agree on a date, and a definition for what features are considered “new”. For example, one definition of “new” could be “features that cannot be polyfilled”. I hope that inc…

WebRTC uses DTLS as it's protocol which is encrypted.

That's correct but that doesn't invalidate chimeracoder's point. His/her point was to disable the ability to use WebRTC with Javascript served from an unencrypted website. Currently, https://github.com/diafygi/webrtc-ips/blob/master/index.html can work on unencrypted websites. The fact that WebRTC has an encrypted connection is irrelevant.
Post reply on HN