Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Using eBPF to see through encryption without a proxy

github.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Show HN: Using eBPF to see through encryption without a proxy

#41

Post by 0xCE0 »

jonfriesen wrote: post #30
captainbland wrote: post #25

Earlier quoted context omitted.

What's the recommended way of locking down communications for this application? With a MITM based solution it's fairly clear you can lock its egress down to precisely what it needs at the network policy level at least, whereas it's a bit trickier with this as it necessarily shares an instance with other processes. Is uploading clear text encrypted in flight data to another system even a good idea in most cases? In so…

You've definitely hit on a point that we've talked about at length and have come to terms that different organizations have different requirements, especially when it comes to regulatory and compliance. Qtap can be locked down with local firewalls or perimeter firewalls like other applications running within a network. The TLS inspection can also be disabled with a `--tls-probes=none` flag on startup. Even without in…

Your writing style reminds LLM for some reason.

Re: Show HN: Using eBPF to see through encryption without a proxy

#43

Post by delusional »

jonfriesen wrote: post #34
delusional wrote: post #31

What does the usage pattern look like for this. Will I need to be root to run it, and can it run from inside a container without "real" host root? I'm always looking for a way to make sniffing traffic from inside a container easier, and if I could attach a debug sidecar with something like an eBPF based SSL pre-master key extractor (both on incoming and outgoing requests) it starts to feel a lot like having network J…

Qtap does require root privileges to function as it uses eBPF to hook into kernel and userspace program functions. The good news is it can also be run within a container. There are some important flags when spinning it up in docker: `--privileged`, `--cap-add CAP_BPF`, `--cap-add CAP_SYS_ADMIN`, and `--pid=host`. These provide access to load eBPF programs, and monitor traffic. Many deployments use Kubernetes daemonse…

I'm honestly not that interested in constant logging or central collection. I think it's a perfectly useful product, but I find it hard to get buy in for that sort of system in the short term.

Supposedly `kubectl debug` does allow you to set a `sysadmin` profile and grant the debug sidecar `privileged` access. I think that would be a neat low cost way to get value out of your product quickly, right when I have an issue, which would maybe help build some organizational trust and goodwill to make the rest of the stack easier to buy.

It would also solve an issue for me that I would really like solving :P

Re: Show HN: Using eBPF to see through encryption without a proxy

#45

Post by chatmasta »

tylerflint wrote: post #8
bbkane wrote: post #3

Does this work for Go binaries? My understanding is that Go programs do all the encryption "in the process" so the data is encrypted before eBPF can intercept it. I'd love to be wrong about that!

We have Go support, but it is not open sourced yet. Go is a bit more complicated but we were able to get it after some cave diving in the ELF formats. To give you a little insight on how this works, because Go is statically linked, we need to pull several different offsets of the functions we are going to hook into. We do this by scanning every version of Go that is released to find offsets in the standard library th…

Great approach. I love the choice of practicality over generalization.

Are these offsets consistent across compilation targets, and they vary only by version of the Go binary? Or do you need to do this scan for every architecture?

Re: Show HN: Using eBPF to see through encryption without a proxy

#46

Post by chatmasta »

jonfriesen wrote: post #30
captainbland wrote: post #25

Earlier quoted context omitted.

What's the recommended way of locking down communications for this application? With a MITM based solution it's fairly clear you can lock its egress down to precisely what it needs at the network policy level at least, whereas it's a bit trickier with this as it necessarily shares an instance with other processes. Is uploading clear text encrypted in flight data to another system even a good idea in most cases? In so…

You've definitely hit on a point that we've talked about at length and have come to terms that different organizations have different requirements, especially when it comes to regulatory and compliance. Qtap can be locked down with local firewalls or perimeter firewalls like other applications running within a network. The TLS inspection can also be disabled with a `--tls-probes=none` flag on startup. Even without in…

I imagine one challenge you’ll face is how to keep it configurable and flexible prior to any data leaving the system. For example, you’d like to default to “intercept everything,” but also allow the user to define rulesets for which packets to ignore or include. That would be a nicer UX with an application-level tool, but at that point you’ve already exfiltrated the data they want to filter. So you’ll need a rules engine that can execute locally in the eBPF program, but now that program is becoming much more complicated.

Also worth noting this is very similar to the code path that got Crowdstrike in trouble when they crashed every device on the internet because of a bug in the parser of their rules engine.

Re: Show HN: Using eBPF to see through encryption without a proxy

#47

Post by tylerflint »

chatmasta wrote: post #45
tylerflint wrote: post #8

Earlier quoted context omitted.

We have Go support, but it is not open sourced yet. Go is a bit more complicated but we were able to get it after some cave diving in the ELF formats. To give you a little insight on how this works, because Go is statically linked, we need to pull several different offsets of the functions we are going to hook into. We do this by scanning every version of Go that is released to find offsets in the standard library th…

Great approach. I love the choice of practicality over generalization. Are these offsets consistent across compilation targets, and they vary only by version of the Go binary? Or do you need to do this scan for every architecture?

The short answer is that we only have to calculate the offset per go version, no expensive runtime scanning is required.

The long answer is that the offsets are the byte alignment offsets for the go structs containing the pointers to the file descriptor and buffers. Fortunately we only have to calculate these for each version where the TLS structs within go actually change, so not even for every version. For instance, if a field is added, removed, or changes type then the location in memory where those pointers will be found changes. We can then calculate the actual offset at runtime where we know which architecture (amd64, arm64, etc) with a simple calculation. Within the eBPF probe, when the function is called, it uses pointer arithmetic to extract the location of the file descriptor and buffer directly.

Re: Show HN: Using eBPF to see through encryption without a proxy

#50

Post by formerly_proven »

eptcyka wrote: post #27

I know that arguing that SSLKEYLOGFILE is all you need will just be a different version of the rsync/dropbox comment, but I do wonder under what circumstances is one able to strace a binary and isn’t able to make it dump session keys? I read the headline and set high hopes on finding a nifty way to mitm apps on Android - alas, I’m not sure this would work there necessarily.

Mostly that SSLKEYLOGFILE has only been an (disabled by default) OpenSSL feature for a few weeks (literally), apart from that it's something implemented by some other libraries (notably libcurl) on top. But it's very far from "just set this env var and the keys will pop out of any app using TLS".
Post reply on HN