aboutsummaryrefslogtreecommitdiff
path: root/tests/sshhelp.pm
diff options
context:
space:
mode:
authorPeter Wu <peter@lekensteyn.nl>2020-05-03 17:10:40 +0200
committerPeter Wu <peter@lekensteyn.nl>2020-05-27 21:19:51 +0200
commit6011a986ca3a4c162eb0daf9204fa5ddbc20a86e (patch)
treea2f069f852e199522cf52943e79c9d7c2ce95890 /tests/sshhelp.pm
parentd528d975639986e10450706f1b523ff49f30e4e4 (diff)
vtls: Extract and simplify key log file handling from OpenSSL
Create a set of routines for TLS key log file handling to enable reuse with other TLS backends. Simplify the OpenSSL backend as follows: - Drop the ENABLE_SSLKEYLOGFILE macro as it is unconditionally enabled. - Do not perform dynamic memory allocation when preparing a log entry. Unless the TLS specifications change we can suffice with a reasonable fixed-size buffer. - Simplify state tracking when SSL_CTX_set_keylog_callback is unavailable. My original sslkeylog.c code included this tracking in order to handle multiple calls to SSL_connect and detect new keys after renegotiation (via SSL_read/SSL_write). For curl however we can be sure that a single master secret eventually becomes available after SSL_connect, so a simple flag is sufficient. An alternative to the flag is examining SSL_state(), but this seems more complex and is not pursued. Capturing keys after server renegotiation was already unsupported in curl and remains unsupported. Tested with curl built against OpenSSL 0.9.8zh, 1.0.2u, and 1.1.1f (`SSLKEYLOGFILE=keys.txt curl -vkso /dev/null https://localhost:4433`) against an OpenSSL 1.1.1f server configured with: # Force non-TLSv1.3, use TLSv1.0 since 0.9.8 fails with 1.1 or 1.2 openssl s_server -www -tls1 # Likewise, but fail the server handshake. openssl s_server -www -tls1 -Verify 2 # TLS 1.3 test. No need to test the failing server handshake. openssl s_server -www -tls1_3 Verify that all secrets (1 for TLS 1.0, 4 for TLS 1.3) are correctly written using Wireshark. For the first and third case, expect four matches per connection (decrypted Server Finished, Client Finished, HTTP Request, HTTP Response). For the second case where the handshake fails, expect a decrypted Server Finished only. tshark -i lo -pf tcp -otls.keylog_file:keys.txt -Tfields \ -eframe.number -eframe.time -etcp.stream -e_ws.col.Info \ -dtls.port==4433,http -ohttp.desegment_body:FALSE \ -Y 'tls.handshake.verify_data or http' A single connection can easily be identified via the `tcp.stream` field.
Diffstat (limited to 'tests/sshhelp.pm')
0 files changed, 0 insertions, 0 deletions