Encrypted web traffic now exceeds 90% (opens in new tab)

While a BCP is indication that “nobody cares” is false, it’s pretty far from even a majority of people caring. If BCPs mattered, IP spoofing wouldn’t be an issue on the Internet.

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.

They don’t claim end to end encryption by default though. You make it sound as if there is a revelation you made here.

Telegram has faults, I would even argue it has many, but it’s clear that only “secret” chats and voice/video calls are end to end encrypted.

Whatsapp, however, does allow you to download all of your messages from your device using WhatsApp web, and they were recently shown to have an exploit/backdoor in the applications themselves. So in that context they’re comparable in my opinion.

To add to the irony: Telegram has evolved in a bit of a darknet on its own where people casual share content that would be near impossible to find on the surface web.

Accessing chats from a new device has no technical relation (or constraint) to the lack of end to end encryption. Wire encrypts all chats end to end, and still provides syncing conversations to multiple devices on multiple operating systems. It does limit the sync to the last 30 days, but that’s mostly because of cost reasons rather than technical reasons.

Edit/correction: Neither Wire nor Signal sync conversations that have happened before the setup of a new device to the new device.

I wouldn’t loop backups into that criteria. iMessage syncs your message history to all of your devices in an end to end encrypted way: https://support.apple.com/en-us/HT202303

and WhatsApp allows user to backup/restore their messages with iCloud (unencrypted)

Telegram is not at all secure, the only real secure product is Signal, which is what Snowden actually recommended.

Are you saying that when you log into Telegram on a new phone it downloads the chat logs from somewhere? And that this only requires a short password?

At best this'd mean the logs are encrypted using the password as the key...

Are you sure the user isn't copying anything between devices? Chat logs and a keyfile maybe?

>if they were, you wouldn't be able to access them from a new device after authorization with a password.

Telegram isn't great but if your password was used to derive the encryption key, that feature would be entirely feasible.

they are not end-to-end encrypted but they are encrypted. Also, I read that WhatsApp is going to switch to the same mode, for user convenience: https://bgr.com/2019/07/29/whatsapp-update-to-bring-multi-pl...

> Why would a company ever want to release any product without strong encryption (end-to-end) when users never complain about their data being encrypted. The only reason companies don't encrypt is when they have a vested interest in spying...

I think the second thought doesn't follow from the thought before it. to my experience, the main reason companies don't encrypt is because it's simply makes it that much harder to debug problems and consistently provide successful connections for users. HTTPS can fail in ways that HTTP does not.

If users aren't clamoring for encryption as a feature, the main reason not to provide it is simplicity and quality of service along the axis users appear to care about. If users want encryption enough that they're willing to tolerate that sometimes browser misconfiguration or server side error will cause the connection to fail because it cannot be trusted, then companies will implement it.

Encryption in the last decade has also become a hell of a lot easier to implement, so "why wouldn't we just do it" has less opposition

I don't think I know many people who insisted on strong privacy/encryption. However, after the Snowden revelations people did consider it a preference. In that sense, it helped.

This is the more important factor at play here. Browsers (Google Chrome mainly) are forcing everyone to go SSL lest you end up with a 'insecure site' warning for all your visitors. Most websites don't care about NSA intercepting their data.

Yeah, Google has done much for privacy and it's kind of ironic how people believe those who say it's malicious. The only crime Google ever did was to be successful.

Wasn’t the server load for ssl something like 3-5%? That doesn’t strike me as much of a factor as the complexity involved, especially with the confusion added by eg Thawte hawking their enhanced validation product.

My P4 could do >400gbps AES128 in 2003. (We tested encrypted connections over Firewire.)

Firesheep co-author here. Thanks and agreed :)

Definitely. Considering the plethora of unencrypted wifi SSIDs that were out there back then, it was huge. Massively reported on in the MSM, too

What’s more important though? The public can’t particularly change things at that level. They don’t live at that level. It’s our job to help them. Just as they help me on non computer related stuff all the time. A barber shouldn’t be in charge of web encryption. It’s on us.

They could definitely do that. They could also mandate the use of "national security certificates".

https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...

It is still better than situation where everyone would use HTTP and naively believe that authorities will respect their right for privacy.

There have been fradulent certificates in the wild in the past but the CAs doing it usually get kicked out pretty quickly. That's what Google's certificate transparency project is for. And they are increasing requirements further and further. Hopefully one day we'll get to a state where the infrastructure of multiple independent companies in different countries needs to be compromised in order for one successful forgery. But even now certificate transparency has greatly reduced the number of entities able to forge certificates.

I don't consider a cert trustworthy just because it's signed by a CA, unless that CA is mine or one run by someone I personally know and trust. I came to this position before Snowden, though.

I feel like Namecoin and Ethereum Name Service are the most promising replacements for certificate authorities that I'm aware of. Are you aware of any better suggestions?

WhatsApp does control the clear text on both ends. They can do whatever they want with it.

As much as I despise Facebook and its properties, the “how do we know” question can only be answered based on the trust that there would be at least one person in the company/team who would be a whistleblower if the end to end encryption is removed (with their knowledge and not through some state sponsored hacking).

With that background, a motivated employee cannot read WhatsApp messages that they have not sent or received themselves because WhatsApp uses the Signal protocol implementation. Coming to your first question, WhatsApp does share metadata with Facebook. So the fact that content isn’t shared is a moot point because a lot can be inferred from metadata alone to target people for any purpose.

So WhatsApp is not really a secure messenger if Facebook is part of your threat model and is considered an adversary or an adversary who can be easily coerced or compromised.

If you’re talking about decrypting messages encrypted created and read via SSL (what they imply is the case), it’s not possible unless you have the private key, versus the widely available public key.

I doubt it’s lying around in Facebooks repositories but I’ve never worked there so cannot say that is the case with certainty.

This is all assuming they are even using modern SSL and are careful with user data. Unfortunately, not a great track record there for FB.

SSL was THE thing in 1995. End-to-end encrypted email has existed since 1991 (PGP), and for instant messaging you've been able to use OTR since 2004.

End-to-end encryption is what is needed, SSL is the bare minimum for everything. It's the seatbelt + airbag. You can't have a car without those anymore. E2EE is the ACC+AEB+ABS. You should not have a car without those anymore.

MITM is not mitigated at all by HTTPS. What makes you think that? Do you understand how certificate signing works?

I believe the OP is talking about encryption for user data, not merely for transport.

Google, Amazon, &tc still store user data uninhibited and though they are often competent about security, they also often provide data to state actors as a normal course of action. The fact the a web browser communicates safely with an endpoint doesn't mean that endpoint isn't a bad apple itself. In some cases these endpoints are logging proxies to other servers and services, and though transport is again encrypted, the data is normally accessible by operators of such services.

Cloud computing has taken away the ownership of data from individuals, and that sounds like it has seeds of some kind of a revolution brewing.

> 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...

Google and AWS aren't eavesdropping directly. However a lot of companies are running unencrypted connections between their load balancers and their backend services. And we know from the Snowden documents the US Government does passive data collection there.

The point is that if you're communicating with someone via Google, encryption terminates at Google, not with the other party.

If that was discovered nothing would happen or change. To some degree has happened with Windows 10, android/iOS for personal computing.

They wouldn't monitor themselves but provide access to law agencies anyhow.

Yes but in this case caching proxies and other distributed approaches still would work out of the box as alternatives to cdns. I am not sure what I have gained. Nobody cares about end to end email encryption. This would be a real benefit, but Google could not build profiles so easily...

Which is fine too, since not all communication needs to be secure (even on the internet).

These numbers are meaningless without a proper context and can potentially create a "security theater".

> 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.

Do iOS or Android have any requirements vis a vis HSTS or HPKP?

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

I personally prefer 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.

> It's probably more attributed to browsers marking non-https as 'Not Secure'

Browsers couldn't have done that if https wasn't free and simple for servers.

Pretty much this.

I ran into a local store taking credit cards awhile back, no TLS, weird, so I go to the store owner in person. I explain the problem and he insists that can't be the case, he's mad at me. "See! It's got a lock on the website!"... on the homepage. I direct him to the store and now it says Not Secure.

That did more to explain the situation than my attempt at TLS and HTTPS and Certs. He was able to call his web guy and say "It says not secure, Jerry! Fix it".

It was such a simple addition to (at least in Firefox) use the words Not Secure that it's crazy no one thought of it before.

Also Google mentioned they would begin ranking HTTPS sites higher.

I don't think any of my personal websites be HTTPS without LetsEncrypt. It's great for that use case.

Thanks! That was the goal. For those who aren't familiar, the original slides and our response blog posts are still up: https://codebutler.com/projects/firesheep/

They are just as secure. Here is an article explaining it deeper: https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas...

It used to be you paid because everyone who was trusted by browser manufacturers charged a fee, not because signing a certificate is actually hard or could be done in a "non secure" way. A signature is a signature.

LetsEncrypt signatures are now trusted by the browsers, so there's usually no need to pay for the service.

Thing is, even if LetsEncrypt were less secure (I don't really think it is, but lets assume), that would hurt the security of every website.

If you use a paid CA, someone trying to impersonate you could still go to lets-encrypt and get a certificate there. In other words, the system is only ever as secure as its weakest link. It doesn't matter what link you chose, it matters what link a potential attacker would use.

All of this is because failure of a CA only means false certificates are issued. Its not like lets encrypt ever could get access to any of your private key material.

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

I am sad that this question is down-voted. It seems honest enough, it's slightly off-topic but not dramatically so.

There are two halves to the first answer but they're both "Yes, Let's Encrypt is just as secure".

1. Most elements of TLS security have nothing whatsoever to do with certificates. This is easier to grasp in TLS 1.3 than earlier versions (all the encryption in TLS 1.3 is working before anybody sends any certificates anywhere) but it has always been true.

Even without certificates eavesdroppers can't see what was communicated, and nobody can change it en route between client and server. For these things even no certificate at all would be fine...

Certificates do add a vital thing though: Identity. A certificate from Let's Encrypt is a signed document from Let's Encrypt vouching for the identity of your site. Cryptography (with a "private key") lets you prove this certificate belongs to you and nobody else can do that. Without Identity somebody in a position to be an eavesdropper could just pretend to be you and intercept everything (a "Man in the Middle"). So even though it's a small aspect it's vital.

2. To go around issuing people with Certificates you need some way to know who is who. Until a few years ago there weren't many hard and fast rules about how to do this, and so a lot of rather dubious procedures were used by people who charged a pretty penny. Some of them would argue that charging validated the purchaser but that's not so smart, plenty of crooks are willing to spend money to make more.

So, Let's Encrypt actually helped write actual formal rules for how you can make sure you're issuing certificates to the real owners of the names they're certificates for. These are known as the Ten Blessed Methods, because there were once exactly ten of them and each is a method that the certificate issuer is allowed to use to do this Domain Validation. None of them are utterly foolproof, and there is ongoing work to further improve them or get rid of the least effective ones, but at least now there are written rules.

Having helped write these rules it should be no surprise that though they represent a significant tightening up of things for some of the incumbent for-profit issuers, Let's Encrypt was already doing everything required.

Partly this is actually helped by not taking money for certificates. Since Let's Encrypt doesn't make a profit from giving you a certificate, they've no incentive to do so unless they're sure.

Now: For the second part, I have written lengthy answers elsewhere, there are a lot of reasons you might pay somebody money. None of these reasons make Let's Encrypt any worse, and many of them are real niche cases, you'd know about it if you've hit those. Like if you make web sites for Nintendo's obsolete WiiU video game console - Let's Encrypt doesn't help you because the WiiU web browser doesn't have the right trust store for that. Or if you need S/MIME certificates for your corporate email system for some reason, Let's Encrypt don't offer that. If you need a special relationship with your issuer under contract (like Facebook has) then Let's Encrypt can't help you. And so on. For most people it doesn't matter.

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.

It's not worthless. It shrinks the attack surface and makes attacks more costly to execute. There's always an arms race though :P

All banks should adopt U2F and hopefully sooner than later :)

It seems like it's a problem with your router not being able to handle TLS. Old equipment doesnt last forever.

HTTP is the internet, and the amount requests a client makes is magnitudes greater than DNS.

Like Google or Cloudfare's DoH isn't slow.

> I could watch each command and response going over the wire.

AFAIK, Wireshark supports decrypting TLS traffic if you give it the private keys.

> When a POP3 mailbox got hung up on a single huge message you could just telnet in

Use “gnutls-cli” or “openssl s_client” – transparent TLS for your terminal. Both those commands also have options supporting protocols’ use of STARTTLS.

In the early 2000s almost any traffic that wasn’t involving financial services or ecommerce was plain HTTP. Gradually, HTTPS became optional (remember encrypted.google.com?) and more sites used it for login (but not all pages, even with cookies.)

This meant that MITMs were a lot more effective. Hell, even today Comcast and some other ISPs will MITM you to send notifications when it can do so on a plaintext HTTP connection.

A lot of IT departments also used this to be able to block unwanted traffic and perform monitoring. Now a lot of that relies on DPI techniques like analyzing SNI, or intercepting DNS. DoH and encrypted SNI work together to close both gaps, and widespread deployment of them would largely kill the ability to MITM or monitor consumer devices without modifications.

In modern times the cost of TLS certificates and the overhead of TLS encryption has dropped to effectively zero, so that ship has sailed, and nobody even remembers there was any concern to begin with. Maybe this time, it will be different, due to the lack of other options for MITM.

I imagine in the future there will be similar concerns about protocols that encrypt session layer bits like CurveCP.

I can't find anything specific at the moment but anecdotally I remember seeing this and being told it hurt performance to encrypt everything. The "solution" was to only encrypt sensitive pages like forms for credit cards.

I'm sure there was some substance to it at the time when computers, networks and browsers were slower but I also completely ignored that advice at the time and always used SSL everywhere on sites I set up.

I've never manged a very high traffic site so any extra overhead from SSL was negligible for us.

When people were concerned about HTTPS overhead? Both in terms of increased latency when establishing a connection and AES overhead for the duration of the connection. Hardware TLS accelerators used to be a thing.

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.

Verizon used to tell people that until this year.

And it is not unimaginable that the US government can crack the RSA. That would explain why they are not requiring people to use short keys, yet still collect the data worldwide.

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

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.

CAs don't have the private keys to the certificates they sign, so this doesn't compromise issued certs.

The ability for CAs to issue extra certs to governments to enable MITM has been reduced a lot by CAA and HPKP.

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.

Or "why lock your car doors when stealing and hotwiring is a crime"? Sure, people have convertibles and jeeps with no doors, but they also won't leave anything valuable out in the open.

Moxie has good points about the problems TLS has. And they are not about breaking TLS via cryptanalysis: https://www.youtube.com/watch?v=UawS3_iuHoA

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...