How many steps are employed between the client and server in the SSL handshake process?

You are explaining SSL to a junior administrator and come up to the topic of handshaking.
How many steps are employed between the client and server in the SSL handshake process?

You are explaining SSL to a junior administrator and come up to the topic of handshaking.
How many steps are employed between the client and server in the SSL handshake process?

A.
Five

B.
Six

C.
Seven

D.
Eight

Explanation:
Graphical explanation of 6 steps to Digital Handshake for SSL Note: The handshake begins when a browser connects to an SSL-enabled server, and asks the server to send back its identification, a digital certificate that usually contains the server name, the trusted certif ying authority, and the server public encryption key. The
browser can contact the server of the trusted certifying authority and confirm that the certificate is authentic before proceeding.The browser then presents a list of encryption algorithms and hashing functions (used to generate a number from another); the server picks the strongest encryption that it also supports and notifies the client of the decision In order to generate the session keys used for the secure connection, the browser uses the server public key from the certificate to encrypt a random number and send it to the server. The client can encrypt this data, but only the server can decrypt it: this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data The server replies with more random data (which doesn’t have to be encrypted), and then both parities use the selected hash functions on the random data to generate the session The SSL handshake allows the establishment of a secured connection over an insecure channel. Even if a third party were to listen to the conversation, it would not be able to obtain the session keys. The process of creating good random numbers and applying hash functions can be quite slow, but usually the session keys are cached, so the handshake occurs only on the first connection between the parties.
This process works on top of HTTP, so its portable to any platform that supports it, and is in principle applicable to other protocols as well (Welling 2001, p.334). The process described is part of SSL version2.0, but version 3.0 is supposed to replace it soon. Another standard, Transport Layer Security (TSL) is still in draft and
is supposed to replace SSL in the future.



Leave a Reply 0

Your email address will not be published. Required fields are marked *