Skip to content

Conversation

@minosgalanakis
Copy link
Contributor

@minosgalanakis minosgalanakis commented Feb 24, 2025

Description

Continue the work on #9928 adding more specially designed tests in ssl-opt.sh. Currently it is focused on buffer resizing and renegotiation for TLS 1.2. The scope may be expanded.

PR checklist

Please remove the segment/s on either side of the | symbol as appropriate, and add any relevant link/s to the end of the line.
If the provided content is part of the present PR remove the # symbol.

  • changelog not required because: Testing changes
  • development PR provided #here
  • TF-PSA-Crypto PR not required because: No changes to crypto
  • framework PR not required: No changes to framework
  • 3.6 PR provided [Backport 3.6] Extend ssl-opt testing for TLS HS defragmentation  #10065
  • 2.28 PR not required because: Feature we are testing has not been backported to 2.28
  • tests provided

@minosgalanakis minosgalanakis changed the base branch from development to features/tls-defragmentation/development February 25, 2025 00:00
@minosgalanakis minosgalanakis changed the title Exntend ssl-opt testing for TLS HS defragmentation Extend ssl-opt testing for TLS HS defragmentation Feb 25, 2025
@minosgalanakis minosgalanakis force-pushed the task9887_extend_defragmentation_tests branch 2 times, most recently from 20501e7 to d2ab8b5 Compare March 5, 2025 10:46
@minosgalanakis minosgalanakis force-pushed the task9887_extend_defragmentation_tests branch 5 times, most recently from d93a7b2 to 8158b39 Compare March 7, 2025 14:33
Copy link
Contributor

@mpg mpg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a first pass, making myself familiar with things. I haven't looked at the buffer resizing part, only renego.

It seems to me that we need to distinguish two things:

  • the party that fragments
  • the party that initiates renegotiation

So far it looks like we're testing both options for the party that fragments, but the party that initiates the renegotiation is always the client. I'm not sure if we need the full matrix, but we need to make a conscious decision about our test plan.

IMO the hardest case is when the client is both initiating and fragmenting (tested in this PR), and the ClientHello that initiates the renegotiation is fragmented (not tested so far).

Server-initiated renego is very simple: it's just the server sending a HelloRequest (empty, so can't be fragmented) followed by a handshake that's identical to client-initiated renego. Basically, only the client can actually start the renego, all the server can do is ask the client to start it. So, I'm not overly worried about not having tests for server-initiated renego with fragmentation, though as a matter of principle it might be good to have one.

tests/ssl-opt.sh Outdated
"$P_SRV debug_level=4 force_version=tls12 auth_mode=required" \
"$O_NEXT_CLI -tls1_2 -split_send_frag 32 -cert $DATA_FILES_PATH/server5.crt -key $DATA_FILES_PATH/server5.key" \
requires_config_enabled MBEDTLS_SSL_RENEGOTIATION
run_test "Handshake defragmentation with client-initiated renegotation: len=256" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: renegotIation (multiple occurrences).

Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks promising at dee46de, but we're missing what's perhaps the most important case: a server receives a fragmented ClientHello for renegotiation.

requires_protocol_version tls12
requires_certificate_authentication
requires_config_enabled MBEDTLS_SSL_MAX_FRAGMENT_LENGTH
requires_config_enabled MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is buffer resizing relevant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was requested by @mpg andscoped in as part of the possible extended tests in the design discussions. This PR is exploring how it could be introduced, but I am happy to move forward either way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually Gilles I think it was you who brought it up, back when the original PR was introducing a new pointer. IIRC the reasoning was that any new pointer comes with a risk of use-after-free, so what's the one thing that frees (reallocates) in_buf other than ssl_free() (which also sets all the pointers to NULL) - it's buffer resizing. Back then I think you said that based on reading the code it looked OK (pointer updated in the relevant place) but as a matter of principle we should have a test. After that I included it in my list of tests we wanted.

Now that we don't have an extra pointer any more, I agree it seems less important. However since Minos already wrote the tests cases, I'm inclined to keep them.

@minosgalanakis minosgalanakis force-pushed the task9887_extend_defragmentation_tests branch from dee46de to 92ec60f Compare March 11, 2025 17:20
@minosgalanakis
Copy link
Contributor Author

The force push to 92ec60f is simply the rebase on updated feature branch.

@minosgalanakis minosgalanakis force-pushed the task9887_extend_defragmentation_tests branch from 92ec60f to 54e275d Compare March 11, 2025 17:30
@minosgalanakis minosgalanakis added size-s Estimated task size: small (~2d) priority-high High priority - will be reviewed soon labels Mar 12, 2025
@minosgalanakis minosgalanakis added the needs-review Every commit must be reviewed by at least two team members, label Mar 12, 2025
@minosgalanakis
Copy link
Contributor Author

@mpg , @gilles-peskine-arm All the comments have been addressed, and the CI is clear.

Copy link
Contributor

@mpg mpg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't complete my review today, posting the feedback I have so far.

Next commit to review: fd0c850 ssl-opt: Added coverage for client-initiated fragmented HS renegotiation tests.

@mpg mpg changed the base branch from features/tls-defragmentation/development to development March 13, 2025 08:38
@mpg mpg changed the base branch from development to features/tls-defragmentation/development March 13, 2025 08:39
@mpg mpg changed the base branch from features/tls-defragmentation/development to development March 13, 2025 10:52
Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM except for a typo that affects test case filtering.

-c "client hello, adding renegotiation extension" \
-c "found renegotiation extension" \
-c "=> renegotiate"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no test case for renegotiation when Mbed TLS is the party that initiates the renegotiation. However, as noted by Manuel, server-initiated renegotiation just means a non-fragmentable (because empty) HelloRequest from the server, followed by the same exchanges as client-initiated renegotiation. So for our purposes here, testing both sides of the initiation doesn't really matter. What matters is testing both a fragmented renegotiation ClientHello (i.e. OpenSSL is the fragmenting client and Mbed TLS is the defragmenting server) and a fragmented renegotiation ServerHello (i.e. OpenSSL is the fragmenting server and Mbed TLS is the defragmenting client), and this is done.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, this comment states that there's an apparent testing gap, but it's ok because it's not really an actual testing gap, so no action is needed.

@github-project-automation github-project-automation bot moved this from In Review to In Development in Roadmap pull requests (new board) Mar 17, 2025
@gilles-peskine-arm gilles-peskine-arm added needs-work and removed needs-review Every commit must be reviewed by at least two team members, labels Mar 17, 2025
mpg
mpg previously approved these changes Mar 18, 2025
Copy link
Contributor

@mpg mpg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing my feedback, looks pretty good to me now!

Only left two minor comments that probably wouldn't be worth another round on their own, but since we already need another round for the filter-impacting typo found by Gilles, you may consider addressing those as well.

Signed-off-by: Minos Galanakis <[email protected]>
Copy link
Contributor

@mpg mpg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks all good to me now, thanks!

@mpg mpg added needs-review Every commit must be reviewed by at least two team members, needs-ci Needs to pass CI tests and removed needs-work labels Mar 18, 2025
@mpg mpg requested a review from gilles-peskine-arm March 18, 2025 10:41
Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

-c "client hello, adding renegotiation extension" \
-c "found renegotiation extension" \
-c "=> renegotiate"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, this comment states that there's an apparent testing gap, but it's ok because it's not really an actual testing gap, so no action is needed.

@github-project-automation github-project-automation bot moved this from In Development to Has Approval in Roadmap pull requests (new board) Mar 18, 2025
@gilles-peskine-arm gilles-peskine-arm added approved Design and code approved - may be waiting for CI or backports and removed needs-review Every commit must be reviewed by at least two team members, labels Mar 18, 2025
@gilles-peskine-arm gilles-peskine-arm added this pull request to the merge queue Mar 18, 2025
Merged via the queue into Mbed-TLS:development with commit 94b9972 Mar 18, 2025
6 checks passed
@github-project-automation github-project-automation bot moved this from Has Approval to Done in Roadmap pull requests (new board) Mar 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Design and code approved - may be waiting for CI or backports needs-ci Needs to pass CI tests priority-high High priority - will be reviewed soon size-s Estimated task size: small (~2d)

Development

Successfully merging this pull request may close these issues.

3 participants