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…
Deprecating Non-Secure HTTP
191–200 of 318 posts
Re: Deprecating Non-Secure HTTP
#192Can 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…
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
#193ISPs 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
#194Here'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…
Re: Deprecating Non-Secure HTTP
#195Earlier 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.
Re: Deprecating Non-Secure HTTP
#196Earlier 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…
Re: Deprecating Non-Secure HTTP
#197I 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
Re: Deprecating Non-Secure HTTP
#198"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
#199I 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.
Re: Deprecating Non-Secure HTTP
#200Earlier 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.