-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
TLS handshake fragmentation support #8981
base: development
Are you sure you want to change the base?
Conversation
dc99fe4
to
469afe8
Compare
CI Failed, as under some configs:
(You can see full test results by clicking on the Details link for the OpenCI PR Tests below) |
yes, looks like a temporary variable was unused when building without debug. fixed. but unused variables aside, does the overall approach look good? |
Support for MBEDTLS_SSL_MAX_FRAGMENT_LENGTH in stream TLS mode Signed-off-by: Deomid rojer Ryabkov <rojer@rojer.me>
If the server does not acknowledge our fragment length proposal we should revert back to not fragmenting. Signed-off-by: Deomid rojer Ryabkov <rojer@rojer.me>
addressed comments, rebased |
Hi, any idea when this is going to land? This prevents us from moving to 3.6.0. |
@cryi Due to the size of the feature, I'm afraid we can't add it to the 3.6 long-time support branch. Since we are not planning any new 3.6 release, I'm afraid this won't be released before Mbed TLS 4.0, which is planned for in Q2 2025. |
@@ -1811,6 +1811,10 @@ struct mbedtls_ssl_context { | |||
|
|||
size_t MBEDTLS_PRIVATE(in_hslen); /*!< current handshake message length, | |||
including the handshake header */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a changelog entry.
@@ -1811,6 +1811,10 @@ struct mbedtls_ssl_context { | |||
|
|||
size_t MBEDTLS_PRIVATE(in_hslen); /*!< current handshake message length, | |||
including the handshake header */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add some tests, i.e. at least one test case in tests/ssl-opt.sh
that fails before adding this feature and passes after adding it. This will probably require adding things to programs/ssl/ssl_{client,server}2.c
.
Thank you @gilles-peskine-arm . Nvm I realized that solution is just not to use |
/* | ||
* Make room for the next fragment's header. | ||
* Note: out_ctr points into previous record's payload but since in practice | ||
* we only process unencrypted handshake messages here, like certificates), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: in TLS 1.3 certificates are encrypted. Does this need updating for 1.3?
@@ -3292,11 +3323,74 @@ int mbedtls_ssl_prepare_handshake_record(mbedtls_ssl_context *ssl) | |||
} | |||
} else | |||
#endif /* MBEDTLS_SSL_PROTO_DTLS */ | |||
/* With TLS we don't handle fragmentation (for now) */ | |||
#if defined(MBEDTLS_SSL_MAX_FRAGMENT_LENGTH) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure re-assembly should depend on MAX_FRAGMENT_LENGTH
being enabled: even if we didn't send the extension, the peer is always free to fragment messages on its own initiative.
I'd say that's already two parts, and arguably we should support defragmenting on the way in unconditionally. Could almost be two distinct PRs, except that for testing it's convenient to have both.
I'm sorry, I'm not sure I understand here: are you talking about messages we send or messages we receive? Indeed if the server ignores the extension, then we're likely to receive messages larger than we asked for, but I don't see why that would prevent us from still sending messages in smaller fragments if we want to.
That's great to know! Unfortunately I don't have time to do a full review now, but this is good news, and the size of the patch is smaller than I expected for this feature, which is encouraging. |
ok, so i take it that there is overall agreement on the approach - good to know. i will work on tests and TLS 1.3 compatibility (that i completely ignored until now, since we don't have it enabled in our build). @mpg, i agree that defragmentation should be performed irrespective of whether fragment length is specified or not. somehow, this did not occur to me when i was working on it. |
@brewkon |
yes, rebasing, making sure it works with 1.3 and adding automated tests is what needs to be done here to get this ready. |
Actually on second thought, we don't need to have both for testing: if we support defragmenting incoming messages, we can use another implementation for testing - for example, So, I think this PR could indeed be split into multiple parts:
The reasons I'm suggesting this are:
@rojer Would you be interested in updating this PR (or creating a new one) focusing just on support for incoming message, including TLS 1.3 and tests? |
@mpg it's on my list of TODOs, but way, way down in the "fun" section. at the moment there's no business requirement for TLS1.3 and it'd be a bigger change. meanwhile, it's being used in prod for 1.2 without issues (i think there's one fix i made after this PR). so, i can commit to get 1.2 support out but not 1.3, unfortunately. |
as suggested, i'm splitting this PR into multiple. |
Description
Adds support for max_frag_len extension in TLS mode.
Consists of two parts:
This approach was extensively tested in production in a big fleet of devices. However, this exact code is new (i'm forward-porting patches to 2.16 which was our previous base version).
Fixes #1840
PR checklist
Note: this is not a finished product. If there's agreement in principle, i will add tests, changelog, etc.
Please tick as appropriate and edit the reasons (e.g.: "backport: not needed because this is a new feature")
Notes for the submitter
Please refer to the contributing guidelines, especially the
checklist for PR contributors.
Help make review efficient: