This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Just looked up this thread on geek interview..and found that there was no explanation..so decided to add my 2 cents.
(a) is wrong because a client must be validated by the server only if there is mutual authentication . Mutual authentication is not mandated by SSL but it adds an extra level of security.
(b) is correct and is a key feature of a SSL handshake
(c) is correct as negotiating on a cryptographic algorithm is one of the key features of an SSL handshake. Typically the client tells the server the algorithms it can support and the server responds by choosing an algorithm (the strongest algorithm that they both can support)
(d) is dicey but incorrect. Using a symmetric key to generate shared secrets does not make much sense (in my opinion). Shared secrets are typically generated by asymmetric keys (public,private) . If both parties had a symmetric key they would not need to generate a shared secret...and could directly use the symmetric key for encyption/decryption. Due to the problems involved in the distribution of secret keys parties involved in SSL tend to derive the shared secret from assymetric keys (using Diffie Helman algorithm or the likes - because of the mathematical nature of the algorithm both parties end up generating the same shared key even if they start with asymmetric keys)..
Hope that made sense..
OCMJEA/SCEA, SCDJWS, SCBCD 1.3, SCJP 1.4
My SCEA experience:http://javalogue.blogspot.com/