In TLS clinet false start mechanism, the standard says the following:

The symmetric cipher defined by the cipher suite negotiated in this handshake has been whitelisted for use with False Start according to the Security Considerations in Section 5.1. Reference: rfc7918

Can you explain to me with more details about white listing the ciphers? Is it a list of allowed ciphers stored at the client side? How is this different from the client's ciphersuite list?


Is it a list of allowed ciphers stored at the client side?

This list is defined by the application or more likely the implementation. Basically what you do with "False Start" is that you run a normal TLS handshake and if all of the conditions you found are met, you also immediately start sending encrypted application data - before you have finished the authentication with the server, ie awaited his Finished and ChangeCipherSpec. Because you wait for the third message run before making your decision, this means the cipher suite has already been negotiated and thus you can apply your white-listing strategy.

How is this different from the client's ciphersuite list?

Indeed, these two lists may be identitical but the RFC explicitely states that you want strong security with the picked cipher suite if you want to use "False Start". Now consider what this requirement means: You cannot possibly connect to servers which only support cipher suites you consider "potentially weak", the RFC mentions RSA key-transport as an example for that. So if you'd make these lists equal, yoo wouldn't be able to connect to those servers which is usually undesirable.

For your last question, consider this quote from the RFC:

Instead, the security goal is to ensure that if anyone at all can decrypt the application data sent in a False Start, it must be the legitimate peer.

Basically you want to make sure that if you are under attack and you used "False Start", an attacker can't learn anything about the application data, which is why you want to be "extra-confident" in the cipher-suite.

  • $\begingroup$ Thanks. But, still not clear. In TLS, the server selects the ciphersuite that will be used. The client checks whether this ciphersuite is supported by the client after the Server Hello message. So, the client is done from checking whether the server's selected cipher is supported by the client or not in any TLS negotiation not only Flase Start. So why is this done again in False Start? Is it literaly just a "double check"? $\endgroup$ – user6875880 Mar 24 '17 at 23:10

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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