HTTPS everywhere is huge waste of energy. Lets encrypt ==> lets transform energy to heat.
Deprecating Non-Secure HTTP
311–318 of 318 posts
Re: Deprecating Non-Secure HTTP
#312Earlier quoted context omitted.
> it requires you to run special software on your servers It doesn't, they ship a tool only for convenience. An open source tool running on your machine would be reverse-engineerable anyway. Plus, it is expected that shared hosting providers will run the tool for you.
Any citation for this claim: "it is expected that shared hosting providers will run the tool for you"? Currently SSL is a revenue stream for many shared hosting providers. Are there are on-record comments from major providers who are planning on supporting Let's Encrypt?
That's not a claim, it's speculation. Since there is not marginal cost, it's going to happen eventually. You only need one provider to do it and some customers to request it for the others to follow. Many shared hosting providers already have removed traffic limits despite the additional revenue it used to bring. They can upsell customers with extended validation anyway.
The only problem is lack of browser support for server name indication so one IP can be shared by many customers, but it's getting less of an issue by end-users renewing their hardware or updating their browser.
Re: Deprecating Non-Secure HTTP
#313Earlier quoted context omitted.
So you handle deployment of apps inside a corporate network, and have no idea on how to manage you own CA? How does you corporation handle actually important corporate sites that nobody must access? It sound to my like your corp has some issues on this side.
...Why would a company need to run their own CA to do this?
How would you otherwise handle this? The only alternative I can think of: a split-horizon DNS sounds even more complex that having your own CA.
Re: Deprecating Non-Secure HTTP
#314Earlier quoted context omitted.
Well, if cost is your main priority, then startssl.com is the obvious way to go, since it provides free certificates. This "certificates are expensive" argument was only valid a decade ago, we have free certs now.
Free as long as you never have to revoke them. Which means people primarily looking at costs are actually incentived to not revoke compromised certs.
Revoking has an actual cost itself for them too (and for all client, in the end) due to the revocation list growing.
Revocation isn't part of the normal lifecyle of TLS certificates either: you'll only need this once you've had a security breach.
Re: Deprecating Non-Secure HTTP
#315Meanwhile, 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 e…
Well, frequently the vulnerability of those CVEs is breaking or downgrading the crypto... or in other words: if exploited, the connection could become as insecure as HTTP.
So your argument is that since locks can occasionally be picked, doors shouldn't have locks? What exactly is the massive burden with HTTPS? The computational cost is tiny and will continue to become tinier, there are free cert providers like StartSSL and more coming soon, and the implementation is simple enough that anyone managing a server should be able to handle it easily.
The number of websites where I wouldn't prefer encryption and identity authentication is around zero, and the number of websites where I'm okay with someone injecting arbitrary JavaScript is exactly zero. The time people spend making flawed "if you have nothing to hide, you have nothing to fear" or "crypto libraries/CAs are bad, scary, and hard to use" arguments would be much better spent actually trying to improve those circumstances for the inevitable and necessary shift to HTTPS everywhere.
Re: Deprecating Non-Secure HTTP
#316Meanwhile, 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 e…
Well, frequently the vulnerability of those CVEs is breaking or downgrading the crypto... or in other words: if exploited, the connection could become as insecure as HTTP. So your argument is that since locks can occasionally be picked, doors shouldn't have locks? What exactly is the massive burden with HTTPS? The computational cost is tiny and will continue to become tinier, there are free cert providers like StartS…
> So your argument is that since locks can occasionally be picked, doors shouldn't have locks?
A faulty lock on my house doesn't turn into Heartbleed.
The thing is, I don't need a lock on my server that serves up static, legal content. You might think it's a problem, that the NSA is going to spy on you, or China is going to inject attacks into your requests to my server, but that's your problem.
I'm not going to run a massively buggy TLS library with an API guide that would take a whole team of engineers weeks to decipher, just because you're intensely paranoid about accessing game-related data over HTTP.
Seriously, look at the GnuTLS documentation sometime. It's psychotic. As is MatrixSSL, PolarSSL, OpenSSL, and NSS. The closest to sanity I've ever seen was libtls, which is only on OpenBSD, still has lots of CVEs popping up, and can't do non-blocking mode.
> What exactly is the massive burden with HTTPS?
1. write your own HTTPS server. I'll wait a few months, or
2. find a library that's easy to use and won't expose my server to Heartbleed-like attacks, and
3. pay me $70/yr for the wildcard cert I would need.
I'll cover the extra CPU costs, since you say they're so small. (even though when people say "small", they're counting overhead as a percentage against a site running a bloated beast like Wordpress in PHP + MySQL.)
> there are free cert providers like StartSSL and more coming soon
That don't provide wildcart certs (and I have a wildcard CNAME entry; and I make use of that.)
> The number of websites where I wouldn't prefer encryption and identity authentication is around zero
And you're free to not visit my site, just like I wouldn't ever patronize a webstore that wasn't HTTPS. That's how markets are supposed to work. I don't see why your browser has to make the decision for the both of us.
> and the number of websites where I'm okay with someone injecting arbitrary JavaScript is exactly zero
Honestly ... I would be okay with blocking Javascript over HTTP. But I think that's more because I just hate Javascript :P
> would be much better spent actually trying to improve those circumstances
You seriously want me to write a TLS library?
My dream goal would actually be to have it built-into the sockets layer. If it could be enabled as easily as a setsockopt(SO_TLS_CERTIFICATE, (void*)certificatedata, ...); and OS updates could fix the security, I'd be a lot more inclined to get on board with the programming side.
I don't have a solution to the wildcard cert issue. I can't well start up my own CA to give them out for free. I guess it would at least be nice to see if they ever tone down self-signed certs from "WORSE THAN HITLER" to "at least equal to HTTP" in terms of warning messages. People keep talking about it, but it's been what? Over a decade now? I'll believe it when I see it.
Re: Deprecating Non-Secure HTTP
#317Earlier quoted context omitted.
Last time I tried, their site had JavaScript bugs and their email validation procedure didn't pass greylisting. I didn't want to place my web server security in the hands of a company with such low quality standards.
i had that problem when i used to run my own mail server (3 years ago). When did you last try?
It was less than a year ago, also running our own mail server.
Re: Deprecating Non-Secure HTTP
#318Earlier quoted context omitted.
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?
and how is HTTPS protecting us against that? if you took over that IP address you can initiate a valid HTTPS session using the compromised server's identity and communicate with the monitoring service happily reporting fake data over HTTPS. I don't see your point. The question here is btw. is it worth X amount of dollar to protect this service with a secure channel? Sometimes the answer is yes, sometimes it is no.
the internal server is always made of servers and clients just like the external one.
if you compromise one server you have access to the data transiting there, but not the others
if you compromise one client you have access to the data this client sends only
in particular, very few internal networks enforce L2 security (ie its possible to sniff all data on the same VLAN as you are).