This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Within the Internet there is a variety of cryptographic protocols, each one is specialized for different operation. Secure Sockets Layer protocol or SSL offers a cryptographic communication between a web browser and a web server and is the most widely used security protocol for e-commerce.
The SSL protocol administers secure communication with a wide range of cryptography and digital signatures that supports, providing a sufficient level of security.
However, in order to have security in e-commerce applications the existence of a secure web server is required. The web server must protect sensitive data sent from the client's browser to the server of the store. The servers manage and distribute those information throughout the Internet.
SSL (Secure Socket Layer) is a flexible, general purpose encryption system to protect communications via the Web, which is embedded in browsers like Netscape and internet explorer.
The SSL protocol is designed to provide confidential communication between two systems, one of which operates as a customer (client) and the other as a server (server). That is, the protocol can provide confidential communication between merchant and customer in a payment transaction and therefore this is the main protocol for electronic commerce. Specifically, the SSL protocol provides encryption of the transmitted information (data encryption), mandatory authentication of the server (server authentication) and optional authentication of the client (client authentication) by valid certificates issued by trusted Certification Authorities.
It supports many encryption techniques and digital signatures to meet all needs. In addition it ensures data integrity, applying the technique of Message Authentication Codes (MACs), ensuring that nobody can alter the information without being observed. For each transaction SSL creates an encrypted session key which length may be 40 bits or 128 bits. It is known that the longer the key length, the more secure the encrypted communication is.
The SSL protocol is developed by Netscape Communications Corporation for secure communication of sensitive information such as personal information and credit card numbers. There have been three versions of SSL.
The history of the development of SSL as follows:
July 1994: Released the first version v.1.0 of the SSL protocol from Netscape, which was used only for internal company needs.
December 1994: Released the second edition v.2.0 Protocol, which was incorporated in the web browser Netscape, the Netscape Navigator.
July 1995: Published the respective web browser from Microsoft, the Internet Explorer, which supports this version v.2.0 of SSL, but with some Microsoft extensions.
The SSL protocol version to v.2.0, was established as the de facto standard for
cryptographic protection of HTTP data traffic. The HTTP (Hyper Text Transfer Protocol) is a protocol that takes care of transportation and communication systems on the Internet. However, SSL v.2.0 has several limitations both in cryptographic security and in terms of functionality. For this reason there was a need for improved version of v.2.0. This protocol was upgraded to SSL v.3.0
November 1995: Released officially v.3.0 of SSL, and a few months earlier has been applied to the company's products, such as Netscape Navigator.
May 1996: The SSL passes in the jurisdiction of the Internet Engineering Task Force-IETF, which creates a task force named TLS group and renames the new version of SSL to TLS (Transport Layer Security).
The workgroup named TLS group was established in 1996 to standardize the Protocol Transport Layer Security. The TLS group worked on SSL v.3.0 protocol. This group completed a series of specifications that describe the versions 1.0 and 1.1 of the TLS protocol, and prepared version 1.2. January 1999: Issued the first edition of the protocol TLS, which may be regarded as the release of v.3.1 SSL.
December 2005: published version 1.1 of the TLS protocol by the TLS group.
The third version of SSL protocol covered many shortcomings of the second edition. The main changes are:
a) Reduction of the message during the establishment of the connection handshake.
b) The choice of compression algorithms and encryption from the server
c) The renegotiation of master-key and session-id.
Even increasing the available encryption algorithms and add new techniques to manage keys. Overall, the third version of SSL (v.3.0) has a more comprehensive design than the second, with a greater range of support and fewer defects.
The Netscape company wanted the universal adoption of the protocol SSL, which conflicted with the current U.S. legislation on the export of cryptographic algorithms, so they were forced to allow the use of cryptographic algorithms with 40 bits key in SSL export applications, instead of the standard version using the 128 bits.
10.2 Architecture of SSL.
The architecture installation of the SSL protocol is illustrated in Figure 10.1.
Figure 10-1: Architecture Installation of SSL.
The SSL protocol can work over any transport protocol. It does not depend on the existence of TCP / IP protocols and supports applications such as HTTP, FTP and TELNET. The TCP / IP (Transmission Control Protocol / Internet Protocol) is the communication protocol for communication between computers connected to the Internet. The original TCP / IP refers to two of the main protocols used on the Internet, ie TCP and IP. The FTP is a file transfer protocol, which arranges the movement of files through the Internet, and TELNET is essentially a service whereby internet users obtain direct access to other terminals over the Internet.
It is important that any new communication protocol complies with the open system interconnection model (OSI), so an existing protocol can be easily replaced or be integrated into the existing structure of protocols. The SSL works additional to the existing structure of the OSI protocol rather than a replacement. Furthermore, the use of SSL does not exclude the use of another security mechanism that operates at a higher level, such as the HTTPS, which is applicable to the level of implementation over SSL. The HTTPS (Secure HTTP) protocol ensures secure data transfer over the Internet. An important advantage of transport layer security in general and in particular SSL is independent of the application, which means it can be used
transparently and provide security to any TCP / IP implementation.
The SSL protocol provides TCP / IP secure connection that has three basic properties:
â€¢ Authentication between those who communicate, each other using
public key cryptography.
â€¢ Confidentiality of data transmitted, after the connection data are
encrypted transparently after an initial handshake and a key session is established.
â€¢ Protect the integrity of transmitted data, messages transparently authenticate and checked for integrity during transmission with the use of MAC addresses.
The operation of the SSL protocol has two main stages: SSL session and SSL connection.
The SSL session establishes a relationship between a client and a
server. Sessions are created by the SSL Handshake protocol and security configurations, which can be shared simultaneously across connections. The main reason for this is to avoid lengthy negotiation over new security parameters for each new connection. The parameters contained and shared in a session are:
â€¢ Session ID: chosen by the server to recognize an active or recurrent status meeting.
â€¢ Digital Certificate (peer entities).
â€¢ Method of data compression: Algorithms used for data compression before encryption.
â€¢ Data Encryption Algorithm.
â€¢ Master secret: A unique number of48-bytes length, shared secret between server and client.
â€¢ Ability to restart the session.
During an SSL connection information is transferred between two entities. The SSL connections are relations between peer entities and are transient.
The parameters contained in a link are:
â€¢ Random numbers between client and server, which is different for each connection.
â€¢ MAC secret server: secret used for MAC operations on data recorded by the server.
â€¢ Client MAC secret: secret used for MAC operations on data entered by the customer.
â€¢ The key used to encrypt data on the server and decryption by the client.
â€¢ The key used to encrypt data on the client and decryption from the server.
â€¢ Vectors initialize the connection.
â€¢ Sequence Numbers: Each member (server, client) maintains separate sequence numbers for sending and receiving messages to each connection.
As shown in Figure 1, the SSL protocol consists of two protocols, the SSL record protocol and the SSL handshake protocol. The SSL record protocol provides authentication, confidentiality and data integrity, and protection from message retransmission attacks. Specifically, the protocol places the data in packets and encrypts them before the broadcast. SSL also performs the reverse procedure for the accepted packets. The SSL handshake protocol is a protocol of authentication and key exchange which also negotiates, initializes and synchronizes security considerations. Specifically, the protocol negotiates the encryption algorithms used to carry out the authentication of a server and a client if requested.
After completing the SSL handshake protocol, data applications can be sent via the SSL record protocol following the agreed parameters of safety. The SSL record protocol and SSL handshake protocol are explained in detail next in this paper. 
10.3 SSL Record Protocol.
The SSL Record Protocol provides two services for SSL connections:
â™¦ Confidentiality: The Handshake Protocol defines a shared secret key,
used to encrypt the data in SSL.
â™¦ Integrity: The Handshake Protocol also establishes a shared secret key used to create MAC of all messages exchanged.
The SSL Record Protocol receives data from higher levels and protocols dealing with fragmentation (fragmentation), compression, authentication and data encryption. Essentially, this protocol converts data in order to transmit in SSL packets.
Figure 10.2 shows the operation of the SSL Record Protocol.
Specifically, the Record Protocol takes the application message to be transmitted and segments the data into manageable blocks, optionally compresses the data through appropriate mechanisms that pass the "handshake" and then applies a MAC over the compressed data. It then encrypts the result using symmetric encryption, SSL adds a header and finally transmits the packet. This method of compression and encryption algorithm is determined during the execution of the SSL Handshake Protocol.
Figure 10-1: Operation of the SSL Record Protocol.
The SSL Record Protocol performs the reverse process for the received packets. Specifically, the decoded data are obtained, confirmed, unpacked and gathered in order to be distributed to users of the higher levels.
Various protocols can be layered on top of the SSL Record Protocol. The SSL 3.0 specifications define the following three SSL protocols:
ô€‚ƒ Alert Protocol
ô€‚ƒ handshake protocol - SSL Handshake Protocol.
ô€‚ƒ SSL Spec Change Cipher Protocol.
The SSL Alert Protocol is used to convey warnings (alerts) via the SSL Record Protocol. Warnings usually signals problems and mistakes (eg wrong MAC "," unexpected message ", etc.) for both the connection and transmission of messages between two peer entities. In this way SSL is alerted to stop the connection or take any other preset action. The SSL Handshake Protocol is the main SSL protocol. The standard change encryption protocol is simpler than the above protocols. It is used to change a standard encryption to another. Normally a standard encryption changes at the end of an SSL handshake. But it can be amended at any time.
10.4 SSL Handshake Protocol.
The SSL Handshake Protocol is the most complex protocol used by the SSL. This optional protocol allows the client and server to verify the identity of one another, negotiate the encryption algorithm and compression method, and create a master secret key, which generates the different session keys for authentication and encryption of messages. After the SSL Handshake Protocol, data transferring begins from the SSL Record Protocol.
The SSL Handshake Protocol, creates an SSL session, the client and server exchange the following messages:
1. C â†’ S: Client_Hello
2. S â†’ C: Server_Hello
3. C â†’ S: Certificate
4. S â†’ C: Change_Cipher_Spec
An implementation of SSL Handshake Protocol usually begins with the client and the
server sending a greeting message (hello) to each other. The greeting messages are used for the exchange of additional security features.
In step 1, when a client wants to connect to a server that sends a message Client_Hello. This message includes:
â€¢ The number of the highest SSL version that the client can support (typically
â€¢ A random structure generated by the client, which consists of a
timestamp of 32 bits and a value of 28 byte is produced by a random number generator. The timestamp prevents repeat message attacks.
â€¢ An identity recognition session (session identity ID) that the customer wishes to use for this connection.
â€¢ A list of cipher suites the client supports.
â€¢ A list of compression methods supported by the client.
The identity recognition value indicates a summit between the same client and server whose security parameters the client would like to reuse.
The identity of the session identification may be from a previous connection or any currently active connection. The field of identity recognition session is empty if not available or if the client wants to create new security considerations. The client message via Client_Hello to the server sends a set of environments that supports encryption. Each environment defines a cryptographic exchange key algorithm and an encryption standard. The server chooses a cryptographic environment, if no acceptable choices have been made it will return an error message and terminate the connection. After sending the message Client_Hello, the client waits for a message Server_Hello.
In step 2, the server processes the message Client_Hello and reply a message Server_Hello or an error message.
That Server_Hello message includes:
A server version number (usually the one proposed by the client in the message Client_Hello).
â€¢ A random structure generated by the server, which also consists of a timestamp of 32 bits and a value of 28 byte generated by a random number generator.
â€¢ An identity recognition session (session ID) that corresponds to the connection.
â€¢ A cryptography environment, which was chosen by the server from the list of cryptographic environments supported by the client.
â€¢ A compression method, which was chosen by the server from the list of compression methods supported by the client.
If the identity recognition session within Client_Hello message is not empty, the
server searches for the identity of this in its own memory session. If the identity is found the server is willing to establish a new connection using the same session state, it responds with the same value as the one from the client. Otherwise this field contains a different value, which identifies the new session.
If the server authenticates the session after the message Server_Hello a certificate in a Certificate message will be sent. The type of certificate must be appropriate for the exchange algorithm cryptographic keys chosen environment and is usually an X.509 certificate.
The same message type will be used later to answer the client's message Certificate_Request from the server.
Then the server sends the message Server_Key_Exchange to the client. This message contains the public key of the server, depending on the exchange key algorithm used. The server can optionally request a certificate to authenticate the client. In this case the client sends a Certificate_Request message. The message includes a list of the types of certificates requested, arranged in order of preference server, and a list of acceptable CAs (Certificate Authorities). At the end of step 2 the server sends a message to the client Server_Hello_Done, which indicates the end of message Server_Hello and associated messages. When the message Server_Hello is received along with the associated messages, the client confirms, if necessary, that the server provided a valid certificate and checks the security features contained in Server_Hello message are accepted.
If the server has requested authentication of the client, the client in step 3 sends a Certificate message containing a certificate for public key. Then the client sends a message Client_Key_Exchange, whose form depends on the exchange key algorithm chosen by the server.
If you use the RSA algorithm for authentication and key exchange server, the client generates a pre-owned secret (pre-master secret) of using a 48 byte random number, encrypts it with a temporary RSA public key from the message server and Server_Key_Exchange sends the results back to the server via message Client_Key_Exchange. Server
using its private key to decrypt the pre-main secret. This pre-owned used secret from both the client and the server side to generate the secret key.
The main secret is not used directly for encryption, but to produce two pairs of keys. The couple belongs to a client consists of client-writekey used by the client to encrypt messages to the server and the client-read-key to decrypt it receives from the server. The second
pair belongs to the server and consists of the server-write-key to encrypt messages to the client and the server-read-key for decryption of view.
It should be noted that client-write-key is the same as the server-read-key and client-readkey is the same as the server-write-key.
Then the customer can send a message to the server
Certificate_Verify. This message is used to provide confirmation of the certificate of the client. Eventually the customer completes step 3 Change_Cipher_Spec sending a message and a Finished message to the server. Change_Cipher_Spec message indicates that the client is ready to go to secure communication. The Finished message is always sent immediately after the message to Change_Cipher_Spec
confirmed that the key exchange and authentication procedures for the certification was indeed successful.
The implementation of the SSL Handshake Protocol ends having the server send a message Change_Cipher_Spec and a Finished message to the client in step 4. After completion of the SSL Handshake Protocol, establishes a secure connection between client and server. This connection can now be used for sending application data through the SSL Record Protocol.
10.5 Resistance to known attacks on SSL.
Dictionary Attack (Dictionary Attack).
During the attack, a portion of unencrypted text is held by people with malicious intent. This section is encrypted using every possible key, and then searched the entire encrypted message until you find a piece that matches any of the budgeted. If the research succeeds, then the key used to encrypt the entire text
been found. SSL is not threatened by this attack since the key algorithms is very large (128 bits). Even the algorithms in exported products, support 128 bits keys and although the 88 bits are transmitted without encryption such, the calculation of 240 different sequences, making the attack very difficult.
Violent Attack (Brute Force Attack).
Â The attack was carried out using all possible keys to decrypt messages. The biggest long keys are used, the more are the possible keys. Such an attack on algorithms that use keys of 128 bits is futile.
Replay (Replay Attack).
When a third record the exchange of messages between client - server and tries to reuse the messages of the customer to access the server, we attack type of replay attack. But the use of SSL session ID (connection-ID), which is produced by the server at random and differs
for each connection. So it is not possible when there are two same login ID.
Offensive Interference (Man-In-The-Middle-Attack).
The attack on Man-In-The-Middle-Attack occurs when one party is able to
inserted in the communication between server and client. After processing the messages of the client and modify as desired, to promote the server.
Nor does the messages from the server. That is, pretending that the client is the server and vice versa.
The SSL requires the server to prove identity using a valid certificate of which the change is impossible .