0rtt garbage resumption #423
Merged
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
tomato42
added
the
new test script
tomato42
force-pushed
the
0rtt-garbage-resumption
branch
2 times, most recently
from
7e58104
to
5b10e9d
Compare
tomato42
force-pushed
the
0rtt-garbage-resumption
branch
2 times, most recently
from
73d15cd
to
cbf2e72
Compare
up till now, the only way to change the record version, was to pass it as a parameter to Connect() class, this extends the abilities to allow changing it in the middle of connection negotiation necessary for sending fake 0-RTT data
even if server does not support the 0-RTT negotiation, the client may have previously connected to a server that did support it and provided the client with a ticket that allowed it. This simulates a resumption from such past session with use of 0-RTT.
in TLS 1.3, the CCS does not change the encryption status of the record layer, so allow skipping that part
tomato42
force-pushed
the
0rtt-garbage-resumption
branch
from
cbf2e72
to
85b58f0
Compare
nmav
reviewed
Jul 23, 2018
scripts/test-tls13-0rtt-garbage.py
Outdated
| node = node.add_child(ExpectServerHelloDone()) | ||
| # section D.3 of draft 28 states that client that receives TLS 1.2 | ||
| # ServerHello as a reply to 0-RTT Client Hello MUST fail a connection | ||
| # consequently, it server does not need to be able to ignore early data |
nmav
reviewed
Jul 23, 2018
| node = node.add_child(ExpectServerHello(version=(3, 3))) | ||
| node = node.add_child(ExpectCertificate()) | ||
| node = node.add_child(ExpectServerHelloDone()) | ||
| # section D.3 of draft 28 states that client that receives TLS 1.2 |
There was a problem hiding this comment.
Doesn't this assume that TLS1.4 will not support 1-rtt? Maybe use a much larger version?
There was a problem hiding this comment.
when TLS 1.4 comes, the test cases will have to be updated, just like they had/have to be updated with TLS 1.3 introduction
the point is to test that if TLS 1.4 comes and includes 1-rtt, that the server will still handle TLS 1.4 clients correctly
tomato42
force-pushed
the
0rtt-garbage-resumption
branch
from
85b58f0
to
5514813
Compare
|
@nmav typo fixed |
nmav
approved these changes
Jul 23, 2018
|
Thanks for review! |
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.
Description
test if server is 0-RTT resumption tolerant, even if it does not support 0-RTT (section 4.2.10 of draft-28)
Motivation and Context
server can turn 0-rtt support at-will, but client will not know when server does it, so the server needs to be able to process 0-rtt handshake always
fixes #422
blocked on tlsfuzzer/tlslite-ng#290
Checklist
tlslite-ng.jsonandtlslite-ng-random-subset.jsonThis change is