Live data from Hacker News

Deprecating Non-Secure HTTP

blog.mozilla.org

181–190 of 318 posts

Re: Deprecating Non-Secure HTTP

#181
post #119

Earlier quoted context omitted.

One thing I've never been able to figure out from Let's Encrypt's website - will you be able to get a certificate, without hosting your own instance? Or will it be limited to servers you can actually install their program on? Also, I assume they'll get the root CA included by all major vendors/browsers?

You don't have to run the Let's Encrypt client, but you do have to be able to do things to prove that you control the domain. Currently the Let's Encrypt client assumes that it's being run on the same machine on which domain control will be proved (though not necessarily the same machine where the cert will eventually be deployed). Someone could write another client application which gives instructions to complete th…

Specifically I'm thinking about current procedures to verify domains - either it's through your registrar (in which case you're golden), or an alternative like adding a specific key to a TXT record, or uploading a particular file to the domain root.

Re: Deprecating Non-Secure HTTP

#182

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…

Can someone explain why we can't give SSL certificates along with domain registration? We already trust the DNS, don't we?

It's because all CAs are able to sign certs for all domains. Browsers simply do not trust your average domain registrar enough to give them power over all domains.

Now you might say don't trust the registrar, trust the people who run the .com (or whatever) TLD. That's getting close to what DNSSEC does, which some people say is better. But CAs weren't designed for this like DNSSEC. With the way CAs work, we would have to give the runners of .com power over all domains, which some people might not think is so bad. But it would also mean we would have to give the owners of .sucks power over all domains as well, which most people would be against.

Re: Deprecating Non-Secure HTTP

#183

This kind of implies that HTTPS is secure. :) I dont think there is anything wrong using HTTP internally in a datacenter for data that is not sensitive (like monitoring, statistics, etc.). I guess you can still access these in legacy mode. I think the title should be that HTTP is getting phased out for public internet use or something.

actually, its not really "safe behind a firewall"

what if im inside the network i tell your monitoring that everythings ok while i break stuff?

Re: Deprecating Non-Secure HTTP

#184

Why do we have to pay for an SSL certificate? Shouldn't it be free?

You would think so. The problem is that browsers have gone and made self-signed certs suspect, and yet not created, for example, a well-established foundation for signing such certs.

Isn't this basically extortion then?

Re: Deprecating Non-Secure HTTP

#185
post #89
post #44

Earlier quoted context omitted.

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.

I am long past confused and heading toward awed, at this point, that it's not a common-sense practice for every web developer to generate a personal self-signed root-CA cert, and install it on all of their machines. It's as basic as having an SSH or PGP key. Setting up a new box? Put your CA-cert in its trust roots. Then use your CA to generate a server cert for it; plop that in /etc/nginx and wherever else. Now it's…

> It's as basic as having an SSH or PGP key.

And you're surprised that not every developer has done this? A minority of the developers I've ever worked with have ever done any of these things.

Re: Deprecating Non-Secure HTTP

#186
post #149
post #128

Earlier quoted context omitted.

> The move to "deprecate" HTTP is an explicit attempt to manipulate the rest of the world into making SSL easier and more affordable. It is unfair to evaluate this proposal in isolation without considering the market upheaval that it is very much intended to trigger. I'd love to believe this but I've never once seen the https-only nazis bring up this issue on their own, or show any concern for the fact that it will l…

The move to deprecate HTTP is solely inspired by the need to authenticate online communication. It's necessary to protect speech on the web, because it makes it harder to tamper with the content in transit. Your ISP shouldn't be able to inject ads into a web page, a WiFi access point shouldn't be able to change every "do" to "do not", and a passive listener shouldn't be able to collect information about you for his o…

There's plenty of privacy and freedom on the internet... otherwise the internet would not have existed this long the way it has. More security is always better but let's please stop with hyperbole.

Re: Deprecating Non-Secure HTTP

#187
post #89

Earlier quoted context omitted.

I am long past confused and heading toward awed, at this point, that it's not a common-sense practice for every web developer to generate a personal self-signed root-CA cert, and install it on all of their machines. It's as basic as having an SSH or PGP key. Setting up a new box? Put your CA-cert in its trust roots. Then use your CA to generate a server cert for it; plop that in /etc/nginx and wherever else. Now it's…

> It's as basic as having an SSH or PGP key. And you're surprised that not every developer has done this? A minority of the developers I've ever worked with have ever done any of these things.

I'm really talking about the kind of developers that hang out here—people who regularly set up their own staging environments, use those "tunnel into my dev box" services, etc. Most of us here certainly know SSH, and probably have used GnuPG at least once. But it's still relatively unlikely, statistically, that you or I have ever touched the openssl(1) command.

Re: Deprecating Non-Secure HTTP

#189
I view this as an attempt by various power brokers to subvert the power of the World Wide Web by attacking it's decentralized nature. In the beginning (like now) it'll be relatively simple for everyone to get their hands on the SSL cert they need, but the risk is that in the future, after support for HTTP has been reduced it could become more difficult to acquire the certificates required to deliver the user experience that you wish to deliver (not just in terms of price, but in terms of censorship).

In addition to making the web more centralized, forcing everyone into HTTPS actually makes it much easier to effect broad scale traffic analysis. On top of that many info-sec experts suspect that the actual cipher in play here may eventually be proven to have significant weaknesses at some future date. AND HTTPS is more expensive to support in terms of bandwidth, CPU, and increased latency. It could result it more coal being burned each year to push all of those extra bytes around.

Re: Deprecating Non-Secure HTTP

#190

I view this as an attempt by various power brokers to subvert the power of the World Wide Web by attacking it's decentralized nature. In the beginning (like now) it'll be relatively simple for everyone to get their hands on the SSL cert they need, but the risk is that in the future, after support for HTTP has been reduced it could become more difficult to acquire the certificates required to deliver the user experien…

In such a scenario, wouldn't an alternative/forked browser emerge with support for an HTTP/anonymous web?

There is also censorship risk in named-data and content-centric networking, which offer multicast and caching benefits, but rely on uniquely identified content.

Post reply on HN