Skip to main content

Return to Answer

Bounty Awarded with 200 reputation awarded by halfer
deleted 9 characters in body
Source Link
Rich
Rich
  • 15.5k
  • 3
  • 73
  • 126

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

However, sinceSince 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.

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

However, 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.

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.

Source Link
Rich
Rich
  • 15.5k
  • 3
  • 73
  • 126

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

However, 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.