That's simply not true. 99% of the time I could care less if a middle man sniffs my traffic. HTTPS is for that other 1% of the time.
The hypocrisy here is amazing, too, because while pushing HTTPS, Google itself is actively following everybody around, tracking everything they do online.
The obvious one is that it makes your traffic hard or impossible to sniff.
What's often overlooked is that it also makes your session highly resistant to tampering by 3rd parties. These parties include:
1. Anybody who might have access to your home WIFI network.
2. Your Internet Service Provider. There's been plenty of documented cases where ISPs have injected 'harmless' HTML.
3. Any number of bad actors if you're using any kind of public WIFI.
4. National actors. That's the NSA in the United States, where we have clear evidence that they have been capable of intercepting unsecured connections and injecting unreleased attacks into targeted computers.
This is not tinfoil hat stuff.
The benefit of https is undeniably greater than the cost.
I'm not crazy about how Google throws their weight around in a lot of cases either. But in this case, I think they're doing the right thing.
1 and 3 are due to poor end user security and won't be solved by HTTPS, and 2 and 4 are lost causes and also not solved by HTTPS.
An ISP is by definition a man in the middle, and unless the user checks certificates for every page and resource they fetch then the ISP can inject their own certs and monitor traffic if they really want to.
And most of the time national actors like the NSA will have better ways of getting the information if they need it
An ISP could inject their own certs very easily. Send an email to customers -- here run our "tune up" app to speed up your computer. A huge portion of customers would probably do it. Bingo, new CA roots installed.
In that case the ISP would be inducing the user to install malware. If the ISP is willing to do that, then you should probably view them as malevolent adversaries in your security model. I don't really think that an OS can protect against this in any reasonable way if that OS allows users to update certificate stores themselves. I don't really view this as a problem with the certificate model as opposed to plain old social engineering.
In any case, I don't think "an ISP could inject their own certs very easily" is a fair characterization unless you put it on the same footing as "anyone with your email can get people to install malware easily".
I'd like to see something comparing the number of people blackmailed or exploited by sniffed HTTP traffic versus the number of people affected by back end exploits or social engineering. Everybody screams about HTTPS because it's easy to do, but it's a tiny problem in the grand scheme of things, and it gives people a misplaced sense of security.
To be fair, there's not much that browser makers can do about back end exploits and social engineering. Google aren't in the business of writing back ends for third parties, and it's difficult to know if a website's back end is insecure, so I don't know who you expect to hear "scream", or who they would scream about.
The article is about one practical measure that a browser maker has taken to improve the piece of user-facing software that they are responsible for, and some users of that software are applauding this improvement.
Having said that, I do accept your over all point that there is a lot of other work that still needs to be done in securing the web. As you suggest, that's not going to be easy, but let's not fail to fix the things that we can fix already.
It's not a big problem if the traffic is inconsequential.
If I'm passively browsing I don't really care too much. If I'm submitting forms, or working in a authenticated session, that's a different matter of course.
And as easy as it is to get a certificate these days, what does it really prove? It stops 3rd party snooping, but then again so does a self-signed certificate.
I think you're confusing authentication vs encryption. If you were MITMing someone and using a self signed cert for example.com that connection can be encrypted (if the user clicks through the warnings) but says nothing about your trust for the site.
Let's Encrypt, or any other low-cost SSL certificate, says very little about my trust for the site either. It's just too easy to get them to think they really mean anything.
All new certificates for DNS names in the Web PKI today (and for some time now) must result from the CA having used one of the Ten Blessed Methods to validate the Applicants control over the name, regardless of who paid how much.
Let's Encrypt offered three of the Ten, but one was discovered to be flawed due to the way some major bulk hosting services are configured, so that leaves two (of Nine, since in practice any implementation of the Tenth Blessed Method is flawed the same way).
Even flawed Blessed Methods are far superior to the checking (basically none) we can reasonably expect from a normal person using a web browser. But still, improvements upon the Blessed Methods are a topic of public discussion, if you think you genuinely have a better way you should definitely let the CA/B Forum or m.d.s.policy know about it.
Having any valid cert (DV or otherwise) proves that you are viewing the example.com that the owner of example.com wants you to see. Without a certificate, you can/will be MITMed.
>It's just too easy to get them to think they really mean anything.
I'm not sure what you mean by this:
1. Are you saying that there is a vulnerability where you can get a valid certificate for a domain you don't own?
2. Do you mean the fact that valid owners of a domain can get a certificate easily?
If 1, please provide more info. If 2, why is that a bad thing?
Google is not doing this without interest, but I guess it overall is beneficial for us as well...