Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keylog capture not working with OpenSSL 1.1.0 #533

Closed
AmazingPP opened this issue Apr 28, 2024 · 3 comments · Fixed by #534
Closed

Keylog capture not working with OpenSSL 1.1.0 #533

AmazingPP opened this issue Apr 28, 2024 · 3 comments · Fixed by #534
Labels
good first issue Good for newcomers invalid This doesn't seem right

Comments

@AmazingPP
Copy link
Contributor

Describe the bug

When using the ecapture tool with OpenSSL 1.1.0 to capture keylog data with the -m keylog option, no output is generated.

To Reproduce

Steps to reproduce the behavior:


  1. Clone the ecapture repository using git clone https://github.com/gojue/ecapture.git
  2. Compile OpenSSL 1.1.0a from source and install it in /opt/openssl
  3. Compile curl with the provided OpenSSL 1.1.0 library
  4. Start ecapture in text mode to capture TLS traffic using sudo ./bin/ecapture tls --libssl=/opt/openssl/lib/libssl.so.1.1
  5. Initiate an HTTPS request using a tool compiled against the same OpenSSL 1.1.0 library (e.g., curl)
  6. Observe that the decrypted TLS traffic is correctly captured and displayed
  7. Stop the ecapture process
  8. Attempt to capture keylog data using sudo ./bin/ecapture tls -m keylog -k ecapture.txt --libssl=/opt/openssl/lib/libssl.so.1.1
  9. No output is generated in the ecapture.txt file
    

Expected behavior

When using the -m keylog option with OpenSSL 1.1.0, ecapture should capture and output keylog data to the specified file (ecapture.txt in this case).


Screenshots

I cannot provide screenshots directly, but here is the relevant output from the terminal:


$ sudo ./bin/ecapture tls --libssl=/opt/openssl/lib/libssl.so.1.1
# ... TLS decryption output ...

$ sudo ./bin/ecapture tls -m keylog -k ecapture.txt --libssl=/opt/openssl/lib/libssl.so.1.1
# No output in ecapture.txt


Linux Server:


  • OS: Ubuntu 20.04.6 LTS
  • Arch: x86_64
  • Kernel Version: 5.4.0-176-generic
  • Version: a8acece
    

Additional context

This issue seems to be specific to the OpenSSL 1.1.0 version. I have tried reproducing this issue on multiple Linux distributions and kernel versions, and the behavior is consistent with OpenSSL 1.1.0. It seems that the keylog capture functionality is not working as expected with this particular OpenSSL version, despite TLS decryption working correctly. I would appreciate if this issue could be investigated and resolved for OpenSSL 1.1.0 compatibility.

@AmazingPP
Copy link
Contributor Author

The issue seems to be related to the incorrect assignment of the OpenSSL offset for OpenSSL 1.1.0 in the probe_openssl_lib.go file.

m.sslVersionBpfMap["openssl 1.1.0"+string(ch)] = "openssl_1_1_1a_kern.o"

After correcting the file assignment, the keylog capture starts working, but the captured data appears to be incorrect.

@cfc4n cfc4n added good first issue Good for newcomers invalid This doesn't seem right labels Apr 28, 2024
AmazingPP added a commit to AmazingPP/ecapture that referenced this issue Apr 28, 2024
the problem was the `client_random` member having different offsets within the `ssl3_state_st`
structure across various OpenSSL versions

Fixes gojue#533
@cfc4n
Copy link
Member

cfc4n commented Apr 28, 2024

Can text mode work?

@AmazingPP
Copy link
Contributor Author

Can text mode work?

Yes, the text mode works normally.

cfc4n pushed a commit that referenced this issue Apr 29, 2024
* user : fixed the incorrect assignment of the OpenSSL offset for OpenSSL 1.1.0

* kern: fix incorrect client_random capture for different OpenSSL versions

the problem was the `client_random` member having different offsets within the `ssl3_state_st`
structure across various OpenSSL versions

Fixes #533
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers invalid This doesn't seem right
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants