summaryrefslogtreecommitdiff
path: root/src/regress/lib/libssl/handshake/handshake_table.c
diff options
context:
space:
mode:
authorjsing <>2020-04-22 17:05:07 +0000
committerjsing <>2020-04-22 17:05:07 +0000
commitc18a60d45888295bb8cf344e076d84ef817a65a5 (patch)
treec7a924ebca094d3b2e25924b18e7bcf1cf4da7b7 /src/regress/lib/libssl/handshake/handshake_table.c
parentc430432c2ef1ea560124b642f581c3e1ddb24f69 (diff)
downloadopenbsd-c18a60d45888295bb8cf344e076d84ef817a65a5.tar.gz
openbsd-c18a60d45888295bb8cf344e076d84ef817a65a5.tar.bz2
openbsd-c18a60d45888295bb8cf344e076d84ef817a65a5.zip
Improve TLSv1.3 state machine for HelloRetryRequest handling.
The state machine currently handles the HelloRetryRequest case by using WITH_HRR - in other words, we're explicitly indicating when we transition to the alternate path. The problem here is that we do not know if we're going to receive a ServerHello or a HelloRetryRequest until we process the message. This means that the ServerHello processing code has to handle both types of messages. The state machine and associated processing code becomes cleaner if we flip this around so that we assume we are going to receive a HelloRetryRequest and upon discovering that it is not, trigger WITHOUT_HRR and hand off to the ServerHello processing function. In particular, this makes the logic much more straight forward on the server side, when adding support for HRR. With feedback from tb@ ok tb@
Diffstat (limited to 'src/regress/lib/libssl/handshake/handshake_table.c')
0 files changed, 0 insertions, 0 deletions