As I understand, during TLS handshake phase, it is not legal for an endpoint to send its own handshake messages till the time it processes its peer's entire flight of messages completely. E.g. although a server is able to compute master secret after seeing client_key_exchange,
it cannot send its own change_cipher_spec and then finished messages
until it has processed client's finished message.

Why did the designers of TLS (say v1.2 and prior) disallow the possibility
of handshake messages flowing in parallel in both directions?

  • $\begingroup$ My feeling is that it is just to ensure that each end can compute the same value of handshake_hash used in processing finished message. $\endgroup$ – Vakul Garg May 14 '17 at 1:35
  • $\begingroup$ Your understanding is not fully correct. While this was defined in the TLS 1.2 RFC this way it is no longer true when TLS False Start is used. $\endgroup$ – Steffen Ullrich May 14 '17 at 4:31
  • 1
    $\begingroup$ Isn't the entire handshake process half duplex? That certainly helps with simplifying protocol implementations, even at the cost of some performance. $\endgroup$ – Maarten Bodewes May 14 '17 at 9:58
  • $\begingroup$ Also note that non-concurrent sending may also make protocol analysis easier. $\endgroup$ – SEJPM May 14 '17 at 10:17
  • $\begingroup$ If a tls endpoint violates this half-duplex rule, i.e. starts sending its own records without fully consuming full flight of records from peer, is it detectable by the other end? $\endgroup$ – Vakul Garg May 14 '17 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.