Secure Socket Layer-Paper

Secure Socket Layer

ABSTRACT:

With the evolution of e-business, data security has become very important for Internet users. The Secure Socket Layer (SSL) protocol ensures that the transfer of sensitive information over the Internet is secure. For that sever authentication and client authentication have to be done to establish the connection between client and server. Then, Seasoning is done by creating packets using ssl record protocols. After that, Encryption is take place using the chipher suite algorithm. It is common for both the client and server. Handshake protocols are used to authenticate or certificate clients in server side and servers in client side. Certifying body is included in the list of trusted Certifying Authorities in possession of the client or server. If the server cannot be successfully authenticated by the client on the basis of the delivered certificate, the handshake terminates and the client will generate an error message and vice versa. If server and client successfully authenticated each other then data are transferred in very secure manner.

SSL OVERVIEW:

One way IMS (Information Management System) Connector for Java communicates with IMS Connect is through TCP/ IP sockets. SSL can be used to secure the TCP/ IP communication between the two entities. The SSL support provided by IMS Connector for Java, along with the support provided by IMS Connect, uses a combination of public and private keys along with symmetric key encryption schemes to achieve client and server authentication, data confidentiality, and integrity. SSL rests on top of TCP/ IP communication protocol and allows an SSL-enabled server to authenticate itself to an SSL-enabled client and vice versa. For an SSL connection between IMS Connector for Java and IMS Connect, IMS Connector for Java is considered to be the client and IMS Connect is considered to be the server. Once authentication is complete, the server and client can establish an encrypted connection that also preserves the integrity of the data.The SSL protocol was originally developed by Netscape, to ensure security of data transported and routed through HTTP, LDAP or POP3 application layers. SSL is designed to make use of TCP as a communication layer to provide a reliable end-to-end secure and authenticated connection between two points over a network. Notwithstanding this SSL can be used for protection of data in transit in situations related to any network service, it is used mostly in HTTP server and client applications. Today, almost each available HTTP server can support an SSL session, whilst IE or Netscape Navigator browsers are provided with SSL-enabled client software.

SSL between application protocols and TCP/IP

SSL objectives:

Authenticating the client and server to each other: the SSL protocol supports the use of standard key cryptographic techniques (public key encryption) to authenticate the communicating parties to each other. Though the most frequent application consists in authenticating the service client on the basis of a certificate, SSL may also use the same methods to authenticate the client.

Ensuring data integrity

During a session, data cannot be either intentionally or unintentionally tampered with.

Securing data privacy:

Data in transport between the client and the server must be protected from interception and be readable only by the intended recipient. This prerequisite is necessary for both the data associated with the protocol itself (securing traffic during negotiations) and the application data that is sent during the session itself. SSL is in fact not a single protocol but rather a set of protocols that can additionally be further divided in two layers:

1) The protocol to ensure data security and integrity: this layer is composed of the SSL Record Protocol.

2) The protocols that are designed to establish an SSL connection: three protocols are used in this layer: the SSL Handshake Protocol, the SSL Change Cipher Spec protocol and the SSL Alert Protocol.

The SSL protocol stack

SSL uses these protocols to address the tasks as described above. The SSL record protocol is responsible for data encryption and integrity. As can be seen in Figure it is also used to encapsulate data sent by other SSL protocols, and therefore, it is also involved in the tasks associated with the SSL check data. The other three protocols cover the areas of session management, cryptographic parameter management and transfer of SSL messages between the client and the server. Prior to going into a more detailed discussion of the role of individual protocols and their functions let us describe two fundamental concepts related to the use of SSL.

SSL process:

The SSL protocol consists of server authentication, client authentication followed by an encrypted conversation.

Server authentication:

SSL server authentication allows a client to confirm a server's identity. SSL-enabled client software uses standard techniques of public-key cryptography to ensure that a server's certificate and public ID is valid and that the certificate and ID was issued from one of the client's list of trusted certificate authorities (CA).

Client authentication:

SSL client authentication allows a server to confirm a client's identity. Using the same techniques used for server authentication, SSL-enabled server software verifies that a client's certificate and public ID is valid and that the certificate and ID was issued by one of the server's list of trusted certificate authorities (CA).

SSL handshake:

Both the client, IMS Connector for Java, and the server, IMS Connect, store their certificates and private keys in key stores. The actual SSL session between IMS Connector for Java and IMS Connect is established by following a handshake sequence between client and server. The sequence will vary depending on whether the server is configured to provide a server certificate or to request a client certificate, and which cipher suites are being used. A cipher is an encryption algorithm. The SSL protocol determines how the client and server negotiate the cipher suites to authenticate one another, to transmit certificates, and to establish session keys. Some of the algorithms used in cipher suites include:

· DES - Data Encryption Standard

· DSA - Digital Signature Algorithm

· KEA - Key Exchange Algorithm

· MD5 - Message Digest algorithm

SSL 2.0 and SSL 3.0 protocols support overlapping sets of cipher suites. Administrators can enable or disable any of the supported cipher suites for both clients and servers. When a particular client and server exchange information during the SSL handshake, the client and server identify the strongest enabled cipher suites that they have in common and use one of them for the SSL session.

SSL session and connection

The concepts as mentioned above are fundamental for a connection between the client and the server, and they also encompass a series of attributes.

Connection:

This is a logical client/server link, associated with the provision of a suitable type of service. In SSL terms, it must be a peer-to-peer connection with two network nodes.

Session:

This is an association between a client and a server that defines a set of parameters such as algorithms used, session number etc. An SSL session is created by the Handshake Protocol that allows parameters to be shared among the connections made between the server and the client, and sessions are used to avoid negotiation of new parameters for each connection.
This means that a single session is shared among multiple SSL connections between the client and the server. In theory, it may also be possible that multiple sessions are shared by a single connection, but this feature is not used in practice. The concepts of a SSL session and connection involve several parameters that are used for SSL-enabled communication between the client and the server. During the negotiations of the handshake protocol, the encryption methods are established and a series of parameters of the Session State are subsequently used within the session. A session state is defined by the following parameters:

Session identifier: This is an identifier generated by the server to identify a session with a chosen client,

Peer certificate: X.509 certificate of the peer, compression method: a method used to compress data prior to encryption, 

Algorithm specification termed Cipher Spec: Specifies the bulk data encryption algorithm and the hash algorithm used during the session, 

Master secret: 48-byte data being a secret shared between the client and server, “is presumable”: this is a flag indicating whether the session can be used to initiate new connections. According to the specification, the SSL connection state is defined by the following parameters: 

Server and client random: Random data generated by both the client and server for each connection, 

Server write MAC secret: The secret key used for data written by the server, 

Client write MAC secret: The secret used for data written by the client, 

Server write key: The bulk cipher key for data encrypted by the server and decrypted by the client, 

Client write key: The bulk cipher key for data encrypted by the client and decrypted by the server,

Sequence number: Sequence numbers maintained separately by the server for messages transmitted and received during the data session.

Creating a packet under SSL record protocol

The SSL Record protocol

The SSL record protocol is used to transfer any data within a session - both messages and other SSL protocols (for example the handshake protocol), as well as for any application data.

The Alert Protocol

The Alert Protocol is used by parties to convey session messages associated with data exchange and functioning of the protocol. Each message in the alert protocol consists of two bytes. The first byte always takes a value, “warning” (1) or “fatal” (2) , that determines the severity of the message sent. Sending a message having a „fatal” status by either party will result in an immediate termination of the SSL session. The next byte of the message contains one of the defined error codes, which may occur during an SSL communication session.

The Change Cipher Spec protocol

This protocol is the simplest SSL protocol. It consists of a single message that carries the value of 1. The sole purpose of this message is to cause the pending session state to be established as a fixed state, which results, for example, in defining the used set of protocols. This type of message must be sent by the client to the server and vice versa. After exchange of messages, the session state is considered agreed. This message and any other SSL messages are transferred using the SSL record protocol.

The handshake protocol

The handshake protocol constitutes the most complex part of the SSL protocol. It is used to initiate a session between the server and the client. Within the message of this protocol, various components such as algorithms and keys used for data encryption are negotiated. Due to this protocol, it is possible to authenticate the parties to each other and negotiate appropriate parameters of the session between them.
It can be divided into 4 phases separated with horizontal broken lines. During the first phase, a logical connection must be initiated between the client and the server followed by the negotiation on the connection parameters. The client sends the server a client hello message containing data such as:

Version:The highest SSL version supported by the client. 

Random: Data consisting of a 32-bit timestamp and 28 bytes of randomly generated data. This data is used to protect the key exchange session between the parties of the connection. 

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. 

Cipher Suite: 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,

Cipher Suite:

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 Cipher Suite 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 Differ-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 signaling 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.

Upon successful completion of all steps the server is considered authenticated. If all parameters are matched and the server’s certificate correctly verified, the client sends the server one or multiple messages. Next is the client__key_exchange message, which must be sent to deliver the keys. The content of this message depends on the negotiated method of key exchange. Moreover, at the server’s request, the client’s certificate is sent along with the message enabling verification of the certificate. This procedure ends Phase 3 of negotiations.

Phase 4 is to confirm the messages so far received and to verify whether the pending data is correct. The client sends a change_cipher_spec message, and then sets up the pending set of algorithm parameters and keys into the current set of the same. Then the client sends the finished message, which is first protected with just negotiated algorithms, keys and secrets. This is to confirm that the negotiated parameters and data are correct. The server in response to the client sends the same message sequence. If the finished message is correctly read by either party this confirms that the transmitted data, negotiated algorithms and the session key are correct. This indicates that the session has been terminated and that it is possible to send the application data between the server and the client, via SSL. At this point the TCP session between the client and the server is closed; however a session state is maintained, allowing it to resume communications within the session using the retained parameters.

It is worth noticing that both Phases 2 and 3 are used by both parties to verify the authenticity of the server’s certificate and possibly the client’s certificate during the handshake step. If the server cannot be successfully authenticated by the client on the basis of the delivered certificate, the handshake terminates and the client will generate an error message. The same will occur at the server if the client’s certificate authenticity cannot be confirmed.

The numbers of ports of some SSL-based services

Conclusion:

The TCP/ IP communication between the client and the server is provided by ssl. Client and server authentication, data confidentiality, and integrity are achieved using this layer. SSL can provide interoperability that is exchange of TLS parameters by either party, with no need for the other party to know the TLS implementation’s details. It is possible to authenticate the parties to each other and negotiate appropriate parameters of the session between them using SSL handshake protocol. SSL is seen as a means to provide a framework for easy future extensions to be built in new cryptographic technologies, based, however, on the same protocols not withstanding the changes made to the cryptographic protocols.