THE SSL PROTOCOL

Status of this Memo
　　This is a DRAFT specification.
　　This RFC specifies a security protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Abstract
　　This document specifies the Secure Sockets Layer (SSL) protocol, a security protocol that provides privacy over the Internet. The protocol allows client/server applications to communicate in a way that cannot be eavesdropped. Server's are always authenticated and clients are optionally authenticated.

Motivation
　　The SSL Protocol is designed to provide privacy between two communicating applications (a client and a server). Second, the protocol is designed to authenticate the server, and optionally the client. SSL requires a reliable transport protocol (e.g. TCP) for data transmission and reception.
The advantage of the SSL Protocol is that it is application protocol independent. A "higher level" application protocol (e.g. HTTP, FTP, TELNET, etc.) can layer on top of the SSL Protocol transparently. The SSL Protocol can negotiate an encryption algorithm and session key as well as authenticate a server before the application protocol transmits or receives its first byte of data. All of the application protocol data is transmitted encrypted, ensuring privacy.

　　The SSL protocol provides "channel security" which has three basic properties:

　　　＊The channel is private. Encryption is used for all messages after a simple handshake is used to define a secret key.

　　�。猅he channel is authenticated. The server endpoint of the conversation is always authenticated, while the client endpoint is optionally authenticated.

　　　＊ The channel is reliable. The message transport includes a message integrity check (using a MAC).

1. SSL Record Protocol Specification

1.1 SSL Record Header Format

　　In SSL, all data sent is encapsulated in a record, an object which is composed of a header and some non-zero amount of data. Each record header contains a two or three byte length code. If the most significant bit is set in the first byte of the record length code then the record has no padding and the total header length will be 2 bytes, otherwise the record has padding and the total header length will be 3 bytes. The record header is transmitted before the data portion of the record.

　　Note that in the long header case (3 bytes total), the second most significant bit in the first byte has special meaning. When zero, the record being sent is a data record. When one, the record being sent is a security escape (there are currently no examples of security escapes; this is reserved for future versions of the protocol). In either case, the length code describes how much data is in the record.

　　The record length code does not include the number of bytes consumed by the record header (2 or 3). For the 2 byte header, the record length is computed by (using a "C"-like notation):

　　RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1];

　　Where byte[0] represents the first byte received and byte[1] the second byte received. When the 3 byte header is used, the record length is computed as follows (using a "C"-like notation):

　　RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];
　　IS-ESCAPE = (byte[0] & 0x40) != 0;
　　PADDING = byte[2];

　　The record header defines a value called PADDING. The PADDING value specifies how many bytes of data were appended to the original record by the sender. The padding data is used to make the record length be a multiple of the block ciphers block size when a block cipher is used for encryption.
The sender of a "padded" record appends the padding data to the end of its normal data and then encrypts the total amount (which is now a multiple of the block cipher's block size). The actual value of the padding data is unimportant, but the encrypted form of it must be transmitted for the receiver to properly decrypt the record. Once the total amount being transmitted is known the header can be properly constructed with the PADDING value set appropriately.

　　The receiver of a padded record decrypts the entire record data (sans record length and the optional padding) to get the clear data, then subtracts the PADDING value from the RECORD-LENGTH to determine the final RECORD-LENGTH. The clear form of the padding data must be discarded.

更多軟考資料請訪問：考試吧軟件水平考試欄目

希望與更多網(wǎng)友交流，請進入考試吧軟件水平考試論壇