Page 234 - Open Soource Technologies 304.indd

Web Technologies-I

Notes Session ID: A number that defines the session identifier. A nonzero value of this field
indicates that the client wishes to update the parameters of an existing connection or establish
a new connection on this session. A zero value in this field indicates that the client wishes
to establish a new connection.
CipherSuite: a list of encryption algorithms and key exchange method supported by the client.
The server, in response to the client_hello message sends a server_hello message, containing
the same set of fields as the client message, placing the following data:
• Version: The lowest version number of the SSL protocol supported by the server.
• Random data: the same fashion as used by the client, but the data generated is completely
independent.
• Session ID: If the client field was nonzero, the same value is sent back; otherwise the
server’s session ID field contains the value for a new session.
CipherSuite: The server uses this field to send a single set of protocols selected by the
server from those proposed by the client. The first element of this field is a chosen method
of exchange of cryptographic keys between the client and the server. The next element is
the specification of encryption algorithms and hash functions, which will be used within
the session being initiated, along with all specific parameters.
The set of encryption algorithms and key exchange method sent in the CipherSuite field
establishes three components:
• The method of key exchange between the server and client.
• The encryption algorithm for data encryption purposes.
• A function used for obtaining the MAC value.
The server begins the next phase of negotiations by sending its certificate to the client for
authentication. The message sent to the client contains one or a chain of X509 certificates.
These are necessary for authentication of both the server and the certification path towards a
trusted certification official of the certificating body for the server. This step is not obligatory
and may be omitted, if the negotiated method of key exchange does not require sending the
certificate (in the case of anonymous Diffie-Hellman method). Depending on the negotiated
method of key exchange, the server may send an additional server_key_exchange message,
which is however not required in the case when the fixed Diffie-Hellman method or RSA key
exchange technique has been negotiated. Moreover, the server can request a certificate from
the client. The final step of Phase 2 is the server_done message, which has no parameters
and is sent by the server merely to indicate the end of the server messages. After sending
this message, the server waits for a client response. Upon receipt of the message, the client
should verify the server’s certificate, the certificate validation data and path, as well as any
other parameters sent by the server in the server_hello message. The client’s verification
consists of:
Validation date check of the certificate and comparison with the current date, to verify
whether the certificate is still valid, checking whether the certifying body is included in
the list of trusted Certifying Authorities in possession of the client. If the CA, which has
issued the server’s certificate is not included in the CAs list, the client attempts to verify
the CA signature. If no information about the CA can be obtained, the client terminates the
identification procedure by either returning the error signal or signalling the problem for
the user to solve it.
Identifying the authenticity of the public key of the CA which has issued the certificate. If
the Certifying Authority is included in the client’s list of trusted CAs, the client checks the
CA’s public key stated in the server’s certificate with the public key available from the list.
This procedure verifies the authenticity of the certifying body. checking whether the domain
name used in the certificate matches the server name shown in the server’s certificate.
Contd...

228 LOVELY PROFESSIONAL UNIVERSITY