The secure socket layer (SSL) is an open protocol originally developed by Netscape Communications for securing data communications across computer networks. Also it has been universally accepted on the World Wide Web for authenticating and encrypting communication between clients and servers. As we all know the World Wide Web is growing in popularity, more organizations and individuals are seeing the Web as an efficient, inexpensive means of distributing information, services and products. Companies must therefore provide a reasonable level of security in their e-commerce activities.

The SSL protocol runs below the application layer and above transport layer, and it uses TCP/IP on behalf of the application protocols.

This protocol allows an SSL-enabled server to authenticate itself with an SSL-enabled client, and also allows the client to authenticate itself with the server. Thus both client and server can establish a connection for encrypting messages. These capabilities address fundamental concerns about communication over the Internet and other TCP/IP networks. Thus three important features that SSL protocol provides are as following:

Allows a user to confirm a server�s identity. This is very important, since users don�t want to send out our personal information, such as credit card numbers to an illegitimate web server. Therefore SSL-enabled client software can use standard techniques of public key cryptography to check if a server�s certificate and public ID are valid and have been issued by a certificate authority (CA) listed in the client�s list of trusted CAs. A Certification Authority is a trusted authority responsible for issuing certificates used to identify a community of individuals, systems or other entities, which make use of a computer network.

• SSL client authentication

Not only do clients want to check a server�s identity; sometimes a server also would like to check a client�s identity before it sends out information to that client. SSL client authentication allows a server to confirm a user�s identity by using the same techniques as those used for server authentication.

• An encrypted SSL connection

After both server and client confirm each other�s identity, an encrypted SSL connection will be established, which means all information sent between the client and the server is encrypted. An encrypted connection between a client and a server is required, because even though both server and client have been confirmed each other�s identity, but there is still a possibility that during the process, information might be intercepted by a third party. If the information is encrypted before it is sent out, it will remain protected until received by the server or the client. SSL also provides a mechanism for determining whether the data has been altered during this transition.

The SSL protocol includes two sub protocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol defines the format that is used to transmit data, which is used for all SSL communications and by both the client and the server at all, times. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL enabled client, when they first establish an SSL connection.

• SSL record sub protocol

In SSL, all data sent is encapsulated in a record, an object that is composed of a header and some non-zero amount of data. Each record header is either a two or three byte length. If the most significant bit is set in the first byte, then the header has two bytes; otherwise the record has three bytes.

The data portion of an SSL record is composed of three components:

• ACTUAL-DATA
• MAC-DATA
• PADDING-DATA

ACTUAL-DATA is the actual data being transmitted, which means the message before encryption. After the message is encrypted, the PADDING-DATA will shows the cipher block size. The MAC-DATA is some data computed by an encryption algorithm, which will be added to the actual data being transmitted to prevent hackers from reading the encrypted message. A MAC message is 40 or 128 bit long, which would make it impossible to try to figure out what the right MAC is. The odds of guessing are 2 to the power of 128. Thus it prevents hackers send out faked message, because they can not decrypt the MAC information. The general process to make a SSL record is as follows:

• Fragment (fragments the original information into SSLPlaintext)
• Compress( compress the SSLPlaintext)
• MAC operation(adding MAC message)
• Encryption(encryption the whole record)

• SSL handshake sub protocol

The handshake allows the server to authenticate itself to the client using public-key techniques. Conversely, it can also allow the client to authenticate itself to the server.

Following steps shows what happens during a handshake:

1. The client sends its SSL version number, cipher settings, randomly generated data, and other information to the server, which server needs to communicate with the client using SSL. The randomly data is just for testing purpose.
2. The server sends the client the server�s SSL version number, cipher setting, randomly generated data, and other information the client needs to communicate with the server during the SSL session. In order to identify the server itself, server also sends its own certificate. The purpose of this digital certificate is that sometimes any user can still fake who he or she is by only providing public and private key, so the digital certificate can provide more security during the authentication process. A digital certificate contains: the certificate�s name; the entity for whom the certificate is being issued; the public key of the entity; and some time stamps. After sending out all the above information, the server can also request the clients certificate.
3. The client uses some of the information sent by the server to authenticate the server. The client first checks the server�s certificate�s validity period. If the current date and time are expired, then the authentication process fails. If the current data and time are valid, then the client checks the issuing CA. Each SSL-enabled client maintains a list of trusted CA certificates. If the issuing CA name that got from the server matches one of the names on the client�s list of trusted CAs, then the client uses that CA�s public key found in its trusted CAs list to check this CA�s digital signature. If everything is passed, then the client checks if the server is actually located at the same network address specified by the domain name in the server certificate

4. After all the above verification process is complete (if the server asked a client for

authentication, then client sends all the information that the server needs, the server

then checks the client�s identity by using similar steps above), the client will send the

server a premaster Secrete, which is 48 byte information. Then both the server and

the client uses that to create an another 48 byte long message called master secrete.

They both use this master secrete to generate a pair of session keys known as

symmetric keys. In the beginning of the handshake, the client and the server both

exchange each other�s SSL setting, so they know each other�s encryption algorithm,

which will be set to the same at the end. Then because they both use a same

premaster secrete to generate a master secrete, therefore the master secrete they

generate should be the same, then they use the same master secrete to generate a pair

of session keys, which is also the same at the end. Thus the server and the client can

encrypt and decrypt each other�s messages. Another more important issue about the

session keys is that because each time the premaster and master secrete will be

regenerated, the session keys will be different each time they get generated. The

advantage to this is that you do not have to worry about too much security for the

session keys since each will be different.

5. After all the above is complete, the server and the client will notify each other, then

they can start to communicate with each other by encrypting and decrypting

messages using the session keys.

Overall, SSL provides you a secure way to exchange information through the internet. We also see most keys range from 40 to 1,024 digits long, with these long lengths it will take very long time to break the key, and if the number of digits in the key gets longer, then the number of possible combinations grows into the trillions. SSL protocol, like any other protocol is designed to work with the existing network protocols. After initiating the security handshake, to start a TCP/IP connection, SSL�s only role is to encrypt and decrypt the byte stream of the application protocol being used. Thus SSL may operate independently of the Internet application and connection protocols. There are many companies using SSL enabled products and supporting the SSL protocol for Internet security. Some of the companies that are supporters of the SSL protocol are: Apple Computer., Bank of America, Delphi Internet Services Corporation, IBM, MasterCard, Novell Inc., Microsoft Corporation, MCI Communications Corp., Sun Microsystems, Inc. and Visa International.