Add handling of fragmented TLS records to the TLS library #194
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Implement handling of messages fragmented across multiple TLSPlaintext records. As described in RFC 2246 (Section 6.2.1), client message boundaries are not preserved across TLSPlaintext records, which have a size limit of 16KB. As a result, handshake messages can straddle multiple TLSPlaintext records, for example, when a server sends a Certificate message with a long certificate chain. Currently, the TLS library's behavior in this case is to ignore the incomplete message fragment in the first TLSPlaintext record, and causes a crash when trying to parse the incomplete message fragment at the beginning of the second TLSPlaintext record.
This patch implements support for message fragmentation by adding a 'fragment' parameter to the record_read() function in the TLS library. This parameter is used to pass a fragment from a previously read TLSPlaintext record and prepend it to the next TLSPlaintext record to be read.
When a TLSPlaintext record that ends with an incomplete message fragment is read by record_read(), the fragment will be returned in the 'fragment' member of the record table, and can be passed to the next invocation of the record_read() function. This usage is illustrated in the get_record_iter() function of the modified ssl-enum-ciphers script included in this patch.
Scripts that have not been modified to take advantage of this fragmentation support (i.e. they ignore the 'fragment' parameter when invoking the record_read() function in tls.lua) will continue to function exactly the same as before.