0

Performing a local network man-in-the-middle (MitM) attack is fairly straightforward, especially when the traffic is unencrypted HTTP. There are other approaches to encrypted SSL/TLS HTTPS connections, such as using SSLStripper.

My question is, provided I own the HTTP certificate, for example to my own website, how could I MitM clients on my network to read their traffic? I would assume that since I own the certificate then decryption would be straight forward, unless they are using a VPN or similar privacy enhancing technology.

This could either be decrypted on the fly, or saved so I can decrypt it at a later date, either approach is fine.

EDIT: Assume I own the private key, sorry for ambiguity.

Improve this question
8
  • It's not really a man in the middle. If you own the certificate they're sending you their data. It's already decrypted on your end.
    – RoraΖ
    Apr 22, 2022 at 14:37
  • @RoraΖ Perhaps a better example would be if the SSL/TLS certificate was stolen from www.google.com, so the attacker cannot see the data at the end on Google's servers, but they do have the certificate so surely they could somehow use it to decrypt traffic...
    – questioner
    Apr 22, 2022 at 14:59
  • If you have a certificate for a site that the browser trusts, and you have the corresponding private key, then you can use a tool like sslsniff to MITM the connection to the site.
    – mti2935
    Apr 22, 2022 at 15:23
  • @mti2935 ./sslsniff -t -s <$listenPort> -w <$logFile> -m google.crt -c <$certDir> like this, provided the attacker somehow obtained google's cert which is unlikely.
    – questioner
    Apr 22, 2022 at 16:15
  • @questioner That looks right. FWIW, anyone can download Google's cert (see serverfault.com/questions/139728/…). The hard part is getting Google's private key.
    – mti2935
    Apr 22, 2022 at 16:24

1 Answer 1

Reset to default
1

This could either be decrypted on the fly, or saved so I can decrypt it at a later date, either approach is fine.

You're gonna have to go with decrypted on the fly. The certificate + private key is not enough information to store-and-decrypt-later. The reason is that (modern) TLS certificates are authentication / signature certificates which is an independent step of the TLS handshake from the key exchange that establishes the session encryption keys. This is a property known as perfect forward secrecy.

You'll need to do this:

  • Set up a proxy that uses the victim server's certificate + priv key.
  • Manipulate the network so that the victim user's traffic flows through the proxy.
    • Note that the client needs to think it's talking to the real server's hostname, otherwise the cert hostname SAN check will fail. So this needs to be a TCP or IP level manipulation, like a hostfile entry pointing server.com to the IP of the proxy, or a DNS poisoning so that server.com resolves to the IP of the proxy, or an ARP / BGP attack so that the proxy advertizes itself as a low-cost router / gateway for routing traffic to server.com's IP.

Tools-wise with what comes in Kali, you could consider a setup like this:

client --1:tls--> Kali[ncat1--2:non-tls--> ncat2] --3:tls--> server.com

where you put the server's cert and priv key on ncat1, and use wireshark to inspect link 2.

Improve this answer
2
  • I appreciate your answer, but would it perhaps be easier to do this: ./sslsniff -t -s <$listenPort> -w <$logFile> -m google.crt -c <$certDir> where the $certDir has the private key of, in this example, Google.
    – questioner
    Apr 22, 2022 at 19:28
  • @questioner Dunno, I've never used sslsniff before.
    – Mike Ounsworth
    Apr 23, 2022 at 0:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .