Support for session tickets and other post-handshake messages #50
Comments
Lekensteyn
added a commit
that referenced
this issue
Nov 12, 2017
Do not assume that every post-handshake messages are HelloRequests that try to trigger a renegotiation. This could result in a no_renegotiation (rather than an unexpected_message) alert even for other message types (like NewSessionTicket). Related: #50
Lekensteyn
added a commit
that referenced
this issue
Nov 24, 2017
Do not assume that every post-handshake messages are HelloRequests that try to trigger a renegotiation. This could result in a no_renegotiation (rather than an unexpected_message) alert even for other message types (like NewSessionTicket). This change makes the caller of readRecord(recordTypeApplicationData) responsible for checking for renegotiation in case of a handshake message, but that is currently already the case. And the condition "c.phase == waitingClientFinished" can only be hit by the server, so that won't have break the handshake either. Related: #50
Lekensteyn
added a commit
that referenced
this issue
Nov 24, 2017
Do not assume that every post-handshake messages are HelloRequests that try to trigger a renegotiation. This could result in a no_renegotiation (rather than an unexpected_message) alert even for other message types (like NewSessionTicket). This change makes the caller of readRecord(recordTypeApplicationData) responsible for checking for renegotiation in case of a handshake message, but that is currently already the case. And the condition "c.phase == waitingClientFinished" can only be hit by the server, so that won't have break the handshake either. Related: #50
Lekensteyn
added a commit
that referenced
this issue
Dec 1, 2017
Do not assume that every post-handshake messages are HelloRequests that try to trigger a renegotiation. This could result in a no_renegotiation (rather than an unexpected_message) alert even for other message types (like NewSessionTicket). This change makes the caller of readRecord(recordTypeApplicationData) responsible for checking for renegotiation in case of a handshake message, but that is currently already the case. And the condition "c.phase == waitingClientFinished" can only be hit by the server, so that won't have break the handshake either. Related: #50
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In TLS 1.2, the client could not receive NewSessionTicket because it did not advertise the session_ticket extension (RFC 5077). The only post-handshake message it could receive from the server is a HelloRequest message.
In TLS 1.3, the NST message is part of the protocol and does not need an extension. This means that the code must be prepared to accept other post-handshake Handshake messages. In particular:
post_handshake_auth).Currently it sends a no_renegotiation alert while it should probably be sending an unexpected_message alert (or handle the message).
Related: golang/go#19199
The text was updated successfully, but these errors were encountered: