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.
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.