Hacker News new | past | comments | ask | show | jobs | submit login
Capturing Linux SSL/TLS plaintext without a CA certificate using eBPF (github.com/gojue)
183 points by walterbell 4 months ago | hide | past | favorite | 70 comments



Similar tools already available in many distros:

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.


Yes, but most of them don't output pcap. Its just sort of every bit of decrypted data. Sure it works well for curl, but for nginx, or multiple connections, not so much.


bpftrace has support for outputting pcap files now.


What is the fuss about ? Of course if you have root access you have access to any process memory and also can intercept communication before encryption takes place.

We use similar approach in Coroot to get fantastic observability insights with zero configuration


This requires Linux and an uncommon(?) kernel config/module. Further, it does not seem to offer a facility for modifying traffic.

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.


> This requires Linux and an uncommon kernel config/module.

Works for me on a Debian 12 installation with the default kernel.


Gigamon offers a capability they call Precryption which functions the same under the hood, but also with a centralized interface: https://www.gigamon.com/campaigns/precryption.html


Gigamon products consistently creep me out. Pretty sure they’re mostly good to great, but they always make me think panopticon.


What is the use case for this? Learning more about how Android apps communicate with their home server?


Very useful for reverse engineering and security auditing of internal APIs. Particularly on Android a lot of apps pin CA certs or use their own trust store, so you have to do a little RE on them to insert your own cert... Or do it this way.


Unfortunately that requires root, and SDKs have gotten incredibly good at detecting root - not to mention SafetyNet Attestation.

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


> and DRM and whatnot can go and screw themselves

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.


My favorite benefit of DRM support has been that Firefox will prompt me "do you want to allow DRM content?" when I visit a news website. Ignoring that or clicking no auto-blocks all the autoplaying videos.


Indeed, I love this feature of Firefox. There's something that feels so damn good about saying "No" to DRM content. If only there was a way to tell the website that the content was blocked due to DRM...


The web is finally catching up with where it was in the Flash days.


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

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.


Yeah then make a Secure Enclave application for that. But ffs I am sick and tired of playing cat and mouse with every random app that whines about my phone being rooted.

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.


Inspecting what apps are sending out when they don't want you to see


Just today I thought about a hypothetical strace analog for web requests. Something that could trace all the HTTPS requests a program makes without playing around with certificates.


You can already do this with eBPF.


Interception for regulated companies. Banks have to keep a log of all communication between their employees.

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.


TLS 1.3 and ESNI (now called Encrypted Client Hello - ECH) are separate standards, although you'll see ECH only enabled in bleeding edge stacks. In fact, ECH is still in IETF draft phase [1].

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


Ah, i didn't know they actually moved eSNI out of TLS1.3. it was certainly part of quite a few drafts.

I do find it sad it isn't pushed harder. Companies who need to do interception have legitimate concerns, but they can be addressed.


In which country is this ? In France the law is pretty clear :

> 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


This can be tackled by excempting certain domains from decryption, which is actually part of why eSNI is a challenge for companies who do this kind of decryption on their own computers.


For regulated firms like the French one I’m at, checking personal email on work devices and the like is simply blocked.

If you want to check your private email, you can just use your personal device.


If you need to work with PII in bank, personal communication on work computer is simply prohibited.


Not sure if this supports TLS3 / perfect forward secrecy. If not lmk, I've written similar code to decrypt PFS in a pcap compatible way.

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 ;)


Half-OT

Is there any way to account a response of a TLS enabled server to it's public key?

Something like reverse fingerprinting?


Do you mean that you can prove to a third party that a TLS transcript is accurate? Then the answer is no. TLS authenticates application data with a symmetric algorithm based on a negotiated secret. To verify authenticity, you need to disclose that secret, but you can also use the secret to authenticate a made-up application data stream. I think it's still possible to prove that a decryption is correct if everyone agrees that the ciphertext is genuine, but that's the extent of it.


It is technically possible to verify the authenticity of a TLS transcript without disclosing the secret key. You would need a zero knowledge proof. Where you prove that you know a key that is consistent with the TLS handshake and that is consistent with the symmetric part of TLS.

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?


See https://eprint.iacr.org/2023/1022. Not only is it implemented, it is reasonably efficient (e.g., on the order of a couple seconds)


This seems to be the other direction. I assume the question was about extracting a cryptographic proof from a TLS session that (say) a bank statement downloaded over HTTPS (in HTML, no API) has not been tampered with. I really doubt this is possible, and quite a few TLS users would treat such an unexpected non-repudiation property as a vulnerability in TLS.


The TLS session, and the 'secret inputs' to the TLS handshake, will always give proof that the received message originated from a TLS session from someone who held the private key to the used certificate. Or from someone who received a session key from that private key holder.

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.


Yes, as far as I understood DH, the symmetrical keys don't have any mathematicial relation to the asymmetrical ones.

I guess, the only reliable way is to sign the response, which requires changes to the server


What do you mean? The asymmetric ephemeral keys used in a TLS handhake with Diffie Helman result rather directly into the symmetric session key used by TLS. The signature of the handshake with the certificate links the ephemeral keys to the certificate, and hence the symmetric session key is linked mathematically to the certificate.


What I wanted to say is, the session key isn't generated from the private keys of either party.

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.


That's what I meant with a common understanding of what the ciphertext is.

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.


A few days, I read that someone claims to do that.

But there was no background info. Just "We use ZKP to prove we got the right data"

So, it's technically possible?


I feared so, thanks.

I was hoping responses were signed.



have a look at this https://tlsnotary.org/


This is one of those things I think should be wrapped up and made more capable for the typical Linux user (so, more like a typical HN user I suppose).

Because IMO, what my PC is doing and sending over the network at all times should be inspectable by me, on that computer.


Have you seen OpenSnitch? https://github.com/evilsocket/opensnitch

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.


What is the point of eBPF? It seems like it can really do anything


I've not used it in anger, so take it with a grain of salt.

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.


Maybe you could do this with HTTPS if you’re using Kernel TLS offloading?


Yes, if the server uses kTLS, it'll be easy for such a probe to get the plaintext, because the syscalls themselves will contain the plaintext. It won't have to do TLS library-specific shenanigans to hook userspace functions or extract the key material like this submission does.


You can instrument userland binaries with eBPF, so as long as you have probes built for the TLS library your target is using, you're fine.


Deep instrumentation of running binaries, especially the kernel, and packet manipulation.


Let’s not forget syscall filtering. Using custom eBPF for what is in effect a syscall firewall is something my coworkers did for one of our clients and it’s really slick. It’s like super seccomp.


It is guaranteed to terminate execution, making it Possible to run in the Kernel without threat of an indefinite hang.


Not sure why it mentions or needs eBPF or anything kernel-side; this is already possible with just OpenSSL/etc. shim libraries.


They mention golang, which uses static binaries, meaning you can't LD_PRELOAD it.


Aren't there cases where shim libraries/LD_PRELOAD won't work, like statically linked binaries?

So if this works there it might be useful in, for example, analyzing encrypted video traffic for some video games.


You don't have to modify or restart any applications, it works globally and at runtime without interrupting existing processes.


> Note: Need ROOT permission.




nice one comment thread.


Zero comment thread, since the only comment was the submitter. That was my point.

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


More likely I think, the reason it got no comments was that even great stuff only has about a 20% chance (or worse) of getting traction before it falls off. I love HN, but I see a lot of great posts that never get their signal through the noise.


It doesn't look like they phrased it as being a vulnerability. It's just a useful tool.


Note to Linus: We have to be able to compile out this eBPF kernel config option, like completely.


Note that despite the headline, the feature actually used here is kprobe and uprobe (which use eBPF to collect data using eBPF every time an event, such as passing a certain point in code, is executed - allowing for hooking of functions and extraction of data). You can turn them off with CONFIG_KPROBE_EVENTS=n and CONFIG_UPROBE_EVENTS=n.

That said, there are other ways to do similar probing: - Loading kernel modules. - Using ptrace. - Using LD_PRELOAD against a dynamic binary.


Right; disabling eBPF doesn't solve this. And the bigger point is that this kind of eBPF is still super-user only.

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.


Libmusl will drop your LD_PRELOAD nicely.

And modules can be compiled directly into a module-less kernel.


I believe that's CONFIG_BPF


It gets flipped on under most settings if you try to disable it, notably by nftables.


If eBPF is disabled you can use other debugging facilities.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: