SSL Handshake in .NET Creator ANSI/AIM Code 128 in .NET SSL Handshake

8.2.6 SSL Handshake generate, create barcode standards 128 none in .net projects ISO Standards A Web Server instance can be Code 128 Code Set C for .NET con gured to communicate over SSL after a certi cate has been installed. An SSL session always begins with an exchange of messages called the SSL handshake.

The handshake allows the server to authenticate itself to the client using public-key techniques. It then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.

Figure 8.6 demonstrates the interaction between the client and the server during the SSL handshake. The steps involved in the SSL handshake can be summarized as follows: 1.

The User Agent (i.e., browser) makes a request to communicate with the Web Server over SSL.

The User Agent sends the Web Server its SSL version number, cipher settings, randomly generated data, and other information that Web Server needs to communicate with the User Agent using SSL.. SECURING WEB SERVER 7.0 User Agent Web Server I want to establish a secure connection. 2 3 4. OK, here is my digital certificate. Review certificate. Generate and encrypt symmetrical key. Here is the encrypted key. 6 Decrypt key. Data is encrypted with shared key. Client Interaction with an SSL-enabled Web Server 2. The Web Server responds to the User Agent by sending its own server s SSL version number, cipher settings, randomly generated data, and other information that the User Agent needs to communicate with the Web Server over SSL. The Web Server also sends its own digital certi cate and, if the User Agent is requesting access to a resource that requires authentication, the Web Server may request that the User Agent provides its own certi cate at this time.

3. The User Agent reviews the information contained in the Web Server s certi cate to determine whether it should trust the Web Server. Speci cally, the User Agent validates the following four items: Validity Period The current date and time must be within the range speci ed in the validity period.

The certi cate cannot be expired. Trusted CA Each SSL-enabled User Agent maintains a list of trusted CA certi cates. This list determines which certi cates the User Agent accepts.

If the distinguished name (DN) of the issuing CA matches the DN of a CA on the User Agent s list of trusted CAs, then the User Agent automatically trusts the certi cate.. 8.2 USING SSL CERTIFICATES TO SECURE DATA Digital Signature The digit al signature contained within the certi cate is actually the certi cate itself, hashed and encrypted with the CA s private key. The User Agent uses the public key from the CA s certi cate to validate the digital signature on the Web Server certi cate being presented. This method ensures that the certi cate has not been altered in any way and the User Agent treats the Web Server s certi cate as a valid letter of introduction from that CA.

Subject The subject of the certi cate (i.e., www. is reviewed to determine whether it matches the host/domain requested by the User Agent. This step con rms that the Web Server from which the User Agent has received the certi cate is actually the same one it was attempting to talk to.

Using all data generated in the handshake so far, the User Agent (with the cooperation of the Web Server, depending on the cipher being used) creates a secret message for the session, encrypts it with the Web Server s public key (obtained from the Web Server s certi cate, sent in Step 2). The User Agent sends the encrypted premaster secret message to the Web Server. Optional Steps: If the Web Server has requested User Agent authentication (an optional step in the handshake and not shown in Figure 8.

6), the User Agent also signs another piece of data that is unique to this handshake and known only by the User Agent and Web Server. In this case, the User Agent sends both the signed data and the User Agent s own certi cate to the Web Server, along with the encrypted premaster secret message. If the Web Server has requested User Agent authentication, the Web Server attempts to authenticate the User Agent.

If the User Agent cannot be authenticated, the session is terminated. If the User Agent can be authenticated successfully, the handshake continues. The Web Server uses its private key to decrypt the premaster secret message.

It then performs a series of steps (which the User Agent also performs using the same premaster secret message) to generate the master secret message. Both the User Agent and the Web Server use the shared master secret message to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection..

Copyright © . All rights reserved.