[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)