Live data from Hacker News

Deprecating Non-Secure HTTP

blog.mozilla.org

191–200 of 318 posts

Re: Deprecating Non-Secure HTTP

#191
post #182

Earlier quoted context omitted.

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…

Aren't name restriction extensions sorta adopted now?

Re: Deprecating Non-Secure HTTP

#192

Can someone explain why HTTPS is necessary for a webpage where I don't log in or submit any information? For example, take the xkcd homepage. Not only do I not log into it, there's nowhere I _could_ log in. The only input is a search box (which seems to be disabled at the moment anyway). Is it really a security risk if my communication with xkcd's servers is unencrypted? (Yes, xkcd has a store and a forum, and I unde…

> Can someone explain why HTTPS is necessary for a webpage where I don't log in or submit any information?

What about a site giving out health info? No login there, but could have consequences if tampered with. Or recipes (same as health info in some cases). Or news (could make investors jump).

Not that HTTPS fixes all of this, but there's no reason to think that a non-interactive or "static page can never benefit from security.

Re: Deprecating Non-Secure HTTP

#193
My question whenever this comes up is how will the web respond to the millions of caching devices out there that will now provide no bandwidth savings?

ISPs and companies all over the world cache static HTTP content (i.e. HTTP resources with proper caching headers). Doesn't endpoint-to-endpoint encryption basically kill that?

What I'd love is to have HTTPS for encrypted traffic, and signed HTTP for traffic that doesn't need encryption. So you would use the certificate to authenticate the payload, but a cache would still be able to deliver the content (because a replay would be valid).

Re: Deprecating Non-Secure HTTP

#194
post #99

Here's two relevant Bugzilla bugs: Self-signed certificates are treated as errors: https://bugzilla.mozilla.org/show_bug.cgi?id=431386 Switch generic icon to negative feedback for non-https sites: https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 Here's a proposed way of phasing this plan in over time: 1. Mid-2015: Start treating self signed certificates as unencrypted connections (i.e. stop showing a warning, but…

Users should still get a warning if they requested an HTTPS URL. If they requested HTTP and there was opportunistic encryption, fine. But under no circumstances should HTTPS URLs, which indicate secure intent, silently downgrade to insecure (self-signed or otherwise).

Re: Deprecating Non-Secure HTTP

#195
post #168

Earlier quoted context omitted.

Cloudflare's free plan has SSL now, which a 10 year could utilize. While that opens up a potential MITM attack, I don't believe it's worse than having no SSL at all (others argue it is, on the premise that it creates a false sense of security).

Amateur web development shouldn't depend on having an account with a 3rd party service which can arbitrarily decide whether or not to sign your cert.

Well you still depend on 3rd parties to register a domain. And one to provide a connection, if not a server.

Re: Deprecating Non-Secure HTTP

#196
post #182

Earlier quoted context omitted.

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…

Thank you. This makes sense.

Re: Deprecating Non-Secure HTTP

#197
post #24

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…

Why this project: https://letsencrypt.org/ is so important. From the site: Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. Arriving Mid-2015

It is waperware. Plus it requires you to run special software on your servers (not possible in a shared hosting environment).

Re: Deprecating Non-Secure HTTP

#198
Meanwhile, OpenBSD 5.7 came out today, with the following security fixes in LibreSSL (arguably the most secure SSL library so far):

"Multiple CVEs fixed including CVE-2014-3506, CVE-2014-3507, CVE-2014-3508, CVE-2014-3509, CVE-2014-3510, CVE-2014-3511, CVE-2014-3570, CVE-2014-3572, CVE-2014-8275, CVE-2015-0205 and CVE-2015-0206."

So if I were running a TLS-enabled site using LibreSSL from OpenBSD 5.6, I'd have been exposed to potentially 11+ CVEs. A little sooner with OpenSSL, and I would have been exposed to Heartbleed. And who knows how many CVEs will arise before 5.8 is released?

Why is it so impossible to write a secure TLS library? Why should I put my entire server at risk to appease the attempts of Mozilla and Google to prop up the CA business? Sorry, but I'll stick to parsing lines of text.

Let 'em remove HTTP completely. Hopefully after they break 90% of the web, we'll get some real user revolt, and some real competitors in the web browser space might emerge. Maybe from some people who actually listen to what their users are asking for.

I guess now we know what that "signed extensions only" change was for: what do you think they're going to do when someone submits a "Restore HTTP Functionality" add-on in the future?

Re: Deprecating Non-Secure HTTP

#199

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.

certainly there will always be alternative browsers, but since they would be used by a small minority the censors would effectively have the ability to determine which publishers are "cleared" to reach out to the most broad demographics. That alone would be enough if your censorship goal was to be able to sway public sentiment.

Re: Deprecating Non-Secure HTTP

#200

Earlier quoted context omitted.

You don't trust the EFF?

No, not in the slightest. The EFF is a non-profit organization that exists to lobby for policy change. No such organization is worthy of much in the way of trust -- especially for such a sensitive instrument.

To look at the history and charter of the EFF and say you don't trust them "in the slightest" is a bit ridiculous. It's hard to take that kind of remark seriously. Look at who's involved and what they've done, and dismiss that under the broad strokes of "no such organization is worthy of trust"? Nonsense.
Post reply on HN