[HN Gopher] When eBPF meets TLS. Defeating TLS encryption with e... ___________________________________________________________________ When eBPF meets TLS. Defeating TLS encryption with eBPF tricks [pdf] Author : guedou Score : 33 points Date : 2022-05-20 20:45 UTC (2 hours ago) (HTM) web link (github.com) (TXT) w3m dump (github.com) | antmldr wrote: | Great presentation. Any thoughts on including these tricks | directly into wireshark to allow fluid decryption at least on the | Linux client where CAP_BPF is present? | [deleted] | tptacek wrote: | Just to clarify what this is probably about, for people who don't | do security research (that's what Quarkslab does) --- this is | mostly valuable information for people who need to instrument | apps under test to see what they're doing. | | Locked-down TLS is a pain for testers, because, of course, the | whole idea is preventing third parties from seeing plaintext. But | that's what app testers need to do (usually, to get enough | information to write their own tooling-grade clients and servers | to use to probe vulnerabilities with). There's a bunch of | different tools people use for this purpose; Frida is probably | the best-known example, for mobile and native clients. | | But if your target under test is Linux, modern eBPF gives you | enough tooling to capture plaintext without directly | instrumenting binaries, which is handy. | | This isn't, like, per se a vulnerability; they're not saying it | is. | otterley wrote: | If you have root access to a host, it's pretty much game over, | unless the OS vendor doesn't trust even the owner of the | hardware/licensee of the software and has taken effective | countermeasures against diving deep into the software (Linux, of | course, has not). You don't need "eBPF tricks" to observe | processes on the host perform traffic decryption. It's just | another mechanism for doing so. | | I wouldn't characterize it as "defeating TLS encryption" either, | because it's not like you're decrypting traffic someplace other | than on the host you already have privileged access to (and | assuming you already have MITM capability, which is by no means | assured). | throwaway_95283 wrote: | It's not quite that simple. | | In theory yes, once you have root it's "game over", however, if | you want to decrypt it to something usable / readable it's a | lot more involved. A modern stack looks like TLS decrypt + | HTTP2 / HTTP3 decode. | | HTTP1 / TLSv1.2 is relatively easy, HTTP2 or 3 + TLSv1.3 is far | more difficult. It will take a few weeks at least to get it all | working. | | Plus you're going to need the right struct offsets for each | OpenSSL / etc library, and a detection mechanism to find out | which offsets to use for that process. | | There are *a lot* of gotchas in this process. | zokier wrote: | > "defeating TLS encryption" | | I do point out that is editorializing on submitters part, the | actual subtitle is "A security focused introduction to eBPF", | which is much more descriptive of the content | antmldr wrote: | Being at the author's talk earlier today, that wasn't really | the spirit that it was given in. The author isn't really | talking about "defeating" TLS as a technical control more as he | is talking about "defeating" it as an annoyance when reverse | engineering. | | It's meant more as a showcase of how eBPF can be applied to a | technical challenge, as opposed to the author claiming they | fundamentally broke TLS. ___________________________________________________________________ (page generated 2022-05-20 23:00 UTC)