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