Yes, I think you have a couple of options here.
HTTPS is specifically designed to thwart "Man in the Middle" attacks and eavesdroppers, which is essentially what you are trying to achieve. You can break some of its assumptions though, and defeat it.
At the start of the SSL connection, 1. the remote server presents its public key and its cert, 2. the client verifies the cert and 3. sends a session key encrypted with the server's public key. For more details, see e.g. An overview of the SSL or TLS handshake
You have two possible ways to circumvent this protection, in the scenario you describe:
1. Rewrite the TLS data, replacing the server's cert and key with your own
Since you control the communications channel, you could substitute the server's public key & cert with one that you control, at step (1). If you then ask the client to skip step (2) using the
--no-check-certificate argument to
wget, you can then have full access to the encrypted data.
This is how the Fiddler debugging proxy allows access to HTTPS traffic, see https://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp
2. Retrieve the session key from the client application
Since the client app knows the session key, if you could extract it, you could then decrypt the stream. I think this is what you had in mind in the question.
wget itself has no options to allow logging the session key (see "HTTPS (SSL/TLS) Options"), but it does look like its TLS library, "
GnuTLS" has a debugging option that will do what you want, see "Debugging and auditing" in the GnuTLS docs:
SSLKEYLOGFILE When set to a filename, GnuTLS will append to it the session keys in the NSS Key Log format. That format can be read by wireshark and will allow decryption of the session for debugging.
Try setting the
SSLKEYLOGFILE environment variable to a filename, and see if
wget will then log your TLS session keys to that file? You might need to recompile
wget with a debug build of
GnuTLS. I haven't tried this myself.