Fix decrypting TLS 1.3 server response

There is at least one server that includes a new session ticket in the same packet as the Finished message. This confuses check_tls_serverhellodone() since the new session ticket is encrypted under the application traffic keys rather than the handshake keys. check_tls_serverhellodone(), being unable to decrypt the new session ticket, reports a failure and does not return any of the decrypted data.

This commit fixes the problem by having check_tls_serverhellodone() simply ignore any data that appears after the Finished message.
This commit is contained in:
David Cooper 2022-09-02 11:15:50 -07:00 committed by GitHub
parent bac8cb73f6
commit a8c8bfe7ea
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -11715,6 +11715,8 @@ check_tls_serverhellodone() {
decrypted_response+="${tls_content_type}0301$(printf "%04X" $((plaintext_len/2)))${plaintext:0:plaintext_len}"
if [[ "$tls_content_type" == 16 ]]; then
tls_handshake_ascii+="${plaintext:0:plaintext_len}"
# Data after the Finished message is encrypted under a different key.
[[ "${plaintext:0:2}" == 14 ]] && break
elif [[ "$tls_content_type" == 15 ]]; then
tls_alert_ascii+="${plaintext:0:plaintext_len}"
else