A decrypting proxy acts like a local certificate authority and issues a certificate on behalf of the site to create one encrypted connection between the client and proxy while creating a second on with the original site on the other side.
The client will get an error (or depending on the site and browser may refuse to connect at all in the case of pinned and pteloaded certificates) indicating that they’re connecting to a site with a certificate from an untrusted issued unless they’ve been configured to trust the CA held on the proxy.
The ‘break’ between the client side connection and the server side connection will be in plaintext and can be examined through internal tools or sent to external ones typically through ICAP.
MigratingtoLemmy@lemmy.world 11 months ago
I see. Which would mean that in cases where the application/OS can be made to blindly trust the “fake” CA (by inserting a root certificate into the certificate store, like in Android), the proxy can simply send the certificate and the client will believe that the certificate comes from Amazon. The certificate list can be refreshed by flushing the cache, yes?
Thanks for the explanation
stifle867@programming.dev 11 months ago
There are some cases where this would not work by the way. It’s called certificate pinning and it’s basically when an application comes with the trusted certificate for a host built-in. Even if you were to override it with a root certificate in the certificate store, the app simply wouldn’t use it.
MigratingtoLemmy@lemmy.world 11 months ago
Shouldn’t flushing the cache mitigate this problem?
stifle867@programming.dev 11 months ago
No, not at all. The request never hits the cache. The certificate is stored within the app and all internet communication is specifically pinned to said certificate. It doesn’t even ask your certificate store.
ShellMonkey@lemmy.socdojo.com 11 months ago
That’s the sum of it. Like others and I have noted some mobile apps (and Apple phones in particular have their entire OS configured to not trust any intercepted certs when attempting to speak to Apple home base) are prone to using certificate pinning and will reject the intercepted certs regardless of the trust store. It’s mostly beneficial for adjusting the browser.
If I might ask, what’s the purpose of this proxy? Functionally there are a lot simpler and more efficient ways to block traffic from a phone. If it’s more for traffic inspection I’ve seen a couple VPN based pcap apps for Android that could get a lot more detail while a DNS filter could both control and give visibility to traffic from the device without all the cert hassles.
MigratingtoLemmy@lemmy.world 11 months ago
Thanks, I didn’t realise that certificate pinning was this strict.
This effort is to check if my mobile has a baseband processor that might be communicating with the internet. I want to know if my device has a backdoor in hardware. The idea with a VPN has me intrigued, could you tell me more about that?
ShellMonkey@lemmy.socdojo.com 11 months ago
play.google.com/store/apps/details?id=app.greyshi…
Something like that should ship all traffic through a local VPN adapter and output a standard pcap file.
Another option if you have a bit more fancy networking available is to set up a security onion instance, then mirror a port on the network and just capture everything at an on-wire level. That would also cover things beyond just web traffic to catch other things like ssh or whatever other remote connectivity could be in play. Seeing the content of the connection is different than just seeing the connections existence though. The endpoint generally has the best visibility before data gets pushed into a a connection but unless you start getting into kernel level debugging it can still be hard to see into the behavior of internal applications.