Hi everyone, I’ve been trying to understand how MiTM setups like a transparent proxy work.

Obviously, the use-case here is in a personal scope: I’d like to inspect the traffic of some of my machines. I am aware that Squid can be a transparent proxy, and some might use the Burp Suite to analyse network traffic.

Could someone explain the basic networking and the concept of certificates in this scenario? I feel like I don’t understand how certificates are used well enough.


For example: I realise that if someone inserts a root certificate in the certificate store of an OS, the machine trusts said CA, thus allowing encrypted traffic from the machine to be decrypted. However, say the machine was trying to access Amazon; won’t Amazon have its own certificate? I don’t know how I’m confused about such a simple matter. Would really appreciate your help!

  • MigratingtoLemmy@lemmy.worldOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    the proxy sends a cert to the client saying ‘I’m Amazon’, and the client believes it

    Thanks, could you explain this a bit more? I didn’t understand what you mean by “sends a cert saying ‘I’m Amazon’”

    • Monkey With A Shell@lemmy.socdojo.com
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      11 months ago

      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 preloaded 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.worldOP
        link
        fedilink
        English
        arrow-up
        3
        ·
        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
          link
          fedilink
          English
          arrow-up
          4
          ·
          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.

            • stifle867@programming.dev
              link
              fedilink
              English
              arrow-up
              2
              ·
              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.

    • SheeEttin@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      11 months ago

      That’s literally it. It sends a cert for amazon.com, that your client trusts, because the CA cert used to sign it is in your trusted store.

      • MigratingtoLemmy@lemmy.worldOP
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 months ago

        I see, thanks for the explanation. Amazon sends the certificate to the proxy, and the proxy sends its own certificate, masquerading as amazon, to the user.

        Thanks

        • canni@lemmy.one
          link
          fedilink
          English
          arrow-up
          2
          ·
          11 months ago

          I think it’s important to understand how a typical SSL certificate is generated. Basically, there are a handful of companies that we have all agreeded to trust. When you download Chrome it comes with a set of trusted root certificates, so does your OS, etc. So when Amazon wants to create an SSL for amazon.com, the only way they can do that is by contacting one of those handful of trusted companies and getting them to issue a certificate that’s says Amazon.com. When you go to the site, you see a trusted party generated the cert and your browser is happy.

          When you create a new root certificate and install it on your computer, you become one of those companies. So now, you can intercept traffic, decrypt it, read it, reissue a certificate for amazon.com (the same way Amazon would have gotten one from the third parties), reencrypt it, and pass it along to the client. Because the client trusts you it’s still a valid certificate. But if you inspect the certificate on the client side the root signer will no longer be GoDaddy or whatever, it will be you.

        • losttourist@kbin.social
          link
          fedilink
          arrow-up
          2
          ·
          11 months ago

          Yes, I think that ‘masquerading’ is the key bit to grasp. The MITM Proxy isn’t just intercepting the traffic, it alters the traffic as it passes through.