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.
Encrypted web traffic now exceeds 90%
121–130 of 311 posts
Re: Encrypted web traffic now exceeds 90%
#122Re: Encrypted web traffic now exceeds 90%
#123Earlier 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).
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%
#124Earlier 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.
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%
#125Earlier 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.
Not every communication is about hiding personal stuff.
Re: Encrypted web traffic now exceeds 90%
#126Earlier 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.
Re: Encrypted web traffic now exceeds 90%
#127Awesome! 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?
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%
#128This 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.
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%
#129We 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…
Re: Encrypted web traffic now exceeds 90%
#130Earlier 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…