Skip to content
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

Find a better way to decide when to switch from handshake-packet to 1RTT packet #69

Open
ddragana opened this issue Dec 5, 2017 · 0 comments

Comments

@ddragana
Copy link
Collaborator

ddragana commented Dec 5, 2017

On the client side: nss writes tls finish message to stream 0 and after that sets the connection state to CONNECTED. The last handshake messages will be encrypted after the connection has changed to the CONNECTED state.

On the server side (if session tickets are used): after receiving the client finish message, server will write the session ticket tls record to the stream 0 and after that switch to the connected state. When the session ticket message is encrypted server is already in the connected state and it will encrypt the session ticket message with 1RTT keys.

The constellation seems good for the server side, but odd for the client side, because it should use handshake message although the connection is the CONNECTED state.

it would be good to be able to marked data correctly (handshake or 1RTT packet data) at the time they are written to stream 0 without inspecting tls records.
it is working currently but can be improved (except for a tls alert from a client after connection has been established).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant