So, what value do the SA government have in intercepting these links now?
So, what value do the SA government have in intercepting these links now?
It seems a ton of mobile apps are sending information with identifiers over HTTP (the ID is a key part for them legally to pick it up and store it in a DB, forever). I notified one developer that was sending real-time GPS data + an email address highlighted in one of the PPT slide's (just a screenshot of a spreadsheet-like table) and never got a response from the developer. It was a small Canadian company with an app with a few million downloads, so I told Citizenlab about it (don't remember the name, had something to do with sports IIRC).
This is a chart of TLS traffic sent via Chrome and across Google:
https://transparencyreport.google.com/https/overview?hl=en
2014 = ~50%
2019 = 94% of traffic encrypted for Chrome users which is great.
Linux users currently have the lowest when using Chrome with 86%. I'm curious why this is.
Again mobile apps seem to be the biggest problem right now and there was no red HTTPS sign when they sent your sensitive information over cleartext:
> Mobile devices account for the vast majority of unencrypted end user traffic that originates from a given set of surveyed Google services. Some older devices cannot support modern encryption, standards, or protocols.
Maybe Google PlayStore should start punishing apps for not using HTTPS? Just like how Google is trying to make the internet faster by ranking performant/mobile friendly sites higher.
The app testers should put fake identifying information in the various app forms + automatically measure the outbound HTTP traffic for cleartext versions of the IDs.
They probably browse quite a few old sites for documentation and tooling that are just not updated for HTTPS. A forum I post on to this day is still served over plain ole HTTP and they have no interest in changing.
I doubt kernel hackers make up a large enough demographic to skew the metrics...
A lot of popular Linux and developer related pages are HTTP only. I did a quick Google search for some Linux related tasks, and found plenty of sites that don't use HTTPS. e.g. man7.org, linuxhowtos.org, linuxcommand.org
The report does break down HTTPS traffic by country, and you're right that lower income countries do have a lower share of HTTPS traffic.
Wikis arent the problem!
This doesn't surprise me when you consider that package management over HTTP is considered ok since it's separately authenticated and verified is a very common view
That this view would also spread to not requiring HTTPS on documentation and other sites would also not be surprising
The Linux world really needs to get it's act together with providing confidentiality via SSL/TLS
Aside: I know at least for some orgs, ATS was helpful in convincing the older 'why isn't http good enough?' folks to finally get their act together. It may be shocking, but some people are quite resistant to typing in that extra 's'.
* If you have compromised a private key, you can get useful data from the cable intercept.
* If you can collect ciphertext today, and decrypt it tomorrow (with, say, quantum computers), the cable intercept is very useful.
The OC's point was by default, meaning/inferring clear-text is still the modus operandi for generally getting onto IRC services.
>Many applications still aren't encrypted by default, like IRC.
SSL and SASL aren't, precisely, user-friendly implementations with some clients (e.g.: IRSSI[0] - but if you're using IRSSI, you don't want a user-friendly GUI to begin with, so...).
SASL has less to do with the actual encryption mechanism and more to do with the authentication mechanism (think NTLM)[1].
If IRC services dropped clear-text, today, that would go a lot further to standardising (e.g.: making default) encryption but, back to the OC's original point, it is not the default today.
[0] - https://freenode.net/kb/answer/irssi
[1] - https://en.wikipedia.org/wiki/Simple_Authentication_and_Secu...
I mention SASL because it is relevant to security posture, especially if the user wasn’t connecting via TLS. Although of course the server could allow PLAINTEXT in practice there’s no point in supporting that because IRC already had native plaintext server authentication.
[1]: https://github.com/hexchat/hexchat/blob/3d1d9e1716d66abb6921...
It probably means your email to your aunt isn't intercepted and shoved onto an enormous pile of decrypted email to be parsed for keywords. Probably. But that's about all.
Against an adversary determined to intercept:
- They can probably just strip STARTTLS, so that everything happens in plaintext - Even if they can't do that because of MTA-STS or similar, they can probably just present self-signed certs and it'll pass the mandatory checks - If they can't do /that/ either (no idea what proportion of email but it may well be in the minority) they can downgrade because unlike in HTTPS nobody is just saying "Old garbage bad, never do that or we'll scream" and so people keep doing it. SSLv3 may even work with a lot of mail servers.
Still, what we have now with opportunistic SMTP encryption is equivalent to what you get with snail mail. The spooks CAN read anybody's mail, but it's a hassle so they mostly don't read yours.
They're a lot better than I thought! (over 90% in each direction, although no data here about certificate verification and the presence or absence of backbone downgrade attacks)
If you run your own mail service, check out my colleague's project at
Remember that the intelligence agencies don't only want today's data, they want yesterday's data. You get yesterday's data by storing it today. Then you can decrypt it at your leisure, or when computers become powerful enough to break through.
I know a lot of people on HN earn a living making sure internet traffic is encrypted. But honestly, I really believe there are multiple TLA's that can decrypt whatever they want in real time. Maybe not en masse, but certainly targeted streams.
How? They've cracked modern public key crypto?
State of the non-TLA art is that modern https is completely impractical to break, even with enormous server farms working for years, let alone in real time.
I have no idea how they're doing it. But I believe it can be done simply because the intelligence agencies have the best, largest, fastest, most advanced machines that money can buy. Machines that none of us have even heard of, that are years ahead of anything any of us will ever touch in our lifetimes.
If you told me you thought they had cracked a common algorithm so they could do it in only 2^60 time that would at least be plausible. But the idea that they have hardware to straight up brute force it, though, is just impossibly wrong.
Seeing this photo makes me think that's more likely.
https://blog.encrypt.me/assets/img/posts/2013/11/05/nsa_slid...
Pardon the source but I'm on mobile.
(Disclosure: I work at Google)
It's probably more likely that they're just trudging along with side-channel attacks, CA fuckery, breaking into servers, and doing targeted attacks though. Cheaper and likely works well enough.
The more prosaic means you're describing, plus zero days and phishing (unless that's included in "targeted attacks"?), can still get them a long way.
You're probably right on the quantum computers of course, but I like comparing it against what was publicly know about say cryptanalysis vs what the NSA knew in the DES days, and also similar situations in the ww2 days.
That's a pretty bizarre thing to believe. Who is building these machines? Intel? No other organization within the US has the lithography capabilities to manufacture cutting-edge computing hardware, much less "years ahead of anything any of us will ever touch in our lifetimes". Perhaps it's aliens?
They reacted to the information becoming public.