
Encrypted web traffic now exceeds 90% - gator-io
https://netmarketshare.com/report.aspx?options=%7B%22filter%22%3A%7B%7D%2C%22dateLabel%22%3A%22Custom%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22secure%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22https%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222019-10%22%2C%22dateEnd%22%3A%222019-10%22%2C%22segments%22%3A%22-1000%22%7D
======
svara
We often hear the complaint here that nobody cares / cared about Snowden's
revelations. But to me it seems he did provide a lot of the impetus for having
HTTPS virtually everywhere and a lot of the instant messenging apps being end-
to-end encrypted. Most of WhatsApp's users are as non-technical as it gets,
and yet they use the kind of encryption that only computer enthusiasts were
interested in just a couple years ago. It's a great development (all the
limitations and caveats notwithstanding) IMO.

~~~
Andrew_nenakhov
Ironically, Telegram markets itself as the most private and secure messenger,
but in reality, it's much less private than WhatsApp or Viber: any regular
(non-secret) Telegram chats are not end-to-end encrypted - if they were, you
wouldn't be able to access them from a new device after authorization with a
password.

~~~
nostrademons
This marketing message always confused me: my techie understanding was that
Telegram is actually one of the _least_ secure messaging choices. If you want
security, my understanding is that your preferences should go Signal,
Whatsapp, iMessage, Hangouts or whatever Google's flavor-of-the-month
messaging app is these days, Telegram, and Facebook.

~~~
pkulak
I was following you until Hangouts...

~~~
nostrademons
Google's security is still better than both Telegram's or Facebook's. It's not
_great_ , but that's why it's #4 on a list of 6. If you care significantly
about privacy & security I would not use anything worse than iMessage, and
even that's borderline.

(Your opinion of whether Google or Telegram is better will likely also depend
upon whether you think malice or incompetence is a bigger threat. Google's
business model relies upon it snooping on you, but they have _really, really
good_ security people ensuring that nobody else snoops on you. Meanwhile
Telegram has less of incentive to actively violate your privacy, but they may
let other parties violate your privacy by passively fucking up their
engineering. They've done stuff like roll their own crypto algorithms, which
is a terrible no-no for anyone that cares about security.)

~~~
samtheprogram
How is iMessage worse versus Hangouts? Is Hangouts even end-to-end encrypted?
IIRC it isn’t, neither is Google Chat (a product which is replacing Hangouts
from what I can tell), just Allo and Duo.

~~~
girvo
That’s not what they said; they’ve said that iMessage has better security than
Hangouts, and that this user wouldn’t use anything “worse” ie. further down on
their list than iMessage

~~~
lern_too_spel
It is worse in that Hangouts does not make false claims about its security, so
people who use it know that they are using it for features provided by the
kind of security it provides (only between the user and Google), like
searching chat history across devices.

iMessage can also only guarantee security between the user and Apple due to
Apple distributing the public keys (but to a lesser extent because it uses
worse crypto), but it does not provide the usability features like searching
full chat history across devices that Hangouts does.

------
gambler
I don't know why so many people here are patting themselves on the back over
this. This is not the kind of encryption people were talking about in the 90s
and 00s. A lot of this encryption is not point-to-point. It merely secures
user's interaction with some middleman (or their server). What would the
numbers be if you subtracted all the traffic that can be snooped on by Google,
Amazon and Cloudflare?

~~~
stjohnswarts
What are you talking about about? I think you better look up how https/tls
works??? Sure you have to trust the certificate authority. Also can you
imagine the scandal that would erupt if Google or AWS cloud was discovered to
be eavesdropping on companies running things in their cloud? I don't think so.

~~~
gpm
> can you imagine the scandal that would erupt if Google or AWS cloud was
> discovered to be eavesdropping on companies running things in their cloud

Remember the "SSL added and removed here" image?

[https://thumbs.mic.com/MTBjNTQzNTMzZiMvbWVtejZOdjJsaUdUVkZEa...](https://thumbs.mic.com/MTBjNTQzNTMzZiMvbWVtejZOdjJsaUdUVkZEa3I1cVgyVkRjTlFFPS8weDQwOjQ5MXgzNDkvODAweDQ1MC9maWx0ZXJzOmZvcm1hdChqcGVnKTpxdWFsaXR5KDgwKS9odHRwczovL3MzLmFtYXpvbmF3cy5jb20vcG9saWN5bWljLWltYWdlcy9kMjg1N2Q0MzliNGEwMDcyNmQwMzYwMGVjMTEzMzdkMjA2MDE4MWM2OTIzYjliN2NmYzc5ZGIyMjkxNDMwOWY0LmpwZw.jpg)

~~~
UncleMeat
That wasn't eavesdropping by Google. That was Google not using encrypted
traffic on internal wires. And that changed a lot of years ago.

~~~
gpm
Yes, it was the US government eavesdropping for them without their consent,
but the end result is basically the same.

Yes, that exact hole was patched, but the point is it wasn't the end of the
world that great grandparent implied it would be.

~~~
lern_too_spel
Google Compute Engine didn't even exist at the time that slide was made, or at
least was not publicly available. That slide was about government intercepting
Google's traffic, not cloud customer traffic.

~~~
gpm
It was certainly smaller, but GCE was first publicly available in April/May
2013, Snowden leaked things in June 2013. I'm not quite sure when this slide
was released but sometime after that.

Google moved to fix the problem after the start of the leaks. Pretty quickly
(good for them), but after.

~~~
lern_too_spel
The slide was created long before Snowden leaked it, which is before GCE was
publicly available. I said, "before the slide was _made_ ," not "before the
slide was _leaked_."

------
mholt
Good news for sure, but note that this isn't a total Internet scan:

> We collect data from the browsers of site visitors to our exclusive on-
> demand network of analytics and social bookmarking products.

More details about their samples:
[https://netmarketshare.com/methodology](https://netmarketshare.com/methodology)

I would be more inclined to trust sources like
[https://transparencyreport.google.com/https/overview](https://transparencyreport.google.com/https/overview)
and Firefox Telemetry which come directly from the browsers. But even these do
not count data from mobile apps (most of which have to be encrypted now I
think), embedded applications, scripts, and APIs.

~~~
input_sh
> from mobile apps (most of which have to be encrypted now I think)

Since the end of 2016 on iOS and since Android v9, apps _have to_ communicate
over HTTPS. I guess you can technically visit HTTP sites via a browser, but
I'd bet that >90% of the traffic from smartphones is over HTTPS.

~~~
UncleMeat
> since Android v9, apps have to communicate over HTTPS

That isn't true. It is the default but Android lets you override the defaults
and use unencrypted traffic both in WebViews and in networking APIs.

~~~
jsjohnst
It’s not true in iOS either. It’s possible for an app to whitelist specific
domains.

------
alpb
Also likely because in the past the internet was really diverse. One would
visit 20 sites possibly during one session.

Today, the landscape looks more like: You visit Google, click some links that
open in AMP (still Google), visit some social networks (primarily Twitter and
FB-owned properties). These companies already operate TLS-only, which helps
these numbers.

~~~
taftster
Right. Encrypted web traffic at 90% is different than encrypted web sites at
90%.

~~~
wolco
When netflix is half, torrent traffic included add in google/facebook/faangs
and you arrive at 90% easily.

~~~
Thorrez
I thought torrent traffic was generally not encrypted.

~~~
cyphar
Not to mention the world-class encryption used by torrents is RC4. It would be
hard to pick a worse cipher (the encryption protocol was designed in 2006).

------
smolder
That's good. One structural issue with the internet down, many more to go.
There is essentially no guarantee that cloud providers don't snoop through
memory and steal your keys and sift through your data, for instance. There are
just some big companies that we implicitly trust. Whenever the endpoint for
encryption /decryption is under the control of a 3rd party, any guarantee of
data safety isn't real. We have devices that constantly go out looking for new
code to run, with proprietary blobs in firmware, which means they're 3rd party
controllable. Control of the internet is in the hands of organizations that
can't be held accountable for abuse of power over individuals.

I guess I'm just saying I don't have faith that a system (I'm talking about
the intersection of technology, government, and business here) which puts so
little power in the hands of individuals will do an adequate job of serving
their interests in the long term.

------
vinayan3
We do need HTTP because sometimes public WiFi networks need you to agree to
terms before any requests stop being redirected. I recently found
[http://neverssl.com](http://neverssl.com)

That being said those public WiFi’s shouldn’t be redirecting sites in the
first place because for HTTPs sites browsers don’t even let you see the page.

~~~
mahesh_rm
[http://http.rip](http://http.rip)

~~~
MayeulC
I personally prefer [http://example.com](http://example.com) as is it is
explicitly http-only, adminitred by IANA.

It boggles my mind that we haven't yet agreed on a signaling mechanism at the
AP level (DHCP?) for signaling captive portals, as this seems to be quite a
common use-case.

------
chrisweekly
Awesome! Any idea how much of that is attributable to LetsEncrypt and
HTTPSEverywhere?

~~~
mikece
Is a LetsEncrypt certificate "just as secure" as other certs? I have to
imagine the answer is "no" simply because LetsEncrypt is free and the other
certs aren't -- what more do you get by paying for a cert?

~~~
a13n
It is just as secure, you get nothing more by paying.

~~~
deaps
So for my personal projects, I use lets encrypt. As far as I know (and I could
be wrong now, haven't checked in a while) - their certs are _only_ good for 3
months. Which is simple enough to get around - run a script on your box that
updates the cert every 90 days automatically.

At work, we use a paid certificate that is good for a longer period of time
(normally a year). So that's one benefit to paying, I suppose.

As far as encryption technologies and security, the traffic encrypted by a
lets encrypt cert is just as secure as the traffic secured by a paid-for CA
signed cert.

~~~
taftster
The fact that Let's Encrypt certificates expire quickly is a feature, not
anything to do with paid vs. non-paid.

Let's Encrypt could have just as easily generated certificates good for a year
or more. But the point of Let's Encrypt is to force you to do this in an
automated way, using scripts like you suggest.

You're not getting around anything. The choice was by design.

[https://letsencrypt.org/2015/11/09/why-90-days.html](https://letsencrypt.org/2015/11/09/why-90-days.html)

------
est31
While this milestone is wonderful, don't forget that it can't be decrypted
_for now_. IMO we trust contemporary encryption algorithms too much, putting
too much data through the wires that will only increase in value. We aren't at
the end of the evolution either: we still don't have really secure random
generators everywhere, we are still using key exchange methods that aren't
quantum proof. And of course, computer programs (as well as hardware) still
have security bugs.

~~~
tantalor
Encryption is worthless without properly enforcing it. How easy is it to trick
your victim's bank into granting you access with a SIM swap? We need 2FA
everywhere and stop relying on SMS for authentication.

~~~
acid__
I agree that we need 2FA and that we shouldn't rely on SMS. That said, saying
encryption is worthless because other threat vectors exist is a bit
hyperbolic. Security is all about defense in layers. There's several orders of
magnitude difference in the difficulty of performing a SIM swap attack vs
sucking up passwords on coffee shop wifi.

------
miguelmota
This doesn't mean 90% of all websites. This simply means 90% of web traffic
which I'm assuming a good chunk of it comes from a few handful of services
such as Netflix and YouTube

~~~
dr-detroit
most of the traffic is people watching people play videogames

------
campuscodi
No, it didn't. NetMarketShare has a very limited view into these things.
Actual data from browser makers

Firefox - 80% [https://letsencrypt.org/stats/](https://letsencrypt.org/stats/)

Google -- 88% on Android; 84% on Windows; 91% on Mac; 73% on Linux
[https://transparencyreport.google.com/https/overview?hl=en](https://transparencyreport.google.com/https/overview?hl=en)

------
jjice
I actually just set up SSL on my EC2 instance after reading this comment
section. It was stupid easy, and I can't believe I didn't do it before

------
Jonnax
Nice. Remember the days when IT professionals would exclaim that this was a
bad idea?

Seems like it's cyclical thing. DNS over HTTPS is now the big bad technology.

~~~
aesh2Xa1
No, haha. When was that a thing?

~~~
cesarb
Back in the 1990s and early 2000s, it was very common to have "transparent
proxies": your router or the ISP's router was configured to transparently
redirect all connections to TCP port 80 to a Squid caching proxy or similar
running on a nearby server. This meant that images, CSS, JS, or even whole
pages (the web was much less dynamic back then) were transparently cached and
shared between all users of that router. That could save a lot of bandwidth.
Encrypting the HTTP connections completely bypassed the caching proxy; to make
it worse, IIRC some popular browsers didn't cache the content from encrypted
connections as well, so every new page view would have to come from the origin
server. Obviously, the IT professionals which set up these caches didn't like
it when most sites started switching to HTTPS, since it made the caches less
useful.

~~~
unilynx
A common problem back then with those caches back then was that in their
common configuration they would limit the maximum upload size to a few
megabytes... which would manifest itself as a broken connection when such an
upload was attempted.

We regularly had to tell customers "can you try whether uploading works with
this HTTPS link? now it suddenly works? okay, use that link from now on and
complain to your network admin/isp"

------
robbya
The 50-50 point appears to have only been June 2017, so the cutover rate is
really quite rapid. I wonder how quickly we'll see 95%, 99%, and how long the
long tail will be.

[https://netmarketshare.com/report.aspx?options=%7B%22filter%...](https://netmarketshare.com/report.aspx?options=%7B%22filter%22%3A%7B%7D%2C%22dateLabel%22%3A%22Custom%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22secure%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22https%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222017-05%22%2C%22dateEnd%22%3A%222017-06%22%2C%22hiddenSeries%22%3A%7B%7D%2C%22segments%22%3A%22-1000%22%7D)

------
ecesena
One thing we recently started looking at is outbound traffic, i.e. links that
people click within our website/app. We're going to publish some results (and
joint forces) soon, but I wanted to share here because I feel outbound links
are something usually ignored. Yet they can contribute to a significant part
of the total Internet traffic.

So, upgrading outbound links from http to https (where possible) can be
another way to contribute to achieving 100% of the web traffic encrypted.

------
frankzen
The Federal Government may not like this but this is heading to as it should
be. Sometimes the government needs to be saved from itself!

~~~
codexon
Governments can force CAs to give them certs. HTTPS only stops non-government
attackers.

~~~
profmonocle
They would be killing the CA by doing this, since all certs have to be
publicly logged in order to be trusted by Chrome or Safari:
[https://en.wikipedia.org/wiki/Certificate_Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency)

If a minor CA suddenly issued a cert for, say, mail.google.com, they'd be
distrusted by every browser/OS within days. If a government made a habit of
doing this, there'd soon be no trusted CAs in their jurisdiction.

The US probably has the best chance of getting away with this since they also
have all the major OS/browser vendors in their jurisdiction. But if
Mozilla/Apple/Microsoft/Google all mysteriously decided not to distrust a CA
that was issuing bogus certs for high-profile sites, it would be pretty
conspicuous.

------
code4tee
Excellent progress and a great credit to LetsEncrypt and others that brought
free cents to the masses. There’s almost no excuse to not encrypt anymore. The
“not secure” shaming of non https sites by major browsers also applied some
needed peer pressure.

------
rb808
Does this include Netflix traffic? Which would skew the results.

~~~
catalogia
Wouldn't the result be skewed if it _didn 't_ include Netflix?

------
ourcat
Thank you LetsEncrypt.

------
ganitarashid
Thank you Edward Snowden

------
geometricstripe
The trend is going in the right direction.

------
lowiqprogrammer
This is awesome, just 5 years ago the numbers were reversed.

------
jyutin
greate!

------
ksenzee
I wonder how much of this is due to Cory Doctorow's novel Little Brother.

------
jancsika
To the 90%: if you've got nothing to hide then why are you encrypting your
traffic?

~~~
philg_jr
Probably sarcasm but...why shut the door when you're in the bathroom?

~~~
catalogia
I like this analogy. We all know what goes on inside a bathroom, it's not
really a secret. But it _is_ private. There is a difference between secrecy
and privacy, and this analogy captures the difference well.

I think I first heard the analogy in Cory Doctorow's presentation _The Coming
Civil War over General-purpose Computing_ , which was ironically given at
Google. I highly recommend people watch it.

------
meche123
Oh, so finally most of the porn sites are defaulting to https?

------
ga-vu
It's been at over 90% for more than a month, from what I can tell

~~~
gator-io
if you look at the trendline, it was 88.7% last month:

[https://netmarketshare.com/report.aspx?options=%7B%22filter%...](https://netmarketshare.com/report.aspx?options=%7B%22filter%22%3A%7B%7D%2C%22dateLabel%22%3A%22Trend%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22secure%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22https%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222018-11%22%2C%22dateEnd%22%3A%222019-10%22%2C%22segments%22%3A%22-1000%22%7D)

------
axaxs
Great. Now nobody can see what you do except companies who sell everything you
do...

------
uxp100
I know this is good and all, but it does bum me out that Netscape 4.8 works
much worse than it did even a few years ago. I prefer it to iCab, which might
fair slightly better. Any suggestions for Mac OS 7.6 web browsers that support
the minimum encryption required these days?

~~~
bbanyc
My suggestion is to set up a proxy. This has long been necessary to run
browsers like Mosaic on the modern web, since many websites are inaccessible
from HTTP/1.0 (or earlier!)

It's funny how ever-moving Internet standards mean an Apple II from 40 years
ago is more functional than an iMac from 20 years ago.

------
santojleo
I’m sorry, but there’s a lot of smart people here. Why is everyone assuming
HTTPS means no one is snooping? I presume someone is snooping no matter what.

~~~
lrem
Snooping on Https requires significant resources. Snooping on http is very
cheap. A good analogy is locking your door. Sure, can be dealt with. But most
would be criminals won't go further than twisting the door knob.

------
gscott
This is good to keep out moderate bad guys from your data. But the not so much
for the NSA. The NSA already captures traffic end to end including the key
negotiation and can break the rest [https://arstechnica.com/information-
technology/2015/10/how-t...](https://arstechnica.com/information-
technology/2015/10/how-the-nsa-can-break-trillions-of-encrypted-web-and-vpn-
connections/)

~~~
philipkglass
Even when it was first discovered, only 8.4% of the top million web sites were
estimated to be vulnerable to the Logjam attack:

[https://arstechnica.com/information-
technology/2015/05/https...](https://arstechnica.com/information-
technology/2015/05/https-crippling-attack-threatens-tens-of-thousands-of-web-
and-mail-servers/)

Now I would expect the number to be much closer to 0%.

------
whydoyoucare
This statement would be more meaningful had it been phrased something like
this: "encrypted web traffic, which most adversaries cannot snoop on, exceeds
90%".

There will always be an adversary, far powerful than you, with an ability to
snoop on your traffic - be it your ISP, the other endpoint, or owners of the
infrastructure that you consume, but do not control.

~~~
gnode
You portray encryption as a magical energy. To the best understanding of
cryptanalysis research, current TLS is secure. Hypothetically it could be
broken and publicly unknown, but this is not a matter of "power".

> the other endpoint

It's not sensible to say encrypted web traffic is snooped on by an actor with
direct access to the plaintext.

~~~
whydoyoucare
The simple statement made in OP, does not capture the complexity of
operational security, which is very difficult to get right. I was merely
trying to illustrate that.

For e.g., even though TLS is end-to-end secure (and I don't doubt that), a
website that uses CloudFlare front [1] is susecptible to its secure traffic
being intercepted by CloudFlare, because by-design TLS would be terminated at
CloudFlare servers'. However, note that the end-user does not notice that,
rather he sees his traffic end-to-end encrypted.

[1] [https://support.cloudflare.com/hc/en-
us/articles/200170416-E...](https://support.cloudflare.com/hc/en-
us/articles/200170416-End-to-end-HTTPS-with-Cloudflare-Part-3-SSL-options)

~~~
profmonocle
> a website that uses CloudFlare front [1] is susceptible to its secure
> traffic being intercepted by CloudFlare, because by-design TLS would be
> terminated at CloudFlare servers

Keep in mind, this is also true of cloud providers. By running the hypervisor,
AWS has full access to your instance's RAM and could snoop on traffic if they
pleased.

A compromised service provider is a risk you're accepting unless you own and
physically control the hardware terminating TLS. Whether this is an acceptable
risk comes down to your threat model. (As do so many things in infosec.)

