Slashdot Mirror
Firefox Users Reach HTTPS Encryption Milestone (techcrunch.com)
For the first time ever, secure HTTPS encryption was used for over half the pageloads served to Mozilla users, representing a big milestone for encryption. TechCrunch reports on the telemetry data tweeted by the Head of Let's Encrypt:
Mozilla, which is one of the organizations backing Let's Encrypt, was reporting that 40% of page views were encrypted as of December 2015. So it's an impressively speedy rise...
The Let's Encrypt initiative, which exited beta back in April, is doing some of that work by providing sites with free digital certificates to help accelerate the switch to HTTPS. According to [co-founder Josh] Aas, Let's Encrypt added more than a million new active certificates in the past week -- which is also a significant step up. In the initiative's first six months (when still in beta) it only issued around 1.7 million certificates in all.
The "50% HTTPS" figure is just a one-day snapshot, and it's from "only a subset of Firefox users who are running Mozilla's telemetry browser...not default switched on for most Firefox users (only for users of pre-release Firefox builds)." But the biggest caveat is it's only counting Firefox users, which in July represented just 7.7% of web surfers (according to Statista), behind both Chrome (49.5%) and Safari (13.68%) -- but also ahead of Internet Explorer (5.4%) and Opera (5.99%).
The Let's Encrypt initiative, which exited beta back in April, is doing some of that work by providing sites with free digital certificates to help accelerate the switch to HTTPS. According to [co-founder Josh] Aas, Let's Encrypt added more than a million new active certificates in the past week -- which is also a significant step up. In the initiative's first six months (when still in beta) it only issued around 1.7 million certificates in all.
The "50% HTTPS" figure is just a one-day snapshot, and it's from "only a subset of Firefox users who are running Mozilla's telemetry browser...not default switched on for most Firefox users (only for users of pre-release Firefox builds)." But the biggest caveat is it's only counting Firefox users, which in July represented just 7.7% of web surfers (according to Statista), behind both Chrome (49.5%) and Safari (13.68%) -- but also ahead of Internet Explorer (5.4%) and Opera (5.99%).
All three of them.
Not worth the paper they're printed on. It's just another form of tracking.
“He’s not deformed, he’s just drunk!”
Firefox should handle self signed certificates better. It treats them as dodgy, but they are not.
A certificate authority injected between you and a known server represents an unwanted man-in-the-middle.
I'll admit that the last time I dealt with this on FF, it was a few revisions ago. Self-signed certs are easy enough to add to the browser, any browser really. Will the average user know how to deal with this and take the appropriate steps? No.
Adding your own CA may take a little more work, but is what you need to do to avoid MITM attacks.
The cesspool just got a check and balance.
If they try to use HTTP, I 301 'em to HTTPS. And not just any HTTPS, but TLS 1.2. They can't squeak by with TLS 1.1 or 1.0, or any SSL version.
I'd be willing to bet that most security-conscious Firefox users turn off telemetry (as I did), which would skew the numbers. Chances are that they hit this milestone earlier than now.
"Can't you see that everyone is buying station wagons?"
Is FF phoning home wto mozilla with this statistic, and if so is there a setting we can turn off to stop it?
That's why let's encrypt is free.
Custom electronics and digital signage for your business: www.evcircuits.com
You mean like https://www.google.com?
Whose certificate is issued by " Google Internet Authority G2".
Self-signed is OK for them, but not for us. Get it?
Along with CPanel, I enabled HTTPS on my little website in seconds, it was truly painless. While my website stores nothing of significant value (Minecraft schematic files), it does have a login form and I sleep better knowing login credentials cannot be intercepted anymore.
It's only "free" if you don't value your time (the certs expire every few months), or if you don't need an EV cert, or if you don't need a wildcard cert. It's a fun toy for your blog that nobody reads, but that's about it.
And you should read the section about ocsp stapling.
It's only "free" if you don't value your time (the certs expire every few months), or if you don't need an EV cert, or if you don't need a wildcard cert.
Let's Encrypt intends that the installation and maintenance (e.g. renewal) is automated. A simple daily cronjob checks if any Let's Encrypt certs on that system are in need of renewal and, if so, handles the validation, issuance, and installation of those certs completely automatically. If anything, it dramatically *saves* admin time.
The vast majority of sites don't need EV or wildcard certs, so Let's Encrypt is perfect for them.
... Letsencrypt provided certificates that lasted longer than 90 days. Ridiculous. Make it one year at least. Please.
The process is intended to be automated, such as with a cronjob, and the short lifetime is intended to resolve issues relating to the general suckitude of revocation.
Which goes to show you how leaking of telemetry info is one of the biggest problems with certs.
How so?
So I have a server on my local network. To enable https, it needs a cert and you click through a form to create a Lets Encrypt cert. BUT if you do that, then you've injected an outside body in the verification!
What do you mean? If you mean the server validates its identity to the certificate authority, then yes, that's true. That's the point.
Each time it contacts that to check the cert, its informing the certificate company that you are accessing your own server on your own network
Let's Encrypt intends that the certificate issuance process is automated, such as with a cronjob. Thus, if you do things right, the server will periodically re-validate your site with Let's Encrypt and renew certificates automatically. This is intended.
If you mean that clients will query the CA's OCSP servers to verify the validity of the certificate, yes, this is true and a minor privacy concern. Fortunately, all modern browsers and servers support OCSP stapling. The server can, with a few lines (or enabling an option in Certbot, the major Let's Encrypt client), handle the OCSP checking itself and "staple" a signed OCSP response to the normal secure handshake. The stapled response is valid for a short period of time (a few days) and the server will query the OCSP servers periodically to get a fresh response. This way, clients don't reveal their browsing habits to the CA and the CA requires less resources for their OCSP servers. Win-win for all. If you haven't already, turn on OCSP stapling on your server.
Of course, if a server doesn't support OCSP stapling, browsers will fall back to querying the CA's OCSP responders.
Firefox should handle self signed certificates better. It treats them as dodgy, but they are not.
How would the browser know they're not dodgy? They are, by definition, self-issued. Anyone, including a bad guy, can make a self-signed certificate saying they're anyone else. There's no in-band way of authenticating a self-signed certificate.
Sure, one can manually elect to trust a self-signed certificate if one knows what one's doing, but the typical user is not knowledgeable enough to do that securely.
A certificate authority injected between you and a known server represents an unwanted man-in-the-middle.
The CA is not a "man in the middle", in that they're not involved in the secure handshake at all. They simply are a third party vouching for the validity of the information contained in the certificate: "We verified that the administrator of www.example.com controls that site and requested a certificate."
CAs undergo stringent vetting and auditing to ensure they follow specific policies before they're trusted by browsers, as well as annual audits thereafter. Is it perfect? No. Have CAs made errors, been compromised, or acted poorly? Yes, and in many cases those CAs received the "death penalty" of having their trust revoked by browsers. Still, it's the least-bad system available that scales for the internet. If you can think of something better, by all means, implement it.
This.
One of the arms of my business is web hosting (among web application development, and other online services). LetsEncrypt is fantastic. Automated SSL/TLS certificates makes life easier, and my small business clients really appreciate the free certificates. I really appreciate not having to deal with renewing them every year or two because its kind of a PITA.
For my own business sites I do use EV certs and its definitely a hassle to renew them.
The "50% HTTPS" figure is just a one-day snapshot, and it's from "only a subset of Firefox users who are running Mozilla's telemetry browser...not default switched on for most Firefox users (only for users of pre-release Firefox builds)." But the biggest caveat is it's only counting Firefox users, which in July represented just 7.7% of web surfers (according to Statista), behind both Chrome (49.5%) and Safari (13.68%) -- but also ahead of Internet Explorer (5.4%) and Opera (5.99%).
Translation: statistics are manipulated.
That's why I never believe any statistic, regardless of the source.
OCSP stapling means the server contacts the CA on the client's behalf and returns a cached OCSP response signed by the CA to the client. Thus the CA sees one OCSP request from the server per day as the server notices that the cached response is about to expire, as opposed to a request from each client. But in the case that Anonymous Coward #53085831 described, both the server and the client are on a LAN behind a NAT. When both the client and server have the same IPv4 address, stapling isn't quite as effective at hiding clients.
Then the problem becomes setting up the means through which the CA's root certificate is "pre-distributed over a secure sideband", such as a head of household wanting to make a private server available to visiting friends and family or a public library wanting to make a private server available to visiting patrons.
Self-signed is OK for [Google], but not for us. Get it?
Any company can join the major web browsers' root certificate programs so long as it can afford the cost of operating a CA and hiring a third-party auditor to verify that its issuance policy is being followed. Google is such a company.
Let's Encrypt is rate-limited in such a way that it's only "free" if you own a valid domain. Someone setting up a web server on a private network, such as inside a home, library, or museum, might not own a domain for that purpose.
Automated renewal is the intent. In practice, it took several months after Let's Encrypt entered public beta for some web hosting providers to let users even upload their own certificates without having to file a support ticket. (See, for example, a blog post from a month ago.) It got so bad that one passive-aggressive fellow wrote a tool to request a certificate from Let's Encrypt and automatically file a support ticket.
That's why LE is cheaper, you are forced to automate it causing you to spend way less time on certs. It's just part of setting up a web server and not all that complicated. Additionally both free and paid web panels now include (which you would be using if you don't know how to install a cert in less than 5m) a module that does it for you.
Custom electronics and digital signage for your business: www.evcircuits.com
It's still only informing them, that the certificate is still in use. And if its your lan and you're really want to avoid it, switch OCSP off in the browsers in your lan. You can do it there, not like an internet site, which cannot avoid the default config of its visitors.