Live data from Hacker News

What I learned by putting GitHub Copilot behind a MitM proxy

lighthousenewsletter.com

11–20 of 40 posts

Re: What I learned by putting GitHub Copilot behind a MitM proxy

#11
post #9

One thing I found that I thought was a fun addition, is using eBPF made this even easier. No need to fight with anyone that is using certificate pinning, mTLS or anything else, you just get the raw plaintext data straight of the wire (right before encryption and right after decryption) and works nicely for most of the agents and IDE's. That will in practice give you everything from telemetry to prompts, and its funny…

Out of curiosity: How?

They don't offload TLS to the kernel, do they? Most apps do it in userspace linked against openssl afaik.

Do you patch that lib? If ebpf "just" operates at network/packet level, I don't see how it can do more than Mitmproxy in regard to avoid DH-PFS/Pinning

Re: What I learned by putting GitHub Copilot behind a MitM proxy

#12
post #9

One thing I found that I thought was a fun addition, is using eBPF made this even easier. No need to fight with anyone that is using certificate pinning, mTLS or anything else, you just get the raw plaintext data straight of the wire (right before encryption and right after decryption) and works nicely for most of the agents and IDE's. That will in practice give you everything from telemetry to prompts, and its funny…

Surprised that works, I thought TLS was done entirely in process space.

I think I found it, My first thought was some sort of builtin ssl library backdoor, but it looks like you do some ld.preload shenanigans to inject a eBPF monitor. I am not sure exactly what the BPF brings to the table here. A convenient interface to intercept the accept() syscall?

Re: What I learned by putting GitHub Copilot behind a MitM proxy

#14
post #11
post #9

One thing I found that I thought was a fun addition, is using eBPF made this even easier. No need to fight with anyone that is using certificate pinning, mTLS or anything else, you just get the raw plaintext data straight of the wire (right before encryption and right after decryption) and works nicely for most of the agents and IDE's. That will in practice give you everything from telemetry to prompts, and its funny…

Out of curiosity: How? They don't offload TLS to the kernel, do they? Most apps do it in userspace linked against openssl afaik. Do you patch that lib? If ebpf "just" operates at network/packet level, I don't see how it can do more than Mitmproxy in regard to avoid DH-PFS/Pinning

eBPF started as a network tool, but (according to the creators of it) targeting the network was just a ploy to get a foot in the door so they could start expanding it to other things. They didn’t think the idea would be accepted if they tried to do it all at once. So now it works on many parts of the system, not just the network.

Re: What I learned by putting GitHub Copilot behind a MitM proxy

#16
post #11
post #9

One thing I found that I thought was a fun addition, is using eBPF made this even easier. No need to fight with anyone that is using certificate pinning, mTLS or anything else, you just get the raw plaintext data straight of the wire (right before encryption and right after decryption) and works nicely for most of the agents and IDE's. That will in practice give you everything from telemetry to prompts, and its funny…

Out of curiosity: How? They don't offload TLS to the kernel, do they? Most apps do it in userspace linked against openssl afaik. Do you patch that lib? If ebpf "just" operates at network/packet level, I don't see how it can do more than Mitmproxy in regard to avoid DH-PFS/Pinning

It’s done via uprobes which allows ebpf to attach to users processes or libraries, basically like ld_preload but built into the kernel. First link that explains it https://blog.quarkslab.com/defeating-ebpf-uprobe-monitoring.... but there are many more links about it and it is a pretty useful tool for debugging in prod environments. (Also first link: https://blog.px.dev/ebpf-function-tracing/) this also the intended use case. px.dev is btw a cncf project which also helps for ebpf debugging in k8s (comes from new relic)
Post reply on HN