More Than 50 Percent of All Pages In Chrome Are Loaded Over HTTPS Now (onthewire.io) 136
Reader Trailrunner7 writes: After years of encouraging site owners to transition to HTTPS by default, Google officials say that the effort has begun to pay off. The company's data now shows that more than half of all pages loaded by Chrome on desktop platforms are served over HTTPS. Google has been among the louder advocates for the increased use of encryption across the web in the last few years. The company has made significant changes to its own infrastructure, encrypting the links between its data center, and also has made HTTPS the default connection option on many of its main services, including Gmail and search. And Google also has been encouraging owners of sites of all shapes and sizes to move to secure connections to protect their users from eavesdropping and data theft. That effort has begun to bear fruit in a big way. New data released by Google shows that at the end of October, 68 percent of pages loaded by the Chrome browser on Chrome OS machines were over HTTPS. That's a significant increase in just the last 10 months. At the end of 2015, just 50 percent of pages loaded by Chrome on Chrome OS were HTTPS. The numbers for the other desktop operating systems are on the rise as well, with macOS at 60 percent, Linux at 54 percent, and Windows at 53 percent.
...and then blanked out by JavaScript (Score:4, Insightful)
loaded over...and then blanked out by JavaScript looking at Adblock's actions.
do they really think my next action would be to disable Adblock? Really? I just close the tab and move onto another page...
Re: (Score:2)
Note that adblock did not blank the content for me. Perhaps because I lock down java?
Needless bullshit (Score:4, Insightful)
Yes, HTTPS is fine for anything sensitive, but does my recipe site really need to provide HTTPS pages?
Seriously, there is no need for every site to output HTTPS pages. If you're really afraid that someone might eavesdrop and see you looking at Banana Bread recipes, you have bigger problems than an HTTPS connection can fix.
Re:Needless bullshit (Score:5, Insightful)
https also ensure the pages cannot be modified. if someone knows your recipe site, they trust you and its content.
if tomorrow they visit and it asks for a donation for example, they'll think its for you and donate. bad luck, it was the attacker.
basically, there is more than confidentiality issues ("they can see your data"). there's also integrity issues ("they can change the data displayed")
besides - there's plenty of ways this can go wrong for confidentiality as well. there are billions of websites. some start as a recipe site, and end up asking login, processing password, etc. some not. people make mistakes along the way. its much safer and easier to basically require https across the board - specially that its pretty much free to do so now.
Re: (Score:2)
Re: (Score:1)
Sad news for you, if an attacker can penetrate and change my banana bread website, it doesn't matter whether it what running https or http. you'll get their donation request and links via https with my trusty certificate.
Or are you imagining hijacking and rerouting traffic? most https sites don't use HSTS so can still do that.
Re: (Score:2)
and block port 443
This will be noticed when the user tries to visit a couple sites that do use HSTS, such as Google, Facebook, Twitter, or anything else in the preload list.
Re: (Score:2)
99.9999999999999999999999999999999999999999% of "rewriting" attacks happen on the webserver itself -- i.e. hacks that insert crap into your swiss cheese wordpress blog. The remaining rounding error are the result of local malware on the web browsing PC -- i.e. the browser inserted that crap. I have yet to even hear of a nefarious operation inserting crap into live traffic. (yes, there have been ISPs with aggressive proxies that can (and did) insert/modify content. If you cannot trust your ISP, you have othe
Re: (Score:2)
yes, there have been ISPs with aggressive proxies that can (and did) insert/modify content. If you cannot trust your ISP, you have other problems that SSL won't always fix.
Unfortunately, most of us are not in a position to move our families within the service area of a trustworthy ISP, if there even is a trustworthy ISP in our home country or any other country to which we hold an entry visa.
Re: (Score:3)
Last year [arstechnica.com], Github was hit by a DDoS caused by attack code injected into plain-text http:// traffic by someone in China.
Let's assume for a moment that the attack on Github consisted of altering the contents of a single 50 byte packet. If that 50 byte packet corresponds to 0.0000000000000000000000000000000000000001% of rewritten traffic, then the remaining 99.9999999999999999999999999999999999999999% would correspond to 10^19 yottabytes of traffic.
Bearing in mind that total global internet traffic is barely e
Re: (Score:1)
The JavaScript was silently injected into the traffic of sites that use an analytics service that China-based search engine Baidu makes available so website operators can track visitor statistics.
It was just yet another "bad ad" hitting people. They didn't man-in-the-middle anyone's traffic to slip their code in. They didn't hack into thousands of websites to slip in their code. The ad network operators already used decided to push out malware instead of, or in addition to, a normal ad. This ALREADY happens all the damn time, except this time it was the ad network itself doing it and not one of their crafty customers.
Someone rewriting traffic in transit is exceptionally rare. Because it's really har
Re: (Score:2)
Read the rest of the post. Strong evidence that the JS was being injected by a middle hop, notably one inside the network of the ISP responsible for China's great firewall.
That they targeted an ad network doesn't mean it was yet another bad ad, it just means that the ad network was a good target because of the way it was included on many other sites.
Re: (Score:2)
more like google wants to be the only advertiser to you and not say your ISP or wireless carrier knowing which ads to push to your phone
it's always about the $$$$$$$$$$$$$$$$$$$$$ and not some bullshit about making the world a better place
Re: (Score:2)
EFF HTTPS Everywhere
https://www.eff.org/https-ever... [eff.org]
Absolutely is a need (Score:1)
Re: (Score:1)
actually, 95% of https sites don't use HSTS with their HTTPS so they can still put chinese lead red paint in the recipe.
Re: (Score:1)
does my recipe site really need to provide HTTPS pages?
your choice of recipes will reveal if you have a health problem such as diabetes or food allergies
you have bigger problems than an HTTPS connection can fix.
Your inability to deal with more than one problem is YOUR problem
Re: (Score:2)
I guess that depends on how much plausible deniability is built into a particular site's hostname. If you're on diabetesrecipes.info, for example, then your ISP can already see diabetesrecipes.info in cleartext in the Server Name Indication field of the TLS handshake. If the client doesn't send this field, the HTTPS server where diabetesrecipes.info is hosted won't know which certificate to send out of the hundreds of sites on the same IP address.
Re:Needless bullshit (Score:5, Informative)
Yes, HTTPS is fine for anything sensitive, but does my recipe site really need to provide HTTPS pages?
That depends, is every user's browser perfectly secure? (Hint: the answer is no)
HTTPS provides three guarantees that HTTP does not.
1. Secrecy. This is the one that you focused on; keeping the contents of the traffic between your recipe server and its clients secure against eavesdroppers. You're probably right that it doesn't matter.
2. Authentication. HTTPS verifies to the client that it is talking to the server it thinks it is, rather than some other, possibly malicious, server.
3. Integrity. HTTPS that the contents of the traffic between your reciper server and its clients is secure against modification.
Both 2 and 3 are important individually, and together they provide an assurance that your clients are getting your content and nothing else. Not only does this mean the recipes won't be modified, but it means the recipe documents cannot be modified so they exploit browser vulnerabilities to hijack the user's browser, or possibly the user's entire computer.
Of course, this still leaves open the possibility that your recipe server is malicious, either because you are or because someone else has taken control of it. Those possibilities are addressed by Safe Browsing infrastructure that attempts to identify and warn users away from malicious sites. But that only works if the browser actually knows what site it's talking to, so HTTPS is an essential enabling technology for Safe Browsing.
Re: (Score:1)
Actually, [i]EVERYTHING[/i] is pinned on #2. Unfortunately, the chain of trust for SSL certificates has been proven, over and over again, to be weak enough a toddler could toss a matchbox truck through it. The instant you get a browser to accept your certificate, the house of cards blows away.
The simple truth is very little of the internet actually needs to be "protected" by SSL. Very few web sites are interesting ("valuable") enough to be worth the effort to divert or otherwise intercept their traffic. All
Re: (Score:1)
Actually all non-ssl websites are very interesting to me, or more specifically to my special wifi access points that use squid to inject ads into everyone's web traffic who uses it.
I make quite a bit of money off these things, but the whole scheme depends on websites not using ssl to work.
Now sure, every so often some of those injected flash ads have malware in them, but that's the ad it's not my fault. I mean it's not like I can use quality ad delivery networks here, they actively stop this kind of thing,
Re: (Score:1)
For those playing along at home, this falls into the bucket of "I CANNOT TRUST MY ISP".
Re:Needless bullshit (Score:4, Insightful)
If a small amount of global web traffic is encrypted then the encrypted traffic will stand out and bring scrutiny.
If everything is encrypted, no matter how mundane, then genuinely sensitive traffic becomes less conspicuous.
Re: (Score:3)
Re: (Score:2)
All of the responses to the OP miss his point. Not every website needs to pay the cost of encryption for no real reason. Yes it is a trivial cost on your recipe site, but not so much when you have a thousand hits a minute.
That's a good point.
There's also the expense and upkeep of maintaining current certificates. I have 100+ sites currently, which means I could be renewing a cert every few days or have to do 100 of them all at once every year. Yes, there are some free certificate services out there, but for some sites it just doesn't seem worth it.
Finally, with the many, many certificate exploits that have occurred, adding HTTPS doesn't really mean you're secure....it just means that the browser thinks everything is secure.
Re: (Score:2)
If you have hundred domains, you should look at using either a hosting service or a content delivery network. Thanks to Let's Encrypt, almost all of the big players allow you to turn on HTTPS support with a single check box. You do that once and you're all set.
As a nice she effect, your site will get much faster, as it can now use HTTP/2, which has huge performance improvements.
And Google's index will rank you higher.
Also, future browser versions won't show warning messages when they access your site (that
Re: (Score:2)
Finally, you get to use new HTML5 features. A lot of the newer features are only available to encrypted sites
Say I want to run a web server on a private network, such as a home NAS, and allow HTML5 playback of videos stored on this NAS. But there has been talk of restricting the Fullscreen API to secure contexts because of the potential for phishing [feross.org]. So how would I go about encrypting a server that doesn't have its own domain name, especially if I want visitors to my home to be able to see the videos in the full screen but not a scary self-signed certificate warning?
Re: (Score:2)
You'll need to own at least one domain name (e.g. "example.com"). But it is OK if your internal service is hosted on a sub domain (e.g. "videos.example.com"). So you only need to pay for a single domain name.
The internal host name does not need to be accessible from the internet, just from your LAN. But you need to be able to control DNS for your entire domain. You can then use DNS validation to prove to Let's Encrypt that you control all of "example.com", and they'll issue you a certificate for "videos.exa
Let cron do the donkey work (Score:2)
There's also the expense and upkeep of maintaining current certificates. I have 100+ sites
Then set up Certbot or another ACME client to renew certificates for 100+ of these sites, and put it on a cron job.
Re:Needless bullshit (Score:4, Informative)
Some ISPs and access points have been doing realtime traffic modification and inserting ads into websites. Since it's well known that some ads are malicious, then yes, it's very much beneficial for a recipe site run on SSL, because it makes it impossible to hijack the trusted and harmless site for nefarious purposes, such as serving you some kind of trojan via an ad.
Re: (Score:2)
Some ISPs and access points have been doing realtime traffic modification and inserting ads into websites. Since it's well known that some ads are malicious, then yes, it's very much beneficial for a recipe site run on SSL, because it makes it impossible to hijack the trusted and harmless site for nefarious purposes, such as serving you some kind of trojan via an ad.
I'll agree that this is one scenario where SSL would help.
Re: (Score:1)
Yes, HTTPS is fine for anything sensitive, but does my recipe site really need to provide HTTPS pages?
Seriously, there is no need for every site to output HTTPS pages. If you're really afraid that someone might eavesdrop and see you looking at Banana Bread recipes, you have bigger problems than an HTTPS connection can fix.
No, I'm afraid about visiting a site and having code injected into the bit stream:
* http://www.pcworld.com/article/2062400/british-spies-reportedly-spoofed-linkedin-slashdot-to-target-network-engineers.html
Or your ISP as well:
* https://www.reddit.com/r/canada/comments/2nv1un/rogers_still_using_content_injection_after_7/
* http://www.infoworld.com/article/2925839/net-neutrality/code-injection-new-low-isps.html
HTTPS Everywhere prevents "tapping glass" and forces the intel folks to hopefully actually focus on i
Re: (Score:1)
My small (but still monopoly) ISP loves to inject content in.
Constant bandwidth warnings? Check
Terms of Service changes? Check
(My favorite) Upgrade to a new modem now with this offer! Check
I cringe every time I see one of their banners, because I know how dangerous of an avenue this is, and the potential for how bad it can get.
But like most other people in America, I don't have a choice to use another provider if I want equivalent service. And the service isn't even good.
Re: (Score:2)
From Google's economic point of view, yes it should all be encrypted. Why, you are wandering, why is it so important from Google's economic point of view, because they want to sell you privacy, they do not want Government's and ISPs to access that data for free, not when Google wants to sell it. Whilst definately a good idea in principle make no mistake there is greed and evil behind it. No free targeted marketing data for you, unless you pay, everything encrypted all of the time except for Google skulking
Re: (Score:2)
If HTTPS becomes the default, then what becomes the default way to obtain a certificate for a web server on a private LAN?
Re: (Score:2)
With Let's Encrypt, it is pretty easy to automate all of the necessary steps. When they launched about a year ago, there were a couple of device manufacturers that wanted to know how to integrate Let's Encrypt into their wireless access points.
Each owner of an access point would automatically be assigned a (sub)domain administered by the device manufacturer. I haven't seen any devices for sale that do this yet, but as SSL becomes more prevalent I'd expect routers to create hostnames such as windos123.wifi56
Let's Encrypt definitely helped... (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Just use the Let's Encrypt client in manual mode (letsencrypt-auto certonly --manual) then install the generated certificates the "old" way.
While my OS has the lets encrypt client available, I've got one service I run on it that doesn't have any predefined rules for generation and auto-renewal. Manual mode works great for this, its just a little annoying to use.
Re: (Score:2)
There are several other clients apart from CertBot. Take a look. They are all linked from the letsencrypt.org website. You might find something that is a better fit for you.
I think, there are a couple of ACME clients that also act as HTTPS reverse proxies. That could be a really easy option to solve your problem
Re: (Score:2)
The easiest way to switch a legacy service to HTTPS is to install an NGINX reverse proxy in front of it.
As for the certificate, get a free certificate from Let's Encrypt. There are are plenty of options to automate and integrate Let's Encrypt with existing services (e.g. the aforementioned NGINX).
And yes, Let's Encrypt has probably done more for the universal adoption of HTTPS than any other effort -- including everything that Google has done.
If you like Let's Encrypt, please consider donating. They are cur
Legacy service on a private LAN (Score:2)
The easiest way to switch a legacy service to HTTPS is to install an NGINX reverse proxy in front of it.
Provided it has its own fully-qualified domain name.
If a service accessible over a LAN is normally accessed with a private IP address (such as one in 192.168/16), or with a hostname under a phony TLD (such as .local), the CAs won't issue a certificate. This is true, for example, of the HTTP server for administering a router, printer, or NAS. Mozilla's FAQ about deprecation of cleartext HTTP [mozilla.org] acknowledges this problem but offers no fix yet:
Re: (Score:2)
You don't need a separate domain for internal services. Use your external domain and create sub domains. All your internal machines could be on dhcp.public.com and all your containers on vm.public.com. Neither one needs to use publicly routable IP addresses, and in fact you can continue using dnsmasq (or an exquisitely DHCP server) to manage this part of your internal network.
You then operate the Let's Encrypt ACME client in DNS mode to get globally trusted SSL certificates. But nobody other than your inter
Re: (Score:2)
Use your external domain and create sub domains.
Home users who bought a printer or NAS appliance tend not to already own a domain. Should buying a domain be considered part of the total cost of ownership of home networking?
Re: (Score:2)
but CentOS 5 is not supported and I have no plan to reinstall the entire server
Sorry but you'll need to do that very soon as CentOS 5 is supported only until March 2017, and in releases that ancient they didn't provide a reasonable way of upgrades. And if you accrued that much technical debt, it might be faster to just nuke and reinstall anyway.
Re: (Score:1)
Right. Because a FREE, NON-VALIDATED certificate is 100% trustworthy. They are on par with a self-signed certificate. Only worse, because they won't trigger a warning from your browser. People who actually care about security do not trust their certificates.
In fact, any "domain validated" certificate should, as Clarkson would say, make some poo come out. If I have control of your DNS, then I can easily man-in-the-middle your site; SSL doesn't prevent anything here. Thanks to Let's Encrypt, I can now get a c
Re: (Score:2)
Right. Because a FREE, NON-VALIDATED certificate is 100% trustworthy. They are on par with a self-signed certificate.
The validation is essentially the same as budget CAs. The difference is LetsEncrypt convinced the major browsers to trust them even though they're a non-profit, automated service.
Re: (Score:1)
Actually, they're WORSE. One script and you're set; run it from cron and your cert is always up-to-date.
And no, they didn't get any browser to accept them. They got some other idiot CA to sign their intermedia CA, and *poof* browsers accept them now.
Re: (Score:2)
If your primary challenge is to train users to differentiate between Extended Validation and Doma
Re: (Score:1)
With a self-signed certificate, the browser emits a warning alerting the user to question what they're doing. You will get that warning each time unless you install it in your personal certificate store. If the cert is later changed, it will differ from the one stored and you'll start getting warnings again. The certificate has no trust until you say so.
With LetsEncrypt, the certificates are just as untrustworthy. The problem is, you don't know they're the idiots behind that lock. They're handed out like pe
Protect users from eavesdropping? (Score:1)
How do they know what websites I visit and what percentage of them are using HTTPS?
Sounds like I don't have the privacy they are trying to protect
Re: (Score:2)
Google? Privacy for the product(s)? You must be joking.
Re: (Score:2)
How do they know what websites I visit and what percentage of them are using HTTPS?
Unless you opted in to allowing Chrome to send usage statistics, they don't.
Re: (Score:2)
The hostname isn't encrypted, when issuing HTTP over SSL. So any network between you and the internet (I.e. your ISP) has this information.
I think HTTP/2 is a little better in this regard, but it is not yet very widely deployed.
My personal web site does not support HTTPS (Score:1)
I run Apache and I even compiled in HTTPS support, but here's the thing; I need a valid certificate which costs real money.
Is there an anonymous way to run an HTTPS server?
Something that doesn't guarantee the identity of the website, but still allows the traffic to be encrypted?
Re:My personal web site does not support HTTPS (Score:5, Informative)
Re: (Score:2)
Ya, and any webhost running cPanel can do it through Comodo (or letsencrypt with a plugin):
https://blog.cpanel.com/autoss... [cpanel.com]
Re: (Score:3)
lets encrypt will issue certificates, without even so much as a registered account.
Re: (Score:1)
Yup, and any host running cPanel will do it through Comodo (or letsencrypt with a plugin):
https://blog.cpanel.com/autoss... [cpanel.com]
Re: (Score:2)
Re: (Score:2)
You can create a self-signed certificate. The user's browser will warn the hell out of them, but it will be encrypted.
Re: (Score:2)
... The user's browser will warn the hell out of them ...
Exactly. Which is why I find that unacceptable.
The problem lies not with the ability to turn on encryption - that's relatively easy.
It's the browser acting as if a self signed certificate is less secure than no certificate.
Let's encrypt may be better, but it depends on how browsers decide to treat domain-validated certificates.
Truth of sense of security (Score:2)
It's the browser acting as if a self signed certificate is less secure than no certificate.
Browser makers find it important to accurately report the truth of the sense of security. A self-signed certificate used with the https: scheme gives a false sense of security, whereas the http: scheme gives a true sense of insecurity.
Let's encrypt may be better, but it depends on how browsers decide to treat domain-validated certificates.
The only browser I've ever seen that warns for valid domain-validated certificates is Comodo Dragon. Any certificate that isn't at least organization-validated causes Dragon to show the "mixed passive content" icon in the location bar and an amber interstitial [netcraft.com], which resembles
Re: (Score:1)
Create your own self-signed certificate. If your users want SSL, they can accept that certificate. Most browsers make it fairly easy to install an otherwise unknown/untrusted certificate.
Scared (Score:2)
And the fact that them being able to get this information doesn't scare and infuriate people? Even if the metric is anonymized, why the fuck do people accept software that spies on you? Yes I'm aware that majority of software does.. but why the hell do we accept it?
spyware (Score:2, Informative)
Not only does most stuff not need to be HTTPS, it often destroys caching, lowers battery life, and hurts performance.... but also.... how does Google know these statistics unless they are freely admitting that they have major spyware in their non-open, binary-only Chrome browser? So this whole https on non-important pages is theoretically so much better for privacy and security, except that Google gets to know everywhere you go?
There are many reasons I don't use Chrome....
Re: (Score:2)
Not only does most stuff not need to be HTTPS, it often destroys caching
Your browser can cache resources delivered through HTTPS as easily as through cleartext HTTP.
lowers battery life, and hurts performance
This was true until most battery-powered laptops, tablets, and smartphones started shipping with support inside the CPU for commonly used ciphers.
but also.... how does Google know these statistics unless they are freely admitting that they have major spyware in their non-open, binary-only Chrome browser?
In both Google Chrome and its free subset Chromium, users can opt in or out of synchronizing bookmarks and history across all devices on the same Google account.
Re: (Score:2)
>"Your browser can cache resources delivered through HTTPS as easily as through cleartext HTTP."
Which does absolutely nothing for centralized caching like Squid.
Re: (Score:2)
Then have your office's Squid proxy act as a man in the middle for HTTPS, and install its root certificate on all devices authorized to connect to the network.
Re: (Score:2)
While that is an option, as you probably know, it has disadvantages:
1) Can be difficult
2) Time consuming
3) Erodes all security
4) Introduces more things to break & support
5) Puts a lot more load on the server (which in same cases is old and can't handle it well)
6) Won't work for clients you don't control (think public and guest access)
I still don't believe it makes sense to force the majority of web browsing to be https.
Re: (Score:2)
In the cleartext HTTP case, there was no security to erode anyway. And clients you don't control would connect to a separate subnet not behind the caching proxy.
1, 2, 4, and 5 will probably end up solved by some information security appliance manufacturer.
Re: (Score:3)
HTTP/2 requires encryption and gives much better performance than plain old HTTP.
If you want a fast and efficient site, there is no way around getting a valid certificate.
The same is true if you want to use any of the more modern HTML5 features. They're disabled for legacy sites
Re: (Score:2)
how does Google know these statistics
Part of it is that by default Chrome will report your browsing habits, partly because Google's OS might (just guessing on this), and partly because Google search returns links to Google which then redirect to the target website.
Re: (Score:2)
Re:And with StartCom dead... (Score:4, Informative)
Re: (Score:2)
so what's the alternative now to get a free SSL certificate valid in browsers?
Re: (Score:2)
Re: (Score:2)
Thanks, went with Let's encrypt. Turns out it's even better as the certificate auto-renew. So even if the duration is only 90 days (1 year with Startcom) it doesn't matter.
Re: (Score:2)
Even most paid certs are only verified with a file on the webserver or an email sent to the domain.
EV certs are the exception (and in that case the CA does, or at least is supposed to, provide an actual useful identity verification service), but for normal certs you can easily automate the check in exactly the way LE does.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
... it's a racket for SSL authorities who charge for their certs. Unless you want to install onerous ACME software on your server. Suckage.
https://letsencrypt.org/ [letsencrypt.org]
Re: (Score:2)
Then use an ACME client that doesn't require administrator privilege, in particular one that uses the DNS challenge instead of the HTTP challenge.
Re: (Score:2)
DNS validation is awesome. I have a couple of embedded devices (e.g. a remote KVM switch) that have minimal support for SSL certificates. I was never able to figure out how to use them with traditional CAs. But ACME over DNS was super easy to set up for these devices
Re: (Score:2)
Anyone else trying that will first need to buy a domain with which to do ACME over DNS, correct?
Re: (Score:2)
Yes, you need to own at least one domain. But you can then use sub domains for everything else. Any cheap domain will do. But yes, it'll cost you on the order of $10/year for all your computation needs
Handout to registrars (Score:2)
Thus the inclusion of WebRTC and Fullscreen in the Secure Contexts proposal [w3.org], currently a W3C Candidate Recommendation, is one big handout to domain registrars. Ten million homes with NAS devices means 10 million domains that need to be registered and renewed annually, to the tune of $100 million a year for registrars. At least it's not quite as bad as it'd be without Let's Encrypt, in which it would have been a handout to both the registrar racket and the CA racket.
Re: (Score:2)
My webhost offers FREE SSL certificates through Let's Encrypt or you can roll your own. There's also a paid SSL certificate option.
https://letsencrypt.org/ [letsencrypt.org]
Re: (Score:2)
If anything, ACME is a vast improvement over what we had before.
You might not mind 1) obtaining a new client certificate, 2) installing it in the browser, 3) generating and uploading a CSR, 4) proving that you have control over the domain, 5) downloading the new certificate, 6) installing it the server, 7) restarting the server with minimal downtime.
It used to take about 30min of work once a year for each of my domains. It also was a little tedious to schedule, as StartCom only gave a relatively small time
Re: (Score:2)
Isn't it a bit stupid to support HTTP for domain validation? The whole point of HTTPS is that you can't trust the identity of HTTP as it's vulnerable to a MITM attack yet it's just fine for getting an automated cert.
Re: (Score:2)
You can trust HTTP as much as you can trust DNS. That's why automated CAs hit a site from several different paths through the Internet. The only practical way the MITM can compromise the validation is by being on the server's only uplink.
And don't bring up DNSSEC until the root is signed with a key longer than 1024 bits.
Re: (Score:2)
That's what "certificate transparency" is for. And it's quickly becoming a mandatory feature.
Also, "certificate pinning" can help. But there are pros and cons to it. It's not appropriate for every site.
Re: (Score:2)
Re: (Score:2)
If you run chrome from that fresh linux install, they'll get exactly the same stats from you.
Re: (Score:2)
And then the firmware will beg you to wipe the machine right back to "OS verification" (that is, the factory image) every single time you turn it on. If you've installed a "regular" GNU/Linux distro on your Chromebook, you have to make sure nobody else has physical access to it even for a moment, or they'll end up tempted to inadvertently wipe it.
Re: (Score:2)
I am not going to pay for a fucking SSL cert
Neither am I. If a site is public, you can obtain certificates without charge from Let's Encrypt.
adding that heavy overhead to read only sites
Most of the overhead in TLS is in the setup and teardown of connections. And even that is mostly mitigated by keep-alive, HTTP/2, or large files. Podcasts are large files.