Live data from Hacker News

Encrypted web traffic now exceeds 90%

netmarketshare.com

121–130 of 311 posts

Re: Encrypted web traffic now exceeds 90%

#121
post #116

Earlier quoted context omitted.

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

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.

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.

Re: Encrypted web traffic now exceeds 90%

#123

Earlier quoted context omitted.

...do you? Unless the attacker has access to the private key associated with the SSL certificate, they can't read any HTTPS traffic encrypted via that certificate - mitigating the ability of that bad actor to perform a MITM attack.

The above poster is still technically correct though, getting the cert is just 1 more obstacle in the way of the attack, which isn't as much of an obstacle as one would think for some actors(see China).

Certificate transparency would make it blatantly obvious if Chinese CAs were issuing bogus certificates. (And if they issued certs without submitting them to CT logs they wouldn't be accepted by Chrome or Safari, so it wouldn't be very useful.)

Sure, they could do it, but it wouldn't be long until there were no Chinese CAs trusted by any browser.

Re: Encrypted web traffic now exceeds 90%

#124
post #116

Earlier quoted context omitted.

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.

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.

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.

Re: Encrypted web traffic now exceeds 90%

#125

Earlier quoted context omitted.

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

>Which is fine too, since not all communication needs to be secure (even on the internet). There was just an article on the front page today about "I have nothing to hide" and why it's wrong.

An example may illustrate my point: download software zip/tar files from a non-secure link. Obtain the signature and checksum files over a secure link, and verify the integrity of the software offline.

Not every communication is about hiding personal stuff.

Re: Encrypted web traffic now exceeds 90%

#126

Earlier quoted context omitted.

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

...do you? Unless the attacker has access to the private key associated with the SSL certificate, they can't read any HTTPS traffic encrypted via that certificate - mitigating the ability of that bad actor to perform a MITM attack.

And even if they get a key, they will show up in the CT Logs eventually and the attack becomes public.

Re: Encrypted web traffic now exceeds 90%

#127
post #20

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

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?

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.

Re: Encrypted web traffic now exceeds 90%

#128
post #113

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.

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.

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

Re: Encrypted web traffic now exceeds 90%

#129
post #73

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 ag…

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.

Re: Encrypted web traffic now exceeds 90%

#130
post #87

Earlier quoted context omitted.

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.

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 lo…

Can you define "uninhibited"?
Post reply on HN