Capturing Linux SSL/TLS plaintext without a CA certificate using eBPF
github.com
github.com
https://github.com/bpftrace/bpftrace/blob/master/tools/sslsn...
https://github.com/iovisor/bcc/blob/master/tools/sslsniff.py
https://embracethered.com/blog/posts/2021/offensive-bpf-snif...
On Ubuntu for example I can just "sudo apt install bpfcc-tools", then run "sudo sslsniff-bpfcc" and see curl TLS traffic right away.
We use similar approach in Coroot to get fantastic observability insights with zero configuration
I use a localhost-bound TLS forward proxy. Works on both BSD and Linux, kernel config is irrelevant. Allows me to easily redirect and modify traffic.
ECH is still lagging in server adoption. After Cloudflare discontinued their ESNI trial I have avoided sites that require SNI, e.g., ones using Cloudflare. What I have found is that most websites on the internet still do not require it. The sites that use a handful of large, popular CDNs are the exceptions. There are numerous workarounds for those, e.g., archive.org needs no SNI. Allows me to access Cloudflare sites without sending SNI.
As for certificate pinning, I do not use closed source "apps".
If corporations MITM their TLS traffic then individuals should do the same.
Works for me on a Debian 12 installation with the default kernel.
For a full bypass of that crap, you nowadays need a lot of resources including a Secure Enclave exploit - for now they're (relatively) cheap but eventually they'll be the kind of stuff traded for seven figures a pop.
Eternal shame on Google for not insisting that Android would follow the "PC model" of the user being root on their own machine and DRM and whatnot can go and screw themselves. They had the chance of actually delivering something that would not require jailbreaking and cat-and-mouse games like iOS, but they blew it (and blew the MAFIAA instead).
The funny thing is that they wouldn't have even needed to take this position. DRM works well enough on (e.g.) Windows to make the various studios more or less happy, and users have "root" on Windows as usual. Ditto for macOS. Hell, DRM works just fine on my Linux desktop install, as much as I despite its existence.
To be fair to Google, banks don't usually allow you to download and generate EMV tokens to perform card transactions on your PC, which places a different set of security requirements (legal requirements too) on Android phones for things like Google Pay to exist.
I might be less angry about that if there were a decent FULL backup solution for Android - with iOS I can do a backup and restore and almost everything will be restored, I think the sole exception is eSIM and Apple Pay because the secrets for that are in the SE. But for Android? Forget it, and there's enough games that don't even implement Google Play cloud-save integration. No way to backup these without root.
That requires HTTPS interception. Before TLS1.3 they would install root CAs on all company devices, have an edge proxy, and use SNI to determine whether an HTTPS session should be man in the middled. Because it would take way to much compute to MitM all trafic (like YouTube video).
After TLS1.3 encrypted SNI blocks this. But they still need (and other companies want) to selectively intercept HTTPS. With a tool like this you can achieve that clientside, rather than at the network edge.
It can be disabled if an organisation wishes to. I wrote about how to do this in Chrome [2,3], and will write about Firefox when I get a chance.
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ [2] https://chasersystems.com/blog/disabling-encrypted-clienthel... [3] https://news.ycombinator.com/item?id=37823262
I do find it sad it isn't pushed harder. Companies who need to do interception have legitimate concerns, but they can be addressed.
> L’employeur ne peut pas mettre en place un dispositif d’écoute ou d’enregistrement permanent ou systématique, sauf texte légal (par exemple pour les services d’urgence).
And there's afaik no such legal text for banks.
Employees also have the right to privacy on their work-provided computer (e.g. to check their personal mails) so all those packet inspection and decryption things would be flat-out illegal there, thankfully
If you want to check your private email, you can just use your personal device.
If you need k8s support I can also help with that, if you get CAP_SYS_ADMIN you can break out of the container and then back into every other container ;)
Is there any way to account a response of a TLS enabled server to it's public key?
Something like reverse fingerprinting?
I was hoping responses were signed.
If the cipher suite used has authenticity in the symmetric part, that proof would be enough.
There are no implementations of this to my knowledge, and all the general zero knowledge proof caveats of speed, proof-size, etc all still apply.
It is definitely possible though. It would be cool to make. Why would anyone need this though?
I don't think this is possible if all you have is your own recording of the ciphertext, with no proof that it was actually transferred over the wire. This is the typical situation with packet capturing at one endpoint only.
But there was no background info. Just "We use ZKP to prove we got the right data"
So, it's technically possible?
I guess, the only reliable way is to sign the response, which requires changes to the server
If I sign any data, it's mathematically linked to the certificate, but that doesn't mean the cert was involved in creating the data.
If you want to fix this, you need the authenticity of the ciphertext to be proven to the recipient without the recipient being able to transfer it. An interactive zero knowledge proof could maybe do that.
Because IMO, what my PC is doing and sending over the network at all times should be inspectable by me, on that computer.
It's a Linux project that's replication what Little Snitch does on macOS - it doesn't decrypt TLS secured data but it does show and allow blocking of network connections (even if it can't see exactly what's going on inside this connections).
Combining eCapture features with OpenSnitch would be awesome. It'd be great if as well as tracking all network connection, you could flag connections sending specific data (like your name, email address, or phone number) to unexpected servers.
it sorta gives you a kernel space VM. you can inspect the state of things, make decisions about that state, and react to those things.
for example, you could look at uri requests coming into your web server. if it's not a known good path, reply back with a canned 400 - without ever hitting the web server. you can do this in the kernel.
_edit_ I think this particular trick would only work with http. the web server still has all the glue to decrypt the incoming request - but you could probably hook into ebpf at that point.
So if this works there it might be useful in, for example, analyzing encrypted video traffic for some video games.
changelog: https://github.com/gojue/ecapture/blob/master/CHANGELOG.md
I figured the reason it wasn't interesting the first time was something like "Are you telling me that a kernel, and anyone with root access to that kernel, can ultimately know everything a kernel does? Shocking!"
That said, there are other ways to do similar probing: - Loading kernel modules. - Using ptrace. - Using LD_PRELOAD against a dynamic binary.
Apart from the more exotic facilities, the critical facilities that would be hard to disable include LD_PRELOAD for interposers/shims (as you mentioned), and gdb for just setting breakpoints on crypto functions. And if neither of those existed, then I may have to edit openssl code and recompile my own edited version. And if that wasn't allowed (signed libraries) then maybe I'd edit the application code or binaries.
And modules can be compiled directly into a module-less kernel.