-
Notifications
You must be signed in to change notification settings - Fork 2.8k
TLS 1.3: Add mbedtls_ssl_write_early_data() API #8760
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 1.3: Add mbedtls_ssl_write_early_data() API #8760
Conversation
875bb4a to
2384374
Compare
2384374 to
32b504f
Compare
32b504f to
04d82b1
Compare
Signed-off-by: Xiaokang Qian <[email protected]> Signed-off-by: Ronald Cron <[email protected]>
No need to define specific early data, the idea is rather to just send the usual request data as early data instead of standard application data. Signed-off-by: Ronald Cron <[email protected]>
Move code to build http request into a dedicated function. Signed-off-by: Ronald Cron <[email protected]>
Switch from int to size_t for some data lengths and counter local variables. Signed-off-by: Ronald Cron <[email protected]>
Add buffer overflow check to build_http_request(). Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Xiaokang Qian <[email protected]> Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
04d82b1 to
b3d42fd
Compare
|
@mpg I have addressed your comments, the Open CI is green, please have another look, thanks. |
|
Btw, out of scope for this PR, but I think the early data APIs are a bit complex (not saying they're bad, I think 0-RTT is just a fairly complex feature of 1.3 so this reflects in the APIs), and a knowledge base article explaining everything a user needs to know (in general, client-side and server-side) would be helpful if we can write one at some point. |
We have already something at the end of |
Great! Though I'll note as a user I would probably not be looking under |
mpg
left a comment
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.
Thanks for addressing my feedback! Looking pretty good, only minor points left.
Also, it seems to me we can now remove the hack used for testing server before we had client support. Btw, now that we have a tls13_write_early_data test function, perhaps tls13_early_data should be renamed to tls13_read_early_data. Also, why doesn't that one have a NO_INDICATION_SENT scenario like the other two? (I'm OK with considering this whole paragraph out of scope as long as it's tracked somewhere.)
Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
Signed-off-by: Ronald Cron <[email protected]>
I've removed it in this PR (not used anymore) but I will reintroduced it in max_early_data_size PRs for negative testing purposes.
Done
Because not much happens I guess, but better with it thus I've added it. |
|
@mpg @waleed-elmelegy-arm this is ready for the next round of reviews, thanks. |
mpg
left a comment
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.
LGTM, thanks for addressing my feedback and answering my questions!
Thanks for the review and the questions. @waleed-elmelegy-arm please have a look, thanks. |
Perhaps we shouldn't remove it then. #8854 will no longer build (when merged with development) once this is merged. |
I think if I keep it here the CI will fail on this PR because the function will not be used thus I guess we don't have really the choice. |
|
Ah, good point. We'll just need to rebase 8854 when this one gets merged, then. |
waleed-elmelegy-arm
left a comment
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.
Thanks for the PR, just some comments for better clarity but nothing really wrong.
| * The client has not sent the first ClientHello yet, it is unknown if the | ||
| * client will send an early data indication extension or not. | ||
| */ | ||
| MBEDTLS_SSL_EARLY_DATA_STATUS_UNKNOWN, |
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 think this gives the idea that this is a state that track the actual early data not the "early data indication extension" and later on when reading the documentation or the code you realise that it's not, so maybe it's clearer to mention it in the name like with adding "EXT" or "IND" or in any other way that indicates it.
| * HelloRetryRequest) from the server yet. The transform to protect early data | ||
| * has been set and early data can be written now. | ||
| */ | ||
| MBEDTLS_SSL_EARLY_DATA_STATUS_CAN_WRITE, |
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.
From the first glance it seems that "MBEDTLS_SSL_EARLY_DATA_STATUS_SENT" is the same as "MBEDTLS_SSL_EARLY_DATA_STATUS_CAN_WRITE" but it's not because of sending changeCipher compatibility so maybe it's better to mention it here in the comments why it's not the case since I was only able to know from the ticket discussion.
| */ | ||
| MBEDTLS_SSL_EARLY_DATA_STATUS_NOT_SENT, | ||
| MBEDTLS_SSL_EARLY_DATA_STATUS_ACCEPTED, | ||
| MBEDTLS_SSL_EARLY_DATA_STATUS_REJECTED, |
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.
It seems to me that those three states are overlapping with the rest of the states for example "MBEDTLS_SSL_EARLY_DATA_STATUS_ACCEPTED" and "MBEDTLS_SSL_EARLY_DATA_STATUS_REJECTED" are both the same state as "MBEDTLS_SSL_EARLY_DATA_STATUS_SERVER_FINISHED_RECEIVED" but we still need to know the information of if the server accepted early data or not so maybe this can be split to maybe "Result" and "State" for example? or something close maybe.
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.
Actually should we just use different enums for the return value of this function and the internal state? I think that would be clearer.
|
@waleed-elmelegy-arm thanks for your comments. The PR is already quite big and I was thinking that I could address your comments in a follow-up PR. @mpg @waleed-elmelegy-arm would you be fine with that? |
|
Fine by me! |
Description
Second PR of two addressing #6340 .
PR checklist