You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to understand the behavior of picoquic_state_server_false_start. The short of my question is: what does this state signify and how does it differ from picoquic_state_server_almost_ready?
I came across its handling in picoquic_prepare_segment, and one oddity is the comment at the end of its handling block - Else, just fall through to almost ready behavior. - which is followed by case picoquic_state_client_ready_start: where I would have expected case picoquic_state_server_almost_ready:. Maybe an artifact of a code move, or more likely due to my own misunderstanding. Flagging just in case.
RFC 9001 section 4.1.1. Handshake Complete reads: "This happens when the TLS stack has both sent a Finished message and verified the peer's Finished message." A server isn't fully done until a client has sent something back after the handshake response. This lines up with Noise as well.
In the picoquic code, if client authentication is enabled, it seems to wait for the client Finished message by transitioning into picoquic_state_server_false_starthere, but otherwise transitions into picoquic_state_server_almost_ready; how do these relate to waiting for the Finished message? The comment next to picoquic_state_server_false_start makes me think that it is the one that waits for a Finished message, but it's only triggered if client authentication is turned on, so I think I'm misunderstanding something.
In the case where it transitions into picoquic_state_server_false_start, what's the sequence of events that leads it to transition to picoquic_state_server_almost_readyhere?
Thanks for helping me understand the code better.
The text was updated successfully, but these errors were encountered:
"False Start" is another name of "0.5RTT". The server has done it's share of the Diffie Hellman exchange, but cannot tell whether the connection is e2e or MITM. The connection will only be verified when the client checks the server keys and certs and sends back a final message.
So basically:
Client
Server
Initial state: send client hello
initial state: receive client hello
initial state: send server hello
handshake state: send first flight
false start: may start sending 1RTT
initial state: receive server hello
handshake state: discard initial key
handshake state: receive server flight
handshake state: validate cert
almost ready: send-receive 1RTT
almost ready: send client final (as handshake packet)
false start: receives client final (as handshake packet)
false start: validates final
ready: send "handshake done" in 1 RTT
discard initial and handshake key
almost ready: receive handshake done
ready: after that. Discard "handshake" and "0RTT" keys
I'm trying to understand the behavior of
picoquic_state_server_false_start
. The short of my question is: what does this state signify and how does it differ frompicoquic_state_server_almost_ready
?I came across its handling in
picoquic_prepare_segment
, and one oddity is the comment at the end of its handling block -Else, just fall through to almost ready behavior.
- which is followed bycase picoquic_state_client_ready_start:
where I would have expectedcase picoquic_state_server_almost_ready:
. Maybe an artifact of a code move, or more likely due to my own misunderstanding. Flagging just in case.RFC 9001 section 4.1.1. Handshake Complete reads: "This happens when the TLS stack has both sent a Finished message and verified the peer's Finished message." A server isn't fully done until a client has sent something back after the handshake response. This lines up with Noise as well.
In the picoquic code, if client authentication is enabled, it seems to wait for the client Finished message by transitioning into
picoquic_state_server_false_start
here, but otherwise transitions intopicoquic_state_server_almost_ready
; how do these relate to waiting for the Finished message? The comment next topicoquic_state_server_false_start
makes me think that it is the one that waits for a Finished message, but it's only triggered if client authentication is turned on, so I think I'm misunderstanding something.In the case where it transitions into
picoquic_state_server_false_start
, what's the sequence of events that leads it to transition topicoquic_state_server_almost_ready
here?Thanks for helping me understand the code better.
The text was updated successfully, but these errors were encountered: