Nah, you can't. The issue is the "easy monitor outgoing traffic with TLS/SSL" part.

It is not impossible but it is far from easy. If the application uses statically linked SSL client (as it should if it is commercially distributed) then you have to modify the application (for example in memory) to get a copy of everything that gets written to the SSL stream.

You know how you can do Ctrl+Shift+K in Firefox to open up the browser console and inspect all the bits of the page, see the code (and fuck with it), see all the network traffic, and so on? I dream of being able to do that for arbitrary applications. Imagine having a Super+Ctrl+Shift+K that opened an OS-level GUI showing all the pertinent details of the running program.

You know that this only pertains to webapps and there is still a lot of software running on your machine that you have no idea what it does?

I believe the parent commenter is aware of that - they’re describing their wish for a tool that makes monitoring native application requests easy and transparent, similar to the experience of using browser devtools with web apps.

I am specifically referring to the ability to have the same sort of interface with non-webapps as we do with webapps.

Not quite.

For this to work well, all your apps need to run with not being able to do their own TLS, but to various (reasonable) reasons a lot of applications today do their own TLS.

You also don't want to add self-signed certificates, but grab the traffic _before_ it gets encrypted IMHO.

In some cases it's still quite viable, like if they dynamic link to OpenSSL (or similar) you could create a facade which allows grabbing traffic.

But things get problematic when it's statically compiled in and not open source.

Additionally there are quite a bunch of use-cases where the encryption is not TLS, like e.g. with some WebRTC applications it's not uncommon to have an encrypted channel we could access to a broker server but in that channel E2E encrypted messages are send e.g. using libsodium statically compiled in.

> You also don't want to add self-signed certificates, but grab the traffic _before_ it gets encrypted IMHO.

that would be ideal but self signed + added to trusted store works

> Additionally there are quite a bunch of use-cases where the encryption is not TLS, like e.g. with some WebRTC applications it's not uncommon to have an encrypted channel we could access to a broker server but in that channel E2E encrypted messages are send e.g. using libsodium statically compiled in.

yeah youre right.

In other cases the only options we have are ld_preload to catch encryption lib. If that doesnt work we can still use ptrace to capture syscalls but encryption will be done in userspace so capturing network activity wont help us with encryption.

Like the other guy said, the info we can gather is still useful.

Reverse engineering + modyfing the binary is a possibility too but it gets complicated fast, especially if they intentionally try to protect it. I feel this isnt really an issue with jvm or interpreted langauges but with the others its hard especially if theyre statically linked. C/C++ have good enough decompilers that its still possible, I don't know about Go/Rust tho.

While i partially agree, even DNS query/http headers (I'm not sure if that is encrypted with ssl?) Could be useful here. Told the software not to connect to cloud, still connects to cloud. Enough reason to complain.