rustls: fix handling of EOF on read #8003
Closed
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
The update to rustls-ffi 0.8.0 changed handling of EOF and close_notify. From the CHANGELOG: > Handling of unclean close and the close_notify TLS alert. Mirroring upstream changes, > a rustls_connection now tracks TCP closed state like so: rustls_connection_read_tls > considers a 0-length read from its callback to mean "TCP stream was closed by peer." > If that happens before the peer sent close_notify, rustls_connection_read will return > RUSTLS_RESULT_UNEXPECTED_EOF once the available plaintext bytes are exhausted. This is > useful to protect against truncation attacks. Note: > some TLS implementations don't send close_notify. If you are already getting length > information from your protocol (e.g. Content-Length in HTTP) you may choose to > ignore UNEXPECTED_EOF so long as the number of plaintext bytes was as > expected. That means we don't need to check for unclean EOF in `cr_recv()`, because `process_new_packets()` will give us an error if appropriate.
jsha
changed the title
When we're reading out plaintext from rustls' internal buffers, we might get a read of zero bytes (meaning a clean TCP close, including close_notify). However, we shouldn't return immediately when that happens, since we may have already copied out some plaintext bytes. Break out of the loop when we get a read of zero bytes, and figure out which path we're dealing with.
|
@kevinburke, does it look good to you as well? |
|
Yes thanks! |
bagder
pushed a commit
that referenced
this pull request
Nov 13, 2021
When we're reading out plaintext from rustls' internal buffers, we might get a read of zero bytes (meaning a clean TCP close, including close_notify). However, we shouldn't return immediately when that happens, since we may have already copied out some plaintext bytes. Break out of the loop when we get a read of zero bytes, and figure out which path we're dealing with. Acked-by: Kevin Burke Closes #8003
|
Thanks both! |
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.
Suggestion cannot be applied right now. Please check back later.
The update to rustls-ffi 0.8.0 changed handling of EOF and close_notify.
From the CHANGELOG:
That means we don't need to check for unclean EOF in
cr_recv(), becauseprocess_new_packets()will give us an error if appropriate.Also, we had code in cr_recv that would return immediately if we got a read of zero
bytes, but actually what we should do in that case is break out of the loop, and
return either CURLE_OK or CURLE_AGAIN depending on whether we had read
some plaintext on a previous iteration.