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.
