5 ms·

> What I want is Little Snitch on steroids built into the OS where every process, including all native ones, including UI apps, are blocked from network connec

> What I want is Little Snitch on steroids built into the OS where every process, including all native ones, including UI apps, are blocked from network connectivity by default, and the user gets an easy monitor of outgoing traffic with TLS/SSL inspection built in (you'd need some OS API to enable that). If you want to you can do that with Linux. Sure you'd need to use the CLI, and a combination of tools but you can pinpoint every packet to an associated process and if you add your self made cert to trusted certs, then you can decrypt TLS as well in most cases.

twawaaay 4y ago
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.
- kibwen 4y ago
  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.
  - twawaaay 4y ago
    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?
    - kibwen 4y ago
      I am specifically referring to the ability to have the same sort of interface with non-webapps as we do with webapps.
    - NietzscheanNull 4y ago
      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.
dathinab 4y ago
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.
- return_to_monke 4y ago
  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.
- IceWreck 4y ago
  > 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.

twawaaay 4y ago

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.

kibwen 4y ago
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.
- twawaaay 4y ago
  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?
  - kibwen 4y ago
    I am specifically referring to the ability to have the same sort of interface with non-webapps as we do with webapps.
  - NietzscheanNull 4y ago
    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.

dathinab 4y ago

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.

return_to_monke 4y ago
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.
IceWreck 4y ago
> 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.