2

I have read Ivan Ristic, Bulletproof SSL and TLS. There its been said after 2 RTT, client start sending application data like for e.g. GET request.

But I have seen when analysing packets through wireshark that in some sites clients starts sending application right along with ClientFinished message i.e. after 1 RTT, while in some cases it doesn't and starts sending application data after 2 RTT i.e. after receiving ServerFinished message. enter image description here

I think that its not required to wait till ServerFinished for sending application data since client already has key, so it can start sending application data.

In what cases does client sends application data before ServerFinished message and in what cases after ServerFinished message?

If 1 RTT was already there in TLS 1.2, then why there is so fuzz about 1 RTT in TLS 1.3? This is not my main question by the way, answer it if you like.

Copied from RFC

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

         Figure 1.  Message flow for a full handshake
3

While I don't know what exactly you've seen the TLS 1.2 explicitly states that application data must only send after the handshake is complete. This means that both sides has got and verified the Finished message from the other side. This is stated in various parts of the RFC 5246, like

7.4.9. Finished
...
Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.

Within a full handshake the Finished message is first send by the client and then by the server. This means that the client has to wait for the server to receive and verify the Finished message from the client and then send its own Finished message back. And only after the client received and verified this Finished message from the server it can send application data.

But, within a successful session resume the Finished message is first send by the server and then by the client. And in this case application data from the client can of course follow directly the Finished message from the client. From RFC 5246 page 37:

  Client                                                Server

  ClientHello                   -------->
                                                   ServerHello
                                            [ChangeCipherSpec]
                                <--------             Finished
  [ChangeCipherSpec]
  Finished                      -------->
  Application Data              <------->     Application Data

      Figure 2.  Message flow for an abbreviated handshake

... that in some sites clients starts sending application right along with ClientFinished message i.e. after 1 RTT, while in some cases it doesn't and starts sending application data after 2 RTT

One possibility is that you've only noticed that application data from the client directly followed the Finished message but that you did not realize that this was because a session resume happened and thus the Finished from the server has already been received and verified by the client.

But, after you've edited the question and included an image it is obvious that this is not the case and a full handshake was done with early sending of application data. This is called TLS False Start and is defined in RFC 7918. According to this RFC TLS False Start can be done if the client has prior knowledge that the server is compatible to False Start and if strong ciphers white listed for use with False Start are used. For a short introduction into TLS False Start see High Performance Browser Networking.

If 1 RTT was already there in TLS 1.2, then why there is so fuzz about 1 RTT in TLS 1.3?

TLS 1.3 changed the protocol a lot. The result of this was 1-RTT instead of 2-RTT for the full handshake and optionally 0-RTT instead of 1-RTT on subsequent connections (i.e. what was session resume in TLS 1.2).

  • I have checked. This was NOT a session resume since if it was server would have sent its finished message earlier. – prakharjain May 6 '17 at 8:51
  • @prakharjain: it is probably TLS False Start, see edited response. – Steffen Ullrich May 6 '17 at 9:50
  • Yes, it is TLS False start indeed. – prakharjain May 6 '17 at 10:29
  • But I am still doubtful for the cases in which it works because i have 2 examples where in one TLS False start takes place while in other TLS False doesn't take place and both has ALPN server advertisement and forward secrecy suite. – prakharjain May 6 '17 at 10:34
  • @prakharjain: is it in both cases the same browser with same version and same settings and same network connectivity and same target host? Or what is different between these setups? – Steffen Ullrich May 6 '17 at 10:35

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.