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

Show HN: Spliff – Correlating XDP and TLS via eBPF (Building a Linux EDR)

github.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Show HN: Spliff – Correlating XDP and TLS via eBPF (Building a Linux EDR)

#11

Post by spliffedr »

metmac wrote: post #9

Just came here to say this is awesome to see more folks do novel stuff with XDP! After reading loophole labs post [0] a few months ago. I was hoping someone would cook on this for security research. [0] https://loopholelabs.io/blog/xdp-for-egress-traffic

I think (not 100% sure) Cillium [0][1] kinda already does this. This loophole is good for packet processing/routing and even introducing XDP based ACL to bypass any ip/nf tables and get that almost wire speed benefit. I use Cilium with these features for custom made k8s clusters with Talos OS without any kube-proxy.

[0]https://docs.cilium.io/en/stable/operations/performance/tuni...

[1]https://isovalent.com/blog/post/cilium-netkit-a-new-containe...

Re: Show HN: Spliff – Correlating XDP and TLS via eBPF (Building a Linux EDR)

#12

Post by spliffedr »

westurner wrote: post #10
spliffedr wrote: post #8

Earlier quoted context omitted.

I've updated the Architecture diagrams to include everything: https://github.com/NoFear0411/spliff/blob/main/README.md#arc... Thanks for the format tip.

So I went looking for TLS accelerator cards again: /? TLS accelerators open: https://www.google.com/search?q=TLS+accelerators+open : - "AsyncGBP+: Bridging SSL/TLS and Heterogeneous Computing with GPU-Based Providers" https://ieeexplore.ieee.org/document/10713226 .. https://news.ycombinator.com/item?id=46664295 /? XDP hardware offload to GPU: https://www.google.com/search?q=XDP+hardware+offload+to+a+GP... : - eunomia…

That is a rabbit hole that I don't wanna go down to again.

Re: Show HN: Spliff – Correlating XDP and TLS via eBPF (Building a Linux EDR)

#13

Post by spliffedr »

ironbound wrote: post #3

This is super cool, I always wanted a system to peak App packets before encryption gets applied.

Give it a test and let me know if you encounter any issues. Except the chrome/chromium with static binaries, that have BoringSSL shipped inside. The entire SSL/TLS code flow is a motherfucking spaghetti to provide acceleration and fast page loads. They even offload to system OpenSSL lib for some TLS parts and even with debug symbols (not you google that doesn't include them in repo) it is a headache to trace it

Re: Show HN: Spliff – Correlating XDP and TLS via eBPF (Building a Linux EDR)

#14

Post by shivanshvij »

spliffedr wrote: post #11
metmac wrote: post #9

Just came here to say this is awesome to see more folks do novel stuff with XDP! After reading loophole labs post [0] a few months ago. I was hoping someone would cook on this for security research. [0] https://loopholelabs.io/blog/xdp-for-egress-traffic

I think (not 100% sure) Cillium [0][1] kinda already does this. This loophole is good for packet processing/routing and even introducing XDP based ACL to bypass any ip/nf tables and get that almost wire speed benefit. I use Cilium with these features for custom made k8s clusters with Talos OS without any kube-proxy. [0] https://docs.cilium.io/en/stable/operations/performance/tuni... [1] https://isovalent.com/blog/pos…

Founder of loophole labs here!

Cilium is definitely the gold standard if you’re working with Kubernetes clusters and need a full CNI, but if you want to extend CNI functionality without replacing it, then this approach is the only option.

It works quite well because Cillium (and all CNIs that I’m aware of) don’t use XDP like the blog post mentions, they use Netkit instead which is an alternative to veth designed for netfilter-like use cases.

This means XDP can work alongside Cillium (with enough tweaking) which is what we wanted to be able to do.

If you’re using pure containers and no CNI, then of course this provides a significant speed up even beyond netkit devices.

Re: Show HN: Spliff – Correlating XDP and TLS via eBPF (Building a Linux EDR)

#15

Post by spliffedr »

shivanshvij wrote: post #14
spliffedr wrote: post #11

Earlier quoted context omitted.

I think (not 100% sure) Cillium [0][1] kinda already does this. This loophole is good for packet processing/routing and even introducing XDP based ACL to bypass any ip/nf tables and get that almost wire speed benefit. I use Cilium with these features for custom made k8s clusters with Talos OS without any kube-proxy. [0] https://docs.cilium.io/en/stable/operations/performance/tuni... [1] https://isovalent.com/blog/pos…

Founder of loophole labs here! Cilium is definitely the gold standard if you’re working with Kubernetes clusters and need a full CNI, but if you want to extend CNI functionality without replacing it, then this approach is the only option. It works quite well because Cillium (and all CNIs that I’m aware of) don’t use XDP like the blog post mentions, they use Netkit instead which is an alternative to veth designed for…

It is nice to see people thinking and working on low level networking stuff that everyone will benefit. I think even single node clusters/container hosts will benefit a lot from XDP loophole. I'll keep an eye on it.
Post reply on HN