mirror of https://github.com/lianthony/NT4.0
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1792 lines
67 KiB
1792 lines
67 KiB
<TITLE>The SSL Protocol</TITLE>
|
|
|
|
<CENTER>
|
|
|
|
<A HREF="/index.html">
|
|
<IMG SRC="images/standards_ban.gif" WIDTH=468 HEIGHT=32 BORDER=0></A>
|
|
|
|
<H2>
|
|
<FONT SIZE=+3>T</FONT>HE
|
|
<FONT SIZE=+3>SSL P</FONT>ROTOCOL
|
|
</H2>
|
|
</CENTER>
|
|
|
|
|
|
<P>
|
|
|
|
If you have questions about this specification or would like to send us
|
|
your comments please send email to <a href=mailto:[email protected]>[email protected]</a>.
|
|
You can subscribe to this mailing list by sending email to
|
|
<a href=mailto:[email protected]>[email protected]</a> and putting the word "<b>subscribe</b>" into the
|
|
subject line or the body of the message.
|
|
<P>
|
|
The SSL protocol has been submitted to the IETF as an <a
|
|
href="gopher://ds.internic.net:70/00/internet-drafts/draft-hickman-netscape-
|
|
ssl-00.txt"><B>Internet
|
|
Draft</B></a>. Netscape is actively pursuing the standardization of SSL within
|
|
the framework of the IETF standards process and is also working with industry
|
|
consortium groups to ensure that open and interoperable security standards
|
|
exist now and in the future. If you would like to send us questions, comments
|
|
or support during this process please send mail to <A
|
|
HREF="mailto:[email protected]">[email protected]</A>.
|
|
<P>
|
|
|
|
Netscape has developed an <A HREF="/newsref/std/sslref.html">SSL reference implementation</A> called
|
|
SSLRef. Written in ANSI C and free for noncommercial use, SSLRef
|
|
is now available please see here for full details.
|
|
<P>
|
|
|
|
<HR SIZE=4>
|
|
|
|
<P>
|
|
<B>
|
|
T<FONT SIZE=-1>HIS</FONT> P<FONT SIZE=-1>ROTOCOL</FONT>
|
|
S<FONT SIZE=-1>PECIFICATION</FONT> W<FONT SIZE=-1>AS</FONT>
|
|
R<FONT SIZE=-1>EVISED</FONT> O<FONT SIZE=-1>N</FONT>
|
|
N<FONT SIZE=-1>OVEMBER</FONT> 29<FONT SIZE=-1>TH,</FONT> 1994:
|
|
</B>
|
|
<P>
|
|
|
|
<UL>
|
|
|
|
<LI>a fundamental correction to the client-certificate authentication
|
|
protocol,
|
|
|
|
<LI>the removal of the username/password messages,
|
|
|
|
<LI>corrections in some of the cryptographic terminology,
|
|
|
|
<LI>the addition of a MAC to the messages [see section 1.2],
|
|
|
|
<LI>the allowance for different kinds of message digest algorithms.
|
|
|
|
</UL>
|
|
<B>
|
|
T<FONT SIZE=-1>HIS</FONT> D<FONT SIZE=-1>OCUMENT</FONT>
|
|
W<FONT SIZE=-1>AS</FONT> R<FONT SIZE=-1>EVISED</FONT>
|
|
O<FONT SIZE=-1>N</FONT> D<FONT SIZE=-1>ECEMBER</FONT>
|
|
22<FONT SIZE=-1>ND,</FONT> 1994:
|
|
</B>
|
|
<P>
|
|
|
|
|
|
<UL>
|
|
|
|
<LI>The spec now defines the order the clear key data and secret key
|
|
data are combined to produce the master key.
|
|
|
|
<LI>The spec now explicitly states the size of the MAC instead of making
|
|
the reader figure it out.
|
|
|
|
<LI>The spec is more clear on the actual values used to produce the
|
|
session read and write keys.
|
|
|
|
<LI>The spec is more clear on how many bits of the session key are used
|
|
after they are produced from the hash function.
|
|
|
|
</UL>
|
|
|
|
<B>
|
|
T<FONT SIZE=-1>HIS</FONT> D<FONT SIZE=-1>OCUMENT</FONT>
|
|
W<FONT SIZE=-1>AS</FONT> R<FONT SIZE=-1>EVISED</FONT>
|
|
O<FONT SIZE=-1>N</FONT> J<FONT SIZE=-1>ANUARY</FONT>
|
|
17<FONT SIZE=-1>TH,</FONT> 1995:
|
|
</B>
|
|
<P>
|
|
|
|
<UL>
|
|
|
|
<LI>Defined the category to be informational.
|
|
|
|
<LI>Clarified ordering of data elements in various places.
|
|
|
|
<LI>Defined DES-CBC cipher kind and key construction.
|
|
|
|
<LI>Defined DES-EDE3-CBC cipher kind and key construction.
|
|
|
|
</UL>
|
|
|
|
<B>
|
|
T<FONT SIZE=-1>HIS</FONT> D<FONT SIZE=-1>OCUMENT</FONT>
|
|
W<FONT SIZE=-1>AS</FONT> R<FONT SIZE=-1>EVISED</FONT>
|
|
O<FONT SIZE=-1>N</FONT> J<FONT SIZE=-1>ANUARY</FONT>
|
|
24<FONT SIZE=-1>TH,</FONT> 1995:
|
|
</B>
|
|
<P>
|
|
|
|
<UL>
|
|
|
|
<LI>Fixed bug in definition of <TT>CIPHER-CHOICE</TT> in
|
|
<TT>CLIENT-MASTER-KEY</TT> message. The previous spec erroneously
|
|
indicated that the <TT>CIPHER-CHOICE</TT> was an index into the
|
|
servers <TT>CIPHER-SPECS-DATA</TT> array, when it was actually
|
|
supposed to be the <TT>CIPHER-KIND</TT> value chosen by the client.
|
|
|
|
<LI>Clarified the values of the <TT>KEY-ARG-DATA</TT>.
|
|
|
|
</UL>
|
|
<B>
|
|
T<FONT SIZE=-1>HIS</FONT> D<FONT SIZE=-1>OCUMENT</FONT>
|
|
W<FONT SIZE=-1>AS</FONT> R<FONT SIZE=-1>EVISED</FONT>
|
|
O<FONT SIZE=-1>N</FONT> F<FONT SIZE=-1>EBRUARY</FONT>
|
|
9<FONT SIZE=-1>TH,</FONT> 1995:
|
|
</B>
|
|
<P>
|
|
|
|
|
|
<UL>The spec has been clarified to indicate the byte order of sequence
|
|
numbers when they are being applied to the MAC hash function.
|
|
|
|
<LI>The spec now defines the acceptable length range of the
|
|
<TT>CONNECTION-ID</TT> parameter (sent by the server in the
|
|
<TT>SERVER-HELLO</TT> message).
|
|
|
|
<LI>Simplified the specification of the <TT>CIPHER-KIND</TT> data.
|
|
The spec language has been changed yet the format remains compatible
|
|
with all existing implementations. The <TT>CIPHER-KIND</TT>
|
|
information is now a three byte value which defines the type of cipher
|
|
and the length of the key. The key length is no longer separable from
|
|
the <TT>CIPHER-KIND</TT>.
|
|
|
|
<LI>Explained how the <TT>KEY-ARG-DATA</TT> is retained with the
|
|
<TT>SESSION-ID</TT> when the session-identifier cache is used.
|
|
|
|
</UL>
|
|
|
|
<HR SIZE=8>
|
|
|
|
<BODY>
|
|
<PRE>
|
|
Experimental Kipp E.B. Hickman
|
|
Request For Comments: XXXX Netscape Communications Corp.
|
|
Category: Informational Last Update: Feb. 9th, 1995
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
<center>The SSL Protocol</center> <P>
|
|
|
|
<H3>Status of this Memo</H3>
|
|
<DL>
|
|
<DD>
|
|
This is a <B>DRAFT</B> specification. <P>
|
|
|
|
This RFC specifies a security protocol for the Internet community, and
|
|
requests discussion and suggestions for improvements. Distribution of
|
|
this memo is unlimited.
|
|
|
|
</DL>
|
|
<H3>Abstract</H3>
|
|
<DL><DD>
|
|
|
|
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. <P>
|
|
|
|
</DL>
|
|
<H3>Motivation</H3>
|
|
<DL><DD>
|
|
|
|
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. <P>
|
|
|
|
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. <P>
|
|
|
|
The SSL protocol provides "channel security" which has three basic
|
|
properties: <P>
|
|
|
|
<UL TYPE=disc>
|
|
|
|
<LI>The channel is private. Encryption is used for all messages after
|
|
a simple handshake is used to define a secret key. <P>
|
|
|
|
<LI>The channel is authenticated. The server endpoint of the
|
|
conversation is always authenticated, while the client endpoint is
|
|
optionally authenticated. <P>
|
|
|
|
<LI>The channel is reliable. The message transport includes a message
|
|
integrity check (using a MAC).
|
|
|
|
</UL>
|
|
|
|
</DL>
|
|
<H3>1. SSL Record Protocol Specification</H3>
|
|
<DL><DD>
|
|
|
|
<H4>1.1 SSL Record Header Format</H4>
|
|
|
|
In SSL, all data sent is encapsulated in a <B>record</B>, 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. <P>
|
|
|
|
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.
|
|
<P>
|
|
|
|
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): <P>
|
|
|
|
<PRE>
|
|
RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1];
|
|
</PRE>
|
|
|
|
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): <P>
|
|
|
|
<PRE>
|
|
RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];
|
|
IS-ESCAPE = (byte[0] & 0x40) != 0;
|
|
PADDING = byte[2];
|
|
</PRE>
|
|
|
|
The record header defines a value called <tt>PADDING</tt>. The
|
|
<TT>PADDING</TT> 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. <P>
|
|
|
|
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 <TT>PADDING</TT> value set appropriately. <P>
|
|
|
|
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 <TT>PADDING</TT> value from the <TT>RECORD-LENGTH</TT>
|
|
to determine the final <TT>RECORD-LENGTH</TT>. The clear form of the
|
|
padding data must be discarded. <P>
|
|
|
|
<H4>1.2 SSL Record Data Format</H4>
|
|
|
|
The data portion of an SSL record is composed of three components
|
|
(transmitted and received in the order shown): <P>
|
|
|
|
<PRE>
|
|
MAC-DATA[MAC-SIZE]
|
|
ACTUAL-DATA[N]
|
|
PADDING-DATA[PADDING]
|
|
</PRE>
|
|
|
|
<TT>ACTUAL-DATA</TT> is the actual data being transmitted (the message
|
|
payload). <TT>PADDING-DATA</TT> is the padding data sent when a block
|
|
cipher is used and padding is needed. Finally, <TT>MAC-DATA</TT> is
|
|
the <I>Message Authentication Code</I>. <P>
|
|
|
|
When SSL records are sent in the clear, no cipher is used.
|
|
Consequently the amount of <TT>PADDING-DATA</TT> will be zero and the
|
|
amount of <TT>MAC-DATA</TT> will be zero. When encryption is in
|
|
effect, the <TT>PADDING-DATA</TT> will be a function of the cipher
|
|
block size. The <TT>MAC-DATA</TT> is a function of the
|
|
<TT>CIPHER-CHOICE</TT> (more about that later). <P>
|
|
|
|
The <TT>MAC-DATA</TT> is computed as follows: <P>
|
|
|
|
<PRE>
|
|
MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]
|
|
</PRE>
|
|
|
|
Where the <TT>SECRET</TT> data is fed to the hash function first,
|
|
followed by the <TT>ACTUAL-DATA</TT>, which is followed by the
|
|
<TT>PADDING-DATA</TT> which is finally followed by the
|
|
<TT>SEQUENCE-NUMBER</TT>. The <TT>SEQUENCE-NUMBER</TT> is a 32 bit
|
|
value which is presented to the hash function as four bytes, with the
|
|
first byte being the most significant byte of the sequence number, the
|
|
second byte being the next most significant byte of the sequence
|
|
number, the third byte being the third most significant byte, and the
|
|
fourth byte being the least significant byte (that is, in network byte
|
|
order or "big endian" order). <P>
|
|
|
|
<TT>MAC-SIZE</TT> is a function of the digest algorithm being
|
|
used. For MD2 and MD5 the <TT>MAC-SIZE</TT> will be 16 bytes (128
|
|
bits). <P>
|
|
|
|
The <TT>SECRET</TT> value is a function of which party is sending the
|
|
message. If the client is sending the message then the <TT>SECRET</TT>
|
|
is the <TT>CLIENT-WRITE-KEY</TT> (the server will use the
|
|
<TT>SERVER-READ-KEY</TT> to verify the MAC). If the client is
|
|
receiving the message then the <TT>SECRET</TT> is the
|
|
<TT>CLIENT-READ-KEY</TT> (the server will use the
|
|
<TT>SERVER-WRITE-KEY</TT> to generate the MAC). <P>
|
|
|
|
The <TT>SEQUENCE-NUMBER</TT> is a counter which is incremented by both
|
|
the sender and the receiver. For each transmission direction, a pair
|
|
of counters is kept (one by the sender, one by the receiver). Every
|
|
time a message is sent by a sender the counter is incremented.
|
|
Sequence numbers are 32 bit unsigned quantities and must wrap to zero
|
|
after incrementing past 0xFFFFFFFF. <P>
|
|
|
|
The receiver of a message uses the expected value of the sequence
|
|
number as input into the MAC <TT>HASH</TT> function (the <TT>HASH</TT>
|
|
function is chosen from the <TT>CIPHER-CHOICE</TT>). The computed
|
|
<TT>MAC-DATA</TT> must agree bit for bit with the transmitted
|
|
<TT>MAC-DATA</TT>. If the comparison is not identity then the record
|
|
is considered damaged, and it is to be treated as if an "I/O Error"
|
|
had occurred (i.e. an unrecoverable error is asserted and the
|
|
connection is closed). <P>
|
|
|
|
A final consistency check is done when a block cipher is used and the
|
|
protocol is using encryption. The amount of data present in a record
|
|
(<TT>RECORD-LENGTH)</TT>)must be a multiple of the cipher's block
|
|
size. If the received record is not a multiple of the cipher's block
|
|
size then the record is considered damaged, and it is to be treated as
|
|
if an "I/O Error" had occurred (i.e. an unrecoverable error is asserted
|
|
and the connection is closed). <P>
|
|
|
|
The SSL Record Layer is used for all SSL communications, including
|
|
handshake messages, security escapes and application data
|
|
transfers. The SSL Record Layer is used by both the client and the
|
|
server at all times. <P>
|
|
|
|
For a two byte header, the maximum record length is 32767 bytes. For
|
|
the three byte header, the maximum record length is 16383 bytes. The
|
|
SSL Handshake Protocol messages are constrained to fit in a single SSL
|
|
Record Protocol record. Application protocol messages are allowed to
|
|
consume multiple SSL Record Protocol record's. <P>
|
|
|
|
Before the first record is sent using SSL all sequence numbers are
|
|
initialized to zero. The transmit sequence number is incremented after
|
|
every message sent, starting with the <TT>CLIENT-HELLO</TT> and
|
|
<TT>SERVER-HELLO</TT> messages. <P>
|
|
|
|
</DL>
|
|
<H3>2. SSL Handshake Protocol Specification</H3>
|
|
<DL><DD>
|
|
|
|
<H4>2.1 SSL Handshake Protocol Flow</H4>
|
|
<DL><DD>
|
|
|
|
The SSL Handshake Protocol has two major phases. The first phase is
|
|
used to establish private communications. The second phase is used for
|
|
client authentication. <P>
|
|
|
|
<H4>Phase 1</H4>
|
|
|
|
The first phase is the initial connection phase where both parties
|
|
communicate their "hello" messages. The client initiates the
|
|
conversation by sending the <TT>CLIENT-HELLO</TT> message. The server
|
|
receives the <TT>CLIENT-HELLO</TT> message and processes it responding
|
|
with the <TT>SERVER-HELLO</TT> message. <P>
|
|
|
|
At this point both the client and server have enough information to
|
|
know whether or not a new master key is needed. When a new master
|
|
key is not needed, both the client and the server proceed immediately
|
|
to phase 2. <P>
|
|
|
|
When a new master key is needed, the <TT>SERVER-HELLO</TT> message
|
|
will contain enough information for the client to generate it. This
|
|
includes the server's signed certificate (more about that later), a
|
|
list of bulk cipher specifications (see below), and a connection-id (a
|
|
connection-id is a randomly generated value generated by the server
|
|
that is used by the client and server during a single connection).
|
|
The client generates the master key and responds with a
|
|
<TT>CLIENT-MASTER-KEY</TT> message (or an <TT>ERROR</TT> message if
|
|
the server information indicates that the client and server cannot
|
|
agree on a bulk cipher). <P>
|
|
|
|
It should be noted here that each SSL endpoint uses a pair of ciphers
|
|
per connection (for a total of four ciphers). At each endpoint, one
|
|
cipher is used for outgoing communications, and one is used for
|
|
incoming communications. When the client or server generate a session
|
|
key, they actually generate two keys, the <TT>SERVER-READ-KEY</TT>
|
|
(also known as the <TT>CLIENT-WRITE-KEY</TT>) and the
|
|
<TT>SERVER-WRITE-KEY</TT> (also known as the
|
|
<TT>CLIENT-READ-KEY</TT>). The master key is used by the client and
|
|
server to generate the various session keys (more about that
|
|
later). <P>
|
|
|
|
Finally, the server sends a <TT>SERVER-VERIFY</TT> message to the
|
|
client after the master key has been determined. This final step
|
|
authenticates the server, because only a server which has the
|
|
appropriate public key can know the master key. <P>
|
|
|
|
<H4>Phase 2</H4>
|
|
|
|
The second phase is the authentication phase. The server has already
|
|
been authenticated by the client in the first phase, so this phase is
|
|
primarily used to authenticate the client. In a typical scenario, the
|
|
server will require something from the client and send a request. The
|
|
client will answer in the positive if it has the needed information,
|
|
or send an <TT>ERROR</TT> message if it does not. This protocol
|
|
specification does not define the semantics of an <TT>ERROR</TT>
|
|
response to a server request (e.g., an implementation can ignore the
|
|
error, close the connection, etc. and still conform to this
|
|
specification). <P>
|
|
|
|
When a party is done authenticating the other party, it sends its
|
|
<B>finished</B> message. For the client, the <TT>CLIENT-FINISHED</TT>
|
|
message contains the encrypted form of the <TT>CONNECTION-ID</TT> for
|
|
the server to verify. If the verification fails, the server sends an
|
|
ERROR message. <P>
|
|
|
|
Once a party has sent its <B>finished</B> message it must continue to
|
|
listen to its peers messages until it too receives a <B>finished</B>
|
|
message. Once a party has both sent a finished message and received
|
|
its peers finished message, the SSL handshake protocol is done. At
|
|
this point the application protocol begins to operate (Note: the
|
|
application protocol continues to be layered on the SSL Record
|
|
Protocol). <P>
|
|
|
|
</DL>
|
|
<H4>2.2 Typical Protocol Message Flow</H4>
|
|
<DL><DD>
|
|
|
|
The following sequences define several typical protocol message flows
|
|
for the SSL Handshake Protocol. In these examples we have two
|
|
principals in the conversation: the client and the server. We use a
|
|
notation commonly found in the literature [10]. When something is enclosed
|
|
in curly braces "{something}key" then the something has been encrypted
|
|
using "key". <P>
|
|
|
|
<H4>2.2.1 Assuming no session-identifier</H4>
|
|
|
|
<PRE>
|
|
client-hello C -> S: challenge, cipher_specs
|
|
server-hello S -> C: connection-id,server_certificate,cipher_specs
|
|
client-master-key C -> S: {master_key}server_public_key
|
|
client-finish C -> S: {connection-id}client_write_key
|
|
server-verify S -> C: {challenge}server_write_key
|
|
server-finish S -> C: {new_session_id}server_write_key
|
|
</PRE>
|
|
|
|
<H4>2.2.2 Assuming a session-identifier was found by both client &
|
|
server</H4>
|
|
|
|
<PRE>
|
|
client-hello C -> S: challenge, session_id, cipher_specs
|
|
server-hello S -> C: connection-id, session_id_hit
|
|
client-finish C -> S: {connection-id}client_write_key
|
|
server-verify S -> C: {challenge}server_write_key
|
|
server-finish S -> C: {session_id}server_write_key
|
|
</PRE>
|
|
|
|
<H4>2.2.3 Assuming a session-identifier was used and client
|
|
authentication is used</H4>
|
|
|
|
<PRE>
|
|
client-hello C -> S: challenge, session_id, cipher_specs
|
|
server-hello S -> C: connection-id, session_id_hit
|
|
client-finish C -> S: {connection-id}client_write_key
|
|
server-verify S -> C: {challenge}server_write_key
|
|
request-certificate S -> C: {auth_type,challenge'}server_write_key
|
|
client-certificate C -> S: {cert_type,client_cert,
|
|
response_data}client_write_key
|
|
server-finish S -> C: {session_id}server_write_key
|
|
</PRE>
|
|
|
|
In this last exchange, the <B>response_data</B> is a function of the
|
|
<B>auth_type</B>. <P>
|
|
|
|
</DL>
|
|
<H4>2.3 Errors</H4>
|
|
<DL><DD>
|
|
|
|
Error handling in the SSL connection protocol is very simple. When an
|
|
error is detected, the detecting party sends a message to the other
|
|
party. Errors that are not recoverable cause the client and server to
|
|
abort the secure connection. Servers and client are required to
|
|
"forget" any session-identifiers associated with a failing
|
|
connection. <P>
|
|
|
|
The SSL Handshake Protocol defines the following errors: <P>
|
|
|
|
<DL>
|
|
|
|
<DT> NO-CIPHER-ERROR
|
|
|
|
<DD> This error is returned by the client to the server when it cannot
|
|
find a cipher or key size that it supports that is also supported by the
|
|
server. This error is not recoverable. <P>
|
|
|
|
<DT> NO-CERTIFICATE-ERROR
|
|
|
|
<DD> When a REQUEST-CERTIFICATE message is sent, this error may
|
|
be returned if the client has no certificate to reply with.
|
|
This error is recoverable (for client authentication only). <P>
|
|
|
|
<DT> BAD-CERTIFICATE-ERROR
|
|
|
|
<DD> This error is returned when a certificate is deemed bad by the
|
|
receiving party. Bad means that either the signature of the
|
|
certificate was bad or that the values in the certificate were
|
|
inappropriate (e.g. a name in the certificate did not match the
|
|
expected name). This error is recoverable (for client authentication
|
|
only). <P>
|
|
|
|
<DT> UNSUPPORTED-CERTIFICATE-TYPE-ERROR
|
|
|
|
<DD> This error is returned when a client/server receives a
|
|
certificate type that it can't support. This error is recoverable (for
|
|
client authentication only). <P>
|
|
|
|
</DL>
|
|
|
|
</DL>
|
|
<H4>2.4 SSL Handshake Protocol Messages</H4>
|
|
<DL><DD>
|
|
|
|
The SSL Handshake Protocol messages are encapsulated in the SSL Record
|
|
Protocol and are composed of two parts: a single byte message type
|
|
code, and some data. The client and server exchange messages until
|
|
both ends have sent their "finished" message, indicating that they are
|
|
satisfied with the SSL Handshake Protocol conversation. While one end
|
|
may be finished, the other may not, therefore the finished end must
|
|
continue to receive SSL Handshake Protocol messages until it too
|
|
receives a "finished" message. <P>
|
|
|
|
After the pair of session keys has been determined by each party, the
|
|
message bodies are encrypted using it. For the client, this happens
|
|
after it verifies the session-identifier or creates a new session key
|
|
and has sent it to the server. For the server, this happens after the
|
|
session-identifier is found to be good, or the server receives the
|
|
client's session key message. <P>
|
|
|
|
The following notation is used for SSLHP messages:
|
|
|
|
<PRE>
|
|
char MSG-EXAMPLE
|
|
char FIELD1
|
|
char FIELD2
|
|
char THING-MSB
|
|
char THING-LSB
|
|
char THING-DATA[(MSB<<8)|LSB];
|
|
...
|
|
</PRE>
|
|
|
|
This notation defines the data in the protocol message, including the
|
|
message type code. The order is presented top to bottom, with the top
|
|
most element being transmitted first, and the bottom most element
|
|
transferred last. <P>
|
|
|
|
For the "THING-DATA" entry, the MSB and LSB values are actually
|
|
THING-MSB and THING-LSB (respectively) and define the number of bytes
|
|
of data actually present in the message. For example, if THING-MSB
|
|
were zero and THING-LSB were 8 then the THING-DATA array would be
|
|
exactly 8 bytes long. This shorthand is used below. <P>
|
|
|
|
Length codes are unsigned values, and when the MSB and LSB are
|
|
combined the result is an unsigned value. Unless otherwise specified
|
|
lengths values are "length in bytes". <P>
|
|
|
|
</DL>
|
|
<H4>2.5 Client Only Protocol Messages</H4>
|
|
<DL><DD>
|
|
|
|
There are several messages that are only generated by clients. These
|
|
messages are never generated by correctly functioning servers. A
|
|
client receiving such a message closes the connection to the server
|
|
and returns an error status to the application through some
|
|
unspecified mechanism. <P>
|
|
|
|
<H4>CLIENT-HELLO (Phase 1; Sent in the clear)</H4>
|
|
|
|
<PRE>
|
|
char MSG-CLIENT-HELLO
|
|
char CLIENT-VERSION-MSB
|
|
char CLIENT-VERSION-LSB
|
|
char CIPHER-SPECS-LENGTH-MSB
|
|
char CIPHER-SPECS-LENGTH-LSB
|
|
char SESSION-ID-LENGTH-MSB
|
|
char SESSION-ID-LENGTH-LSB
|
|
char CHALLENGE-LENGTH-MSB
|
|
char CHALLENGE-LENGTH-LSB
|
|
char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
|
|
char SESSION-ID-DATA[(MSB<<8)|LSB]
|
|
char CHALLENGE-DATA[(MSB<<8)|LSB]
|
|
</PRE>
|
|
|
|
When a client first connects to a server it is required to send the
|
|
<TT>CLIENT-HELLO</TT> message. The server is expecting this message
|
|
from the client as its first message. It is an error for a client to
|
|
send anything else as its first message. <P>
|
|
|
|
The client sends to the server its SSL version, its cipher specs (see
|
|
below), some challenge data, and the session-identifier data. The
|
|
session-identifier data is only sent if the client found a
|
|
session-identifier in its cache for the server, and the
|
|
<TT>SESSION-ID-LENGTH</TT> will be non-zero. When there is no
|
|
session-identifier for the server <TT>SESSION-ID-LENGTH</TT> must be
|
|
zero. The challenge data is used to authenticate the server. After the
|
|
client and server agree on a pair of session keys, the server returns
|
|
a <TT>SERVER-VERIFY</TT> message with the encrypted form of the
|
|
<TT>CHALLENGE-DATA</TT>. <P>
|
|
|
|
Also note that the server will not send its <TT>SERVER-HELLO</TT>
|
|
message until it has received the <TT>CLIENT-HELLO</TT> message. This
|
|
is done so that the server can indicate the status of the client's
|
|
session-identifier back to the client in the server's first message
|
|
(i.e. to increase protocol efficiency and reduce the number of round
|
|
trips required). <P>
|
|
|
|
The server examines the <TT>CLIENT-HELLO</TT> message and will verify
|
|
that it can support the client version and one of the client cipher
|
|
specs. The server can optionally edit the cipher specs, removing any
|
|
entries it doesn't choose to support. The edited version will be
|
|
returned in the <TT>SERVER-HELLO</TT> message if the
|
|
session-identifier is not in the server's cache. <P>
|
|
|
|
The <TT>CIPHER-SPECS-LENGTH</TT> must be greater than zero and a
|
|
multiple of 3. The <TT>SESSION-ID-LENGTH</TT> must either be zero or
|
|
16. The <TT>CHALLENGE-LENGTH</TT> must be greater than or equal to 16
|
|
and less than or equal to 32. <P>
|
|
|
|
This message must be the first message sent by the client to the
|
|
server. After the message is sent the client waits for a
|
|
<TT>SERVER-HELLO</TT> message. Any other message returned by the
|
|
server (other than <TT>ERROR</TT>) is disallowed. <P>
|
|
|
|
<H4>CLIENT-MASTER-KEY (Phase 1; Sent primarily in the clear)</H4>
|
|
|
|
<PRE>
|
|
char MSG-CLIENT-MASTER-KEY
|
|
char CIPHER-KIND[3]
|
|
char CLEAR-KEY-LENGTH-MSB
|
|
char CLEAR-KEY-LENGTH-LSB
|
|
char ENCRYPTED-KEY-LENGTH-MSB
|
|
char ENCRYPTED-KEY-LENGTH-LSB
|
|
char KEY-ARG-LENGTH-MSB
|
|
char KEY-ARG-LENGTH-LSB
|
|
char CLEAR-KEY-DATA[MSB<<8|LSB]
|
|
char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
|
|
char KEY-ARG-DATA[MSB<<8|LSB]
|
|
</PRE>
|
|
|
|
The client sends this message when it has determined a master key for
|
|
the server to use. Note that when a session-identifier has been agreed
|
|
upon, this message is not sent. <P>
|
|
|
|
The <TT>CIPHER-KIND</TT> field indicates which cipher was chosen
|
|
from the server's <TT>CIPHER-SPECS</TT>. <P>
|
|
|
|
The <TT>CLEAR-KEY-DATA</TT> contains the clear portion of the
|
|
<TT>MASTER-KEY</TT>. The <TT>CLEAR-KEY-DATA</TT> is combined with the
|
|
<TT>SECRET-KEY-DATA</TT> (described shortly) to form the
|
|
<TT>MASTER-KEY</TT>, with the <TT>SECRET-KEY-DATA</TT> being the least
|
|
significant bytes of the final <TT>MASTER-KEY</TT>.
|
|
|
|
The <TT>ENCRYPTED-KEY-DATA</TT> contains the secret portions of the
|
|
<TT>MASTER-KEY</TT>, encrypted using the server's public key. The
|
|
encryption block is formatted using block type 2 from PKCS#1 [5]. The
|
|
data portion of the block is formatted as follows: <P>
|
|
|
|
<PRE>
|
|
char SECRET-KEY-DATA[SECRET-LENGTH]
|
|
</PRE>
|
|
|
|
<TT>SECRET-LENGTH</TT> is the number of bytes of each session key that
|
|
is being transmitted encrypted. The <TT>SECRET-LENGTH</TT> plus the
|
|
<TT>CLEAR-KEY-LENGTH</TT> equals the number of bytes present in the
|
|
cipher key (as defined by the <TT>CIPHER-KIND</TT>). It is an error if
|
|
the <TT>SECRET-LENGTH</TT> found after decrypting the PKCS#1 formatted
|
|
encryption block doesn't match the expected value. It is also an
|
|
error if <TT>CLEAR-KEY-LENGTH</TT> is non-zero and the
|
|
<TT>CIPHER-KIND</TT> is not an export cipher. <P>
|
|
|
|
If the key algorithm needs an argument (for example, DES-CBC's
|
|
initialization vector) then the <TT>KEY-ARG-LENGTH</TT> fields will be
|
|
non-zero and the <TT>KEY-ARG-DATA</TT> will contain the relevant
|
|
data. For the <TT>SSL_CK_RC2_128_CBC_WITH_MD5</TT>,
|
|
<TT>SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5</TT>,
|
|
<TT>SSL_CK_IDEA_128_CBC_WITH_MD5</TT>,
|
|
<TT>SSL_CK_DES_64_CBC_WITH_MD5</TT> and
|
|
<TT>SSL_CK_DES_192_EDE3_CBC_WITH_MD5</TT> algorithms the <TT>KEY-ARG</TT>
|
|
data must be present and be exactly 8 bytes long. <P>
|
|
|
|
Client and server session key production is a function of the
|
|
<TT>CIPHER-CHOICE</TT>: <P>
|
|
|
|
<DL>
|
|
<DT> <B>SSL_CK_RC4_128_WITH_MD5</B>
|
|
<DT> <B>SSL_CK_RC4_128_EXPORT40_WITH_MD5</B>
|
|
<DT> <B>SSL_CK_RC2_128_CBC_WITH_MD5</B>
|
|
<DT> <B>SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5</B>
|
|
<DT> <B>SSL_CK_IDEA_128_CBC_WITH_MD5</B>
|
|
|
|
<DD>
|
|
|
|
<PRE>
|
|
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
|
|
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
|
|
|
|
CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
|
|
CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
|
|
</PRE>
|
|
|
|
Where <TT>KEY-MATERIAL-0[0-15]</TT> means the first 16 bytes of the
|
|
<TT>KEY-MATERIAL-0</TT> data, with <TT>KEY-MATERIAL-0[0]</TT> becoming
|
|
the most significant byte of the <TT>CLIENT-READ-KEY</TT>. <P>
|
|
|
|
Data is fed to the MD5 hash function in the order shown, from left to
|
|
right: first the <TT>MASTER-KEY</TT>, then the "0" or "1", then the
|
|
<TT>CHALLENGE</TT> and then finally the <TT>CONNECTION-ID</TT>. <P>
|
|
|
|
Note that the "0" means the ascii zero character (0x30), not a zero
|
|
value. "1" means the ascii 1 character (0x31). MD5 produces 128 bits
|
|
of output data which are used directly as the key to the cipher
|
|
algorithm (The most significant byte of the MD5 output becomes the
|
|
most significant byte of the key material). <P>
|
|
|
|
<DT> <B>SSL_CK_DES_64_CBC_WITH_MD5</B>
|
|
|
|
<DD>
|
|
|
|
<PRE>
|
|
KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]
|
|
|
|
CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
|
|
CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
|
|
</PRE>
|
|
|
|
For DES-CBC, a single 16 bytes of key material are produced using MD5.
|
|
The first 8 bytes of the MD5 digest are used as the
|
|
<TT>CLIENT-READ-KEY</TT> while the remaining 8 bytes are used as the
|
|
<TT>CLIENT-WRITE-KEY</TT>. The initialization vector is provided in
|
|
the <TT>KEY-ARG-DATA</TT>. Note that the raw key data is not parity
|
|
adjusted and that this step must be performed before the keys are
|
|
legitimate DES keys. <P>
|
|
|
|
<DT> <B>SSL_CK_DES_192_EDE3_CBC_WITH_MD5</B>
|
|
|
|
<DD>
|
|
|
|
<PRE>
|
|
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
|
|
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
|
|
KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]
|
|
|
|
CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
|
|
CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
|
|
CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
|
|
CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
|
|
CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
|
|
CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]
|
|
</PRE>
|
|
|
|
Data is fed to the MD5 hash function in the order shown, from left to
|
|
right: first the <TT>MASTER-KEY</TT>, then the "0", "1" or "2", then
|
|
the <TT>CHALLENGE</TT> and then finally the <TT>CONNECTION-ID</TT>. <P>
|
|
|
|
Note that the "0" means the ascii zero character (0x30), not a zero
|
|
value. "1" means the ascii 1 character (0x31). "2" means the ascii 2
|
|
character (0x32). <P>
|
|
|
|
A total of 6 keys are produced, 3 for the read side DES-EDE3 cipher
|
|
and 3 for the write side DES-EDE3 function. The initialization vector
|
|
is provided in the <TT>KEY-ARG-DATA</TT>. The keys that are produced
|
|
are not parity adjusted. This step must be performed before proper DES
|
|
keys are usable. <P>
|
|
|
|
</DL> <P>
|
|
|
|
Recall that the <TT>MASTER-KEY</TT> is given to the server in the
|
|
<TT>CLIENT-MASTER-KEY</TT> message. The <TT>CHALLENGE</TT> is given
|
|
to the server by the client in the <TT>CLIENT-HELLO</TT> message. The
|
|
<TT>CONNECTION-ID</TT> is given to the client by the server in the
|
|
<TT>SERVER-HELLO</TT> message. This makes the resulting cipher keys a
|
|
function of the original session and the current session. Note that
|
|
the master key is never directly used to encrypt data, and therefore
|
|
cannot be easily discovered. <P>
|
|
|
|
The <TT>CLIENT-MASTER-KEY</TT> message must be sent after the
|
|
<TT>CLIENT-HELLO</TT> message and before the <TT>CLIENT-FINISHED</TT>
|
|
message. The <TT>CLIENT-MASTER-KEY</TT> message must be sent if the
|
|
<TT>SERVER-HELLO</TT> message contains a <TT>SESSION-ID-HIT</TT> value
|
|
of 0. <P>
|
|
|
|
<H4>CLIENT-CERTIFICATE (Phase 2; Sent encrypted)</H4>
|
|
|
|
<PRE>
|
|
char MSG-CLIENT-CERTIFICATE
|
|
char CERTIFICATE-TYPE
|
|
char CERTIFICATE-LENGTH-MSB
|
|
char CERTIFICATE-LENGTH-LSB
|
|
char RESPONSE-LENGTH-MSB
|
|
char RESPONSE-LENGTH-LSB
|
|
char CERTIFICATE-DATA[MSB<<8|LSB]
|
|
char RESPONSE-DATA[MSB<<8|LSB]
|
|
</PRE>
|
|
|
|
This message is sent by one an SSL client in response to a server
|
|
<TT>REQUEST-CERTIFICATE</TT> message. The <TT>CERTIFICATE-DATA</TT>
|
|
contains data defined by the <TT>CERTIFICATE-TYPE</TT> value. An
|
|
<TT>ERROR</TT> message is sent with error code
|
|
<TT>NO-CERTIFICATE-ERROR</TT> when this request cannot be answered
|
|
properly (e.g. the receiver of the message has no registered
|
|
certificate). <P>
|
|
|
|
<TT>CERTIFICATE-TYPE</TT> is one of: <P>
|
|
|
|
<DL>
|
|
<DT> <B>SSL_X509_CERTIFICATE</B>
|
|
<DD> The <TT>CERTIFICATE-DATA</TT> contains an X.509 (1988) [3] signed
|
|
certificate. <P>
|
|
</DL>
|
|
|
|
The <TT>RESPONSE-DATA</TT> contains the authentication response data.
|
|
This data is a function of the <TT>AUTHENTICATION-TYPE</TT> value sent
|
|
by the server. <P>
|
|
|
|
When <TT>AUTHENTICATION-TYPE</TT> is
|
|
<TT>SSL_AT_MD5_WITH_RSA_ENCRYPTION</TT> then the
|
|
<TT>RESPONSE-DATA</TT> contains a digital signature of the following
|
|
components (in the order shown): <P>
|
|
|
|
<UL TYPE=disc>
|
|
<LI>the KEY-MATERIAL-0
|
|
<LI>the KEY-MATERIAL-1 (only if defined by the cipher kind)
|
|
<LI>the KEY-MATERIAL-2 (only if defined by the cipher kind)
|
|
<LI>the CERTIFICATE-CHALLENGE-DATA (from the REQUEST-CERTIFICATE message)
|
|
<LI>the server's signed certificate (from the SERVER-HELLO message)
|
|
</UL> <P>
|
|
|
|
The digital signature is constructed using MD5 and then encrypted
|
|
using the clients private key, formatted according to PKCS#1's digital
|
|
signature standard [5]. The server authenticates the client by
|
|
verifying the digital signature using standard techniques. Note that
|
|
other digest functions are supported. Either a new
|
|
<TT>AUTHENTICATION-TYPE</TT> can be added, or the algorithm-id in the
|
|
digital signature can be changed. <P>
|
|
|
|
This message must be sent by the client only in response to a
|
|
<TT>REQUEST-CERTIFICATE</TT> message. <P>
|
|
|
|
<H4>CLIENT-FINISHED (Phase 2; Sent encrypted)</H4>
|
|
|
|
<PRE>
|
|
char MSG-CLIENT-FINISHED
|
|
char CONNECTION-ID[N-1]
|
|
</PRE>
|
|
|
|
The client sends this message when it is satisfied with the server.
|
|
Note that the client must continue to listen for server messages until
|
|
it receives a <TT>SERVER-FINISHED</TT> message. The
|
|
<TT>CONNECTION-ID</TT> data is the original connection-identifier the
|
|
server sent with its <TT>SERVER-HELLO</TT> message, encrypted using
|
|
the agreed upon session key. <P>
|
|
|
|
"<TT>N</TT>" is the number of bytes in the message that was sent, so
|
|
"<TT>N-1</TT>" is the number of bytes in the message without the
|
|
message header byte. <P>
|
|
|
|
For version 2 of the protocol, the client must send this message after
|
|
it has received the <TT>SERVER-HELLO</TT> message. If the
|
|
<TT>SERVER-HELLO</TT> message <TT>SESSION-ID-HIT</TT> flag is non-zero
|
|
then the <TT>CLIENT-FINISHED</TT> message is sent immediately,
|
|
otherwise the <TT>CLIENT-FINISHED</TT> message is sent after the
|
|
<TT>CLIENT-MASTER-KEY</TT> message. <P>
|
|
|
|
</DL>
|
|
<H4>2.6 Server Only Protocol Messages</H4>
|
|
<DL><DD>
|
|
|
|
There are several messages that are only generated by servers. The
|
|
messages are never generated by correctly functioning clients. <P>
|
|
|
|
<H4>SERVER-HELLO (Phase 1; Sent in the clear)</H4>
|
|
|
|
<PRE>
|
|
char MSG-SERVER-HELLO
|
|
char SESSION-ID-HIT
|
|
char CERTIFICATE-TYPE
|
|
char SERVER-VERSION-MSB
|
|
char SERVER-VERSION-LSB
|
|
char CERTIFICATE-LENGTH-MSB
|
|
char CERTIFICATE-LENGTH-LSB
|
|
char CIPHER-SPECS-LENGTH-MSB
|
|
char CIPHER-SPECS-LENGTH-LSB
|
|
char CONNECTION-ID-LENGTH-MSB
|
|
char CONNECTION-ID-LENGTH-LSB
|
|
char CERTIFICATE-DATA[MSB<<8|LSB]
|
|
char CIPHER-SPECS-DATA[MSB<<8|LSB]
|
|
char CONNECTION-ID-DATA[MSB<<8|LSB]
|
|
</PRE>
|
|
|
|
The server sends this message after receiving the clients
|
|
<TT>CLIENT-HELLO</TT> message. The server returns the
|
|
<TT>SESSION-ID-HIT</TT> flag indicating whether or not the received
|
|
session-identifier is known by the server (i.e. in the server's
|
|
session-identifier cache). The <TT>SESSION-ID-HIT</TT> flag will be
|
|
non-zero if the client sent the server a session-identifier (in the
|
|
<TT>CLIENT-HELLO</TT> message with <TT>SESSION-ID-LENGTH</TT> != 0)
|
|
and the server found the client's session-identifier in its cache. If
|
|
the <TT>SESSION-ID-HIT</TT> flag is non-zero then the
|
|
<TT>CERTIFICATE-TYPE</TT>, <TT>CERTIFICATE-LENGTH</TT> and
|
|
<TT>CIPHER-SPECS-LENGTH</TT> fields will be zero. <P>
|
|
|
|
The <TT>CERTIFICATE-TYPE</TT> value, when non-zero, has one of the
|
|
values described above (see the information on the
|
|
<TT>CLIENT-CERTIFICATE</TT> message). <P>
|
|
|
|
When the <TT>SESSION-ID-HIT</TT> flag is zero, the server packages up
|
|
its certificate, its cipher specs and a connection-id to send to the
|
|
client. Using this information the client can generate a session key
|
|
and return it to the server with the <TT>CLIENT-MASTER-KEY</TT>
|
|
message. <P>
|
|
|
|
When the <TT>SESSION-ID-HIT</TT> flag is non-zero, both the server and
|
|
the client compute a new pair of session keys for the current session
|
|
derived from the <TT>MASTER-KEY</TT> that was exchanged when the
|
|
<TT>SESSION-ID</TT> was created. The <TT>SERVER-READ-KEY</TT> and
|
|
<TT>SERVER-WRITE-KEY</TT> are derived from the original
|
|
<TT>MASTER-KEY</TT> keys in the same manner as the <TT>CLIENT-READ-KEY</TT>
|
|
and <TT>CLIENT-WRITE-KEY</TT>:
|
|
|
|
<PRE>
|
|
SERVER-READ-KEY = CLIENT-WRITE-KEY
|
|
SERVER-WRITE-KEY = CLIENT-READ-KEY
|
|
</PRE>
|
|
|
|
Note that when keys are being derived and the <TT>SESSION-ID-HIT</TT>
|
|
flag is set and the server discovers the client's session-identifier
|
|
in the servers cache, then the <TT>KEY-ARG-DATA</TT> is used from the
|
|
time when the <TT>SESSION-ID</TT> was established. This is because the
|
|
client does not send new <TT>KEY-ARG-DATA</TT> (recall that the
|
|
<TT>KEY-ARG-DATA</TT> is sent only in the <TT>CLIENT-MASTER-KEY</TT>
|
|
message). <P>
|
|
|
|
The <TT>CONNECTION-ID-DATA</TT> is a string of randomly generated
|
|
bytes used by the server and client at various points in the
|
|
protocol. The <TT>CLIENT-FINISHED</TT> message contains an encrypted
|
|
version of the <TT>CONNECTION-ID-DATA</TT>. The length of the
|
|
<TT>CONNECTION-ID</TT> must be between 16 and than 32 bytes,
|
|
inclusive. <P>
|
|
|
|
The <TT>CIPHER-SPECS-DATA</TT> define a cipher type and key length (in
|
|
bits) that the receiving end supports. Each
|
|
<TT>SESSION-CIPHER-SPEC</TT> is 3 bytes long and looks like this: <P>
|
|
|
|
<PRE>
|
|
char CIPHER-KIND-0
|
|
char CIPHER-KIND-1
|
|
char CIPHER-KIND-2
|
|
</PRE>
|
|
|
|
Where CIPHER-KIND is one of: <P>
|
|
|
|
<UL TYPE=disc>
|
|
<LI>SSL_CK_RC4_128_WITH_MD5
|
|
<LI>SSL_CK_RC4_128_EXPORT40_WITH_MD5
|
|
<LI>SSL_CK_RC2_128_CBC_WITH_MD5
|
|
<LI>SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
|
|
<LI>SSL_CK_IDEA_128_CBC_WITH_MD5
|
|
<LI>SSL_CK_DES_64_CBC_WITH_MD5
|
|
<LI>SSL_CK_DES_192_EDE3_CBC_WITH_MD5
|
|
</UL>
|
|
<P>
|
|
|
|
This list is not exhaustive and may be changed in the future. <P>
|
|
|
|
The <TT>SSL_CK_RC4_128_EXPORT40_WITH_MD5</TT> cipher is an RC4 cipher
|
|
where some of the session key is sent in the clear and the rest is
|
|
sent encrypted (exactly 40 bits of it). MD5 is used as the hash
|
|
function for production of MAC's and session key's. This cipher type
|
|
is provided to support "export" versions (i.e. versions of the
|
|
protocol that can be distributed outside of the United States) of the
|
|
client or server. <P>
|
|
|
|
An exportable implementation of the SSL Handshake Protocol will have
|
|
secret key lengths restricted to 40 bits. For non-export
|
|
implementations key lengths can be more generous (we recommend at
|
|
least 128 bits). It is permissible for the client and server to have a
|
|
non-intersecting set of stream ciphers. This, simply put, means they
|
|
cannot communicate. <P>
|
|
|
|
Version 2 of the SSL Handshake Protocol defines the
|
|
<TT>SSL_CK_RC4_128_WITH_MD5</TT> to have a key length of 128 bits. The
|
|
<TT>SSL_CK_RC4_128_EXPORT40_WITH_MD5</TT> also has a key length of 128
|
|
bits. However, only 40 of the bits are secret (the other 88 bits are
|
|
sent in the clear by the client to the server). <P>
|
|
|
|
The <TT>SERVER-HELLO</TT> message is sent after the server receives
|
|
the <TT>CLIENT-HELLO</TT> message, and before the server sends the
|
|
<TT>SERVER-VERIFY</TT> message. <P>
|
|
|
|
<H4>SERVER-VERIFY (Phase 1; Sent encrypted)</H4>
|
|
|
|
<PRE>
|
|
char MSG-SERVER-VERIFY
|
|
char CHALLENGE-DATA[N-1]
|
|
</PRE>
|
|
|
|
The server sends this message after a pair of session keys
|
|
(<TT>SERVER-READ-KEY</TT> and <TT>SERVER-WRITE-KEY</TT>) have been
|
|
agreed upon either by a session-identifier or by explicit
|
|
specification with the <TT>CLIENT-MASTER-KEY</TT> message. The
|
|
message contains an encrypted copy of the <TT>CHALLENGE-DATA</TT> sent
|
|
by the client in the <TT>CLIENT-HELLO</TT> message. <P>
|
|
|
|
"<TT>N</TT>" is the number of bytes in the message that was sent, so
|
|
"<TT>N-1</TT>" is the number of bytes in the <TT>CHALLENGE-DATA</TT>
|
|
without the message header byte. <P>
|
|
|
|
This message is used to verify the server as follows. A legitimate
|
|
server will have the private key that corresponds to the public key
|
|
contained in the server certificate that was transmitted in the
|
|
<TT>SERVER-HELLO</TT> message. Accordingly, the legitimate server will
|
|
be able to extract and reconstruct the pair of session keys
|
|
(<TT>SERVER-READ-KEY</TT> and <TT>SERVER-WRITE-KEY</TT>). Finally,
|
|
only a server that has done the extraction and decryption properly can
|
|
correctly encrypt the <TT>CHALLENGE-DATA</TT>. This, in essence,
|
|
"proves" that the server has the private key that goes with the public
|
|
key in the server's certificate. <P>
|
|
|
|
The <TT>CHALLENGE-DATA</TT> must be the exact same length as
|
|
originally sent by the client in the <TT>CLIENT-HELLO</TT>
|
|
message. Its value must match exactly the value sent in the clear by
|
|
the client in the <TT>CLIENT-HELLO</TT> message. The client must
|
|
decrypt this message and compare the value received with the value
|
|
sent, and only if the values are identical is the server to be
|
|
"trusted". If the lengths do not match or the value doesn't match then
|
|
the connection is to be closed by the client. <P>
|
|
|
|
This message must be sent by the server to the client after either
|
|
detecting a session-identifier hit (and replying with a
|
|
<TT>SERVER-HELLO</TT> message with <TT>SESSION-ID-HIT</TT> not equal
|
|
to zero) or when the server receives the <TT>CLIENT-MASTER-KEY</TT>
|
|
message. This message must be sent before any Phase 2 messages or a
|
|
<TT>SEVER-FINISHED</TT> message. <P>
|
|
|
|
<H4>SERVER-FINISHED (Phase 2; Sent encrypted)</H4>
|
|
|
|
<PRE>
|
|
char MSG-SERVER-FINISHED
|
|
char SESSION-ID-DATA[N-1]
|
|
</PRE>
|
|
|
|
The server sends this message when it is satisfied with the clients
|
|
security handshake and is ready to proceed with transmission/reception
|
|
of the higher level protocols data. The <TT>SESSION-ID-DATA</TT> is
|
|
used by the client and the server at this time to add entries to their
|
|
respective session-identifier caches. The session-identifier caches
|
|
must contain a copy of the <TT>MASTER-KEY</TT> sent in the
|
|
<TT>CLIENT-MASTER-KEY</TT> message as the master key is used for all
|
|
subsequent session key generation. <P>
|
|
|
|
"<TT>N</TT>" is the number of bytes in the message that was sent, so
|
|
"<TT>N-1</TT>" is the number of bytes in the <TT>SESSION-ID-DATA</TT>
|
|
without the message header byte. <P>
|
|
|
|
This message must be sent after the <TT>SERVER-VERIFY</TT>
|
|
message. <P>
|
|
|
|
<H4>REQUEST-CERTIFICATE (Phase 2; Sent encrypted)</H4>
|
|
|
|
<PRE>
|
|
char MSG-REQUEST-CERTIFICATE
|
|
char AUTHENTICATION-TYPE
|
|
char CERTIFICATE-CHALLENGE-DATA[N-2]
|
|
</PRE>
|
|
|
|
A server may issue this request at any time during the second phase of
|
|
the connection handshake, asking for the client's certificate. The
|
|
client responds with a <TT>CLIENT-CERTIFICATE</TT> message immediately
|
|
if it has one, or an <TT>ERROR</TT> message (with error code
|
|
<TT>NO-CERTIFICATE-ERROR</TT>) if it doesn't. The
|
|
<TT>CERTIFICATE-CHALLENGE-DATA</TT> is a short byte string (whose
|
|
length is greater than or equal to 16 bytes and less than or equal to
|
|
32 bytes) that the client will use to respond to this message. <P>
|
|
|
|
The <TT>AUTHENTICATION-TYPE</TT> value is used to choose a particular
|
|
means of authenticating the client. The following types are defined:
|
|
<P>
|
|
|
|
<UL TYPE=disc>
|
|
<LI>SSL_AT_MD5_WITH_RSA_ENCRYPTION
|
|
</UL>
|
|
<P>
|
|
|
|
The <TT>SSL_AT_MD5_WITH_RSA_ENCRYPTION</TT> type requires that the
|
|
client construct an MD5 message digest using information as described
|
|
above in the section on the CLIENT-CERTIFICATE message. Once the
|
|
digest is created, the client encrypts it using its private key
|
|
(formatted according to the digital signature standard defined in
|
|
PKCS#1). The server authenticates the client when it receives the
|
|
<TT>CLIENT-CERTIFICATE</TT> message. <P>
|
|
|
|
This message may be sent after a <TT>SERVER-VERIFY</TT> message and
|
|
before a <TT>SERVER-FINISHED</TT> message. <P>
|
|
|
|
</DL>
|
|
<H4>2.7 Client/Server Protocol Messages</H4>
|
|
<DL><DD>
|
|
|
|
These messages are generated by both the client and the server. <P>
|
|
|
|
<H4>ERROR (Sent clear or encrypted)</H4>
|
|
|
|
<PRE>
|
|
char MSG-ERROR
|
|
char ERROR-CODE-MSB
|
|
char ERROR-CODE-LSB
|
|
</PRE>
|
|
|
|
This message is sent when an error is detected. After the message
|
|
is sent, the sending party shuts the connection down. The receiving
|
|
party records the error and then shuts its connection down. <P>
|
|
|
|
This message is sent in the clear if an error occurs during session
|
|
key negotiation. After a session key has been agreed upon, errors are
|
|
sent encrypted like all other messages. <P>
|
|
|
|
</DL>
|
|
</DL>
|
|
|
|
<hr>
|
|
|
|
<H3>Appendix A: ASN.1 Syntax For Certificates</H3>
|
|
<DL><DD>
|
|
|
|
Certificates are used by SSL to authenticate servers and clients. SSL
|
|
Certificates are based largely on the X.509 [3] certificates. An X.509
|
|
certificate contains the following information (in ASN.1 [1] notation): <P>
|
|
|
|
<PRE>
|
|
X.509-Certificate ::= SEQUENCE {
|
|
certificateInfo CertificateInfo,
|
|
signatureAlgorithm AlgorithmIdentifier,
|
|
signature BIT STRING
|
|
}
|
|
|
|
CertificateInfo ::= SEQUENCE {
|
|
version [0] Version DEFAULT v1988,
|
|
serialNumber CertificateSerialNumber,
|
|
signature AlgorithmIdentifier,
|
|
issuer Name,
|
|
validity Validity,
|
|
subject Name,
|
|
subjectPublicKeyInfo SubjectPublicKeyInfo
|
|
}
|
|
|
|
Version ::= INTEGER { v1988(0) }
|
|
|
|
CertificateSerialNumber ::= INTEGER
|
|
|
|
Validity ::= SEQUENCE {
|
|
notBefore UTCTime,
|
|
notAfter UTCTime
|
|
}
|
|
|
|
SubjectPublicKeyInfo ::= SEQUENCE {
|
|
algorithm AlgorithmIdentifier,
|
|
subjectPublicKey BIT STRING
|
|
}
|
|
|
|
AlgorithmIdentifier ::= SEQUENCE {
|
|
algorithm OBJECT IDENTIFIER,
|
|
parameters ANY DEFINED BY ALGORITHM OPTIONAL
|
|
}
|
|
</PRE>
|
|
|
|
For SSL's purposes we restrict the values of some of the X.509 fields: <P>
|
|
|
|
<UL TYPE=disc>
|
|
|
|
<LI>The <TT>X.509-Certificate::signatureAlgorithm</TT> and
|
|
<TT>CertificateInfo::signature</TT> fields must be identical in
|
|
value. <P>
|
|
|
|
<LI>The issuer name must resolve to a name that is deemed acceptable
|
|
by the application using SSL. How the application using SSL does this
|
|
is outside the scope of this memo. <P>
|
|
|
|
</UL>
|
|
<A NAME="#cert-check"></A>
|
|
Certificates are validated using a few straightforward steps. First,
|
|
the signature on the certificate is checked and if invalid, the
|
|
certificate is invalid (either a transmission error or an attempted
|
|
forgery occurred). Next, the <TT>CertificateInfo::issuer</TT> field is
|
|
verified to be an issuer that the application trusts (using an
|
|
unspecified mechanism). The <TT>CertificateInfo::validity</TT> field
|
|
is checked against the current date and verified. <P>
|
|
|
|
Finally, the <TT>CertificateInfo::subject</TT> field is checked. This
|
|
check is optional and depends on the level of trust required by the
|
|
application using SSL. <P>
|
|
|
|
</DL>
|
|
<H3>Appendix B: Attribute Types and Object Identifiers</H3>
|
|
<DL><DD>
|
|
|
|
SSL uses a subset of the X.520 selected attribute types as well as a
|
|
few specific object identifiers. Future revisions of the SSL protocol
|
|
may include support for more attribute types and more object
|
|
identifiers. <P>
|
|
|
|
<H4>B.1 Selected attribute types</H4>
|
|
|
|
<DL>
|
|
|
|
<DT> commonName { attributeType 3 }
|
|
<DD> The common name contained in the distinguished name contained
|
|
within a certificate issuer or certificate subject. <P>
|
|
|
|
<DT> countryName { attributeType 6 }
|
|
<DD> The country name contained in the distinguished name contained
|
|
within a certificate issuer or certificate subject. <P>
|
|
|
|
<DT> localityName { attributeType 7 }
|
|
<DD> The locality name contained in the distinguished name contained
|
|
within a certificate issuer or certificate subject. <P>
|
|
|
|
<DT> stateOrProvinceName { attributeType 8 }
|
|
<DD> The state or province name contained in the distinguished name
|
|
contained within a certificate issuer or certificate subject. <P>
|
|
|
|
<DT> organizationName { attributeType 10 }
|
|
<DD> The organization name contained in the distinguished name
|
|
contained within a certificate issuer or certificate subject. <P>
|
|
|
|
<DT> organizationalUnitName { attributeType 11 }
|
|
<DD> The organizational unit name contained in the distinguished name
|
|
contained within a certificate issuer or certificate subject. <P>
|
|
|
|
</DL>
|
|
|
|
<H4>B.2 Object identifiers</H4>
|
|
|
|
<DL>
|
|
|
|
<DT> md2withRSAEncryption { ... pkcs(1) 1 2 }
|
|
<DD> The object identifier for digital signatures that use both MD2 and
|
|
RSA encryption. Used by SSL for certificate signature verification. <P>
|
|
|
|
<DT> md5withRSAEncryption { ... pkcs(1) 1 4 }
|
|
<DD> The object identifier for digital signatures that use both MD5 and
|
|
RSA encryption. Used by SSL for certificate signature verification. <P>
|
|
|
|
<DT> rc4 { ... rsadsi(113549) 3 4 }
|
|
<DD> The RC4 symmetric stream cipher algorithm used by SSL for bulk
|
|
encryption. <P>
|
|
|
|
</DL>
|
|
|
|
</DL>
|
|
<H3>Appendix C: Protocol Constant Values</H3>
|
|
<DL><DD>
|
|
|
|
This section describes various protocol constants. A special value
|
|
needs mentioning - the IANA reserved port number for <B>"https"</B>
|
|
(HTTP using SSL). IANA has reserved port number 443 (decimal) for
|
|
"https". <P>
|
|
|
|
<H4>C.1 Protocol Version Codes</H4>
|
|
|
|
<DL><DD><PRE>
|
|
#define SSL_CLIENT_VERSION 0x0002
|
|
#define SSL_SERVER_VERSION 0x0002
|
|
</PRE></DL>
|
|
|
|
<H4>C.2 Protocol Message Codes</H4>
|
|
|
|
The following values define the message codes that are used by version
|
|
2 of the SSL Handshake Protocol. <P>
|
|
|
|
<DL><DD><PRE>
|
|
#define SSL_MT_ERROR 0
|
|
#define SSL_MT_CLIENT_HELLO 1
|
|
#define SSL_MT_CLIENT_MASTER_KEY 2
|
|
#define SSL_MT_CLIENT_FINISHED 3
|
|
#define SSL_MT_SERVER_HELLO 4
|
|
#define SSL_MT_SERVER_VERIFY 5
|
|
#define SSL_MT_SERVER_FINISHED 6
|
|
#define SSL_MT_REQUEST_CERTIFICATE 7
|
|
#define SSL_MT_CLIENT_CERTIFICATE 8
|
|
</PRE></DL>
|
|
|
|
<H4>C.3 Error Message Codes</H4>
|
|
|
|
The following values define the error codes used by the <TT>ERROR</TT>
|
|
message. <P>
|
|
|
|
<DL><DD><PRE>
|
|
#define SSL_PE_NO_CIPHER 0x0001
|
|
#define SSL_PE_NO_CERTIFICATE 0x0002
|
|
#define SSL_PE_BAD_CERTIFICATE 0x0004
|
|
#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006
|
|
</PRE></DL>
|
|
|
|
<H4>C.4 Cipher Kind Values</H4>
|
|
|
|
The following values define the <TT>CIPHER-KIND</TT> codes used in the
|
|
<TT>CLIENT-HELLO</TT> and <TT>SERVER-HELLO</TT> messages. <P>
|
|
|
|
<DL><DD><PRE>
|
|
#define SSL_CK_RC4_128_WITH_MD5 0x01,0x00,0x80
|
|
#define SSL_CK_RC4_128_EXPORT40_WITH_MD5 0x02,0x00,0x80
|
|
#define SSL_CK_RC2_128_CBC_WITH_MD5 0x03,0x00,0x80
|
|
#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 0x04,0x00,0x80
|
|
#define SSL_CK_IDEA_128_CBC_WITH_MD5 0x05,0x00,0x80
|
|
#define SSL_CK_DES_64_CBC_WITH_MD5 0x06,0x00,0x40
|
|
#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5 0x07,0x00,0xC0
|
|
</PRE></DL>
|
|
|
|
<H4>C.5 Certificate Type Codes</H4>
|
|
|
|
The following values define the certificate type codes used in the
|
|
<TT>SERVER-HELLO</TT> and <TT>CLIENT-CERTIFICATE</TT> messages. <P>
|
|
|
|
<DL><DD><PRE>
|
|
#define SSL_CT_X509_CERTIFICATE 0x01
|
|
</PRE></DL>
|
|
|
|
<H4>C.6 Authentication Type Codes</H4>
|
|
|
|
The following values define the authentication type codes used in
|
|
the <TT>REQUEST-CERTIFICATE</TT> message. <P>
|
|
|
|
<DL><DD><PRE>
|
|
#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01
|
|
</PRE></DL>
|
|
|
|
<H4>C.7 Upper/Lower Bounds</H4>
|
|
|
|
The following values define upper/lower bounds for various protocol
|
|
parameters. <P>
|
|
|
|
<DL><DD><PRE>
|
|
#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256
|
|
#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES 16
|
|
#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES 64
|
|
#define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER 32767
|
|
#define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER 16383
|
|
</PRE></DL>
|
|
|
|
<H4>C.8 Recommendations</H4>
|
|
|
|
Because protocols have to be implemented to be of value, we recommend
|
|
the following values for various operational parameters. This is only
|
|
a recommendation, and not a strict requirement for conformance to the
|
|
protocol. <P>
|
|
|
|
<DL>
|
|
|
|
<DT> Session-identifier Cache Timeout <P>
|
|
|
|
<DD> Session-identifiers are kept in SSL clients and SSL
|
|
servers. Session-identifiers should have a lifetime that serves their
|
|
purpose (namely, reducing the number of expensive public key
|
|
operations for a single client/server pairing). Consequently, we
|
|
recommend a maximum session-identifier cache timeout value of 100
|
|
seconds. Given a server that can perform N private key operations per
|
|
second, this reduces the server load for a particular client by a
|
|
factor of 100. <P>
|
|
|
|
</DL>
|
|
|
|
</DL>
|
|
<H3>Appendix D: Attacks</H3>
|
|
<DL><DD>
|
|
|
|
In this section we attempt to describe various attacks that might
|
|
be used against the SSL protocol. This list is not guaranteed to
|
|
be exhaustive. SSL was defined to thwart these attacks. <P>
|
|
|
|
<H4>D.1 Cracking Ciphers</H4>
|
|
|
|
SSL depends on several cryptographic technologies. RSA Public Key
|
|
encryption [5] is used for the exchange of the session key and
|
|
client/server authentication. Various cryptographic algorithms are
|
|
used for the session cipher. If successful cryptographic attacks are
|
|
made against these technologies then SSL is no longer secure. <P>
|
|
|
|
Attacks against a specific communications session can be made by
|
|
recording the session, and then spending some large number of compute
|
|
cycles to crack either the session key or the RSA public key until the
|
|
communication can be seen in the clear. This approach is easier than
|
|
cracking the cryptographic technologies for all possible messages.
|
|
Note that SSL tries to make the cost of such of an attack greater than
|
|
the benefits gained from a successful attack, thus making it a waste
|
|
of money/time to perform such an attack. <P>
|
|
|
|
There have been many books [9] and papers [10] written on
|
|
cryptography. This document does not attempt to reference them
|
|
all. <P>
|
|
|
|
<H4>D.2 Clear Text Attack</H4>
|
|
|
|
A clear text attack is done when the attacker has an idea of what kind
|
|
of message is being sent using encryption. The attacker can generate a
|
|
data base whose keys are the encrypted value of the known text (or
|
|
clear text), and whose values are the session cipher key (we call this
|
|
a "dictionary"). Once this data base is constructed, a simple lookup
|
|
function identifies the session key that goes with a particular
|
|
encrypted value. Once the session key is known, the entire message
|
|
stream can be decrypted. Custom hardware can be used to make this cost
|
|
effective and very fast. <P>
|
|
|
|
Because of the very nature of SSL clear text attacks are possible. For
|
|
example, the most common byte string sent by an HTTP client
|
|
application to an HTTP server is "GET". SSL attempts to address this
|
|
attack by using large session cipher keys. First, the client generates
|
|
a key which is larger than allowed by export, and sends some of it in
|
|
the clear to the server (this is allowed by United States government
|
|
export rules). The clear portion of the key concatenated with the
|
|
secret portion make a key which is very large (for RC4, exactly 128
|
|
bits). <P>
|
|
|
|
The way that this "defeats" a clear text attack is by making the
|
|
amount of custom hardware needed prohibitively large. Every bit added
|
|
to the length of the session cipher key increases the dictionary size
|
|
by a factor of 2. By using a 128 bit session cipher key length the
|
|
size of the dictionary required is beyond the ability of anyone to
|
|
fabricate (it would require more atoms to construct than exist in the
|
|
entire universe). Even if a smaller dictionary is to be used, it must
|
|
first be generated using the clear key bits. This is a time
|
|
consumptive process and also eliminates many possible custom hardware
|
|
architectures (e.g. static prom arrays). <P>
|
|
|
|
The second way that SSL attacks this problem is by using large key
|
|
lengths when permissible (e.g. in the non-export version). Large key
|
|
sizes require larger dictionaries (just one more bit of key size
|
|
doubles the size of the dictionary). SSL attempts to use keys that are
|
|
128 bits in length. <P>
|
|
|
|
Note that the consequence of the SSL defense is that a brute force
|
|
attack becomes the cheapest way to attack the key. Brute force attacks
|
|
have well known space/time tradeoffs and so it becomes possible to
|
|
define a cost of the attack. For the 128 bit secret key, the known
|
|
cost is essentially infinite. For the 40 bit secret key, the cost is
|
|
much smaller, but still outside the range of the "random hacker". <P>
|
|
|
|
<H4>D.3 Replay</H4>
|
|
|
|
The replay attack is simple. A bad-guy records a communication session
|
|
between a client and server. Later, it reconnects to the server, and
|
|
plays back the previously recorded client messages. <P>
|
|
|
|
SSL defeats this attack using a "nonce" (the connection-id) which is
|
|
"unique" to the connection. In theory the bad-guy cannot predict the
|
|
nonce in advance as it is based on a set of random events outside the
|
|
bad-guys control, and therefore the bad-guy cannot respond properly to
|
|
server requests. <P>
|
|
|
|
A bad-guy with large resources can record many sessions between a
|
|
client and a server, and attempt to choose the right session based on
|
|
the nonce the server sends initially in its SERVER-HELLO message.
|
|
However, SSL nonces are at least 128 bits long, so a bad-guy would
|
|
need to record approximately 2^64 nonces to even have a 50% chance of
|
|
choosing the right session. This number is sufficiently large that one
|
|
cannot economically construct a device to record 2^64 messages, and
|
|
therefore the odds are overwhelmingly against the replay attack ever
|
|
being successful. <P>
|
|
|
|
<H4>D.4 The Man In The Middle</H4>
|
|
|
|
The man in the middle attack works by having three people in
|
|
a communications session: the client, the server, and the bad guy.
|
|
The bad guy sits between the client and the server on the network
|
|
and intercepts traffic that the client sends to the server, and
|
|
traffic that the server sends to the client. <P>
|
|
|
|
The man in the middle operates by pretending to be the real server to
|
|
the client. With SSL this attack is impossible because of the usage of
|
|
server certificates. During the security connection handshake the
|
|
server is required to provide a certificate that is signed by a
|
|
certificate authority. Contained in the certificate is the server's
|
|
public key as well as its name and the name of the certificate
|
|
issuer. The client verifies the certificate by first checking the
|
|
signature and then verifying that the name of the issuer is somebody
|
|
that the client trusts. <P>
|
|
|
|
In addition, the server must encrypt something with the private key
|
|
that goes with the public key mentioned in the certificate. This in
|
|
essence is a single pass "challenge response" mechanism. Only a server
|
|
that has both the certificate and the private key can respond properly
|
|
to the challenge. <P>
|
|
|
|
If the man in the middle provides a phony certificate, then the
|
|
signature check will fail. If the certificate provided by the bad guy
|
|
is legitimate, but for the bad guy instead of for the real server,
|
|
then the signature will pass but the name check will fail (note that
|
|
the man in the middle cannot forge certificates without discovering a
|
|
certificate authority's private key). <P>
|
|
|
|
Finally, if the bad guy provides the real server's certificate then
|
|
the signature check will pass and the name check will pass. However,
|
|
because the bad guy does not have the real server's private key, the
|
|
bad guy cannot properly encode the response to the challenge code, and
|
|
this check will fail. <P>
|
|
|
|
In the unlikely case that a bad guy happens to guess the response code
|
|
to the challenge, the bad guy still cannot decrypt the session key and
|
|
therefore cannot examine the encrypted data. <P>
|
|
|
|
</DL>
|
|
<H3>Appendix E: Terms</H3>
|
|
<DL><DD>
|
|
|
|
<DL>
|
|
|
|
<DT> <B>Application Protocol</B>
|
|
|
|
<DD> An application protocol is a protocol that normally layers directly
|
|
on top of TCP/IP. For example: HTTP, TELNET, FTP, and SMTP. <P>
|
|
|
|
<DT> <B>Authentication</B>
|
|
|
|
<DD> Authentication is the ability of one entity to determine the
|
|
identity of another entity. Identity is defined by this document to
|
|
mean the binding between a <I>public key</I> and a name and the
|
|
implicit ownership of the corresponding <I>private key</I>. <P>
|
|
|
|
<DT> <B>Bulk Cipher</B>
|
|
|
|
<DD> This term is used to describe a cryptographic technique with
|
|
certain performance properties. Bulk ciphers are used when large
|
|
quantities of data are to be encrypted/decrypted in a timely
|
|
manner. Examples include RC2, RC4, and IDEA. <P>
|
|
|
|
<DT> <B>Client</B>
|
|
|
|
<DD> In this document <B>client</B> refers to the application entity
|
|
that is initiates a connection to a server. <P>
|
|
|
|
<DT> <B>CLIENT-READ-KEY</B>
|
|
|
|
<DD> The session key that the client uses to initialize the client
|
|
read cipher. This key has the same value as the SERVER-WRITE-KEY. <P>
|
|
|
|
<DT> <B>CLIENT-WRITE-KEY</B>
|
|
|
|
<DD> The session key that the client uses to initialize the client
|
|
write cipher. This key has the same value as the SERVER-READ-KEY. <P>
|
|
|
|
<DT> <B>MASTER-KEY</B>
|
|
|
|
<DD> The master key that the client and server use for all session
|
|
key generation. The CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY
|
|
and SERVER-WRITE-KEY are generated from the MASTER-KEY. <P>
|
|
|
|
<DT> <B>MD2</B>
|
|
|
|
<DD> MD2 [8] is a hashing function that converts an arbitrarily long
|
|
data stream into a <B>digest</B> of fixed size. This function predates
|
|
MD5 [7] which is viewed as a more robust hash function [9]. <P>
|
|
|
|
<DT> <B>MD5</B>
|
|
|
|
<DD> MD5 [7] is a hashing function that converts an arbitrarily long
|
|
data stream into a <B>digest</B> of fixed size. The function has
|
|
certain properties that make it useful for security, the most
|
|
important of which is it's inability to be reversed. <P>
|
|
|
|
<DT> <B>Nonce</B>
|
|
|
|
<DD> A randomly generated value used to defeat "playback" attacks.
|
|
One party randomly generates a nonce and sends it to the other party.
|
|
The receiver encrypts it using the agreed upon secret key and returns
|
|
it to the sender. Because the nonce was randomly generated by the
|
|
sender this defeats playback attacks because the replayer can't know
|
|
in advance the nonce the sender will generate. The receiver denies
|
|
connections that do not have the correctly encrypted nonce. <P>
|
|
|
|
<DT> <B>Non-repudiable Information Exchange</B>
|
|
|
|
<DD> When two entities exchange information it is sometimes valuable
|
|
to have a record of the communication that is non-repudiable. Neither
|
|
party can then deny that the information exchange occurred. Version 2
|
|
of the SSL protocol does not support Non-repudiable information
|
|
exchange. <P>
|
|
|
|
<DT> <B>Public Key Encryption</B>
|
|
|
|
<DD> Public key encryption is a technique that leverages asymmetric
|
|
ciphers. A public key system consists of two keys: a public key and a
|
|
private key. Messages encrypted with the public key can only be
|
|
decrypted with the associated private key. Conversely, messages
|
|
encrypted with the private key can only be decrypted with the public
|
|
key. Public key encryption tends to be extremely compute intensive and
|
|
so is not suitable as a bulk cipher. <P>
|
|
|
|
<DT> <B>Privacy</B>
|
|
|
|
<DD> Privacy is the ability of two entities to communicate without
|
|
fear of eavesdropping. Privacy is often implemented by
|
|
<I>encrypting</I> the communications stream between the two
|
|
entities. <P>
|
|
|
|
<DT> <B>RC2, RC4</B>
|
|
|
|
<DD> Proprietary bulk ciphers invented by RSA (There is no good
|
|
reference to these as they are unpublished works; however, see
|
|
[9]). RC2 is block cipher and RC4 is a stream cipher. <P>
|
|
|
|
<DT> <B>Server</B>
|
|
|
|
<DD> The server is the application entity that responds to requests
|
|
for connections from clients. The server is passive, waiting for
|
|
requests from clients. <P>
|
|
|
|
<DT> <B>Session cipher</B>
|
|
|
|
<DD> A session cipher is a "bulk" cipher that is capable of encrypting
|
|
or decrypting arbitrarily large amounts of data. Session ciphers are
|
|
used primarily for performance reasons. The session ciphers used by
|
|
this protocol are symmetric. Symmetric ciphers have the property of
|
|
using a single key for encryption and decryption. <P>
|
|
|
|
<DT> <B>Session identifier</B>
|
|
|
|
<DD> A session identifier is a random value generated by a client that
|
|
identifies itself to a particular server. The session identifier can
|
|
be thought of as a handle that both parties use to access a recorded
|
|
secret key (in our case a session key). If both parties remember the
|
|
session identifier then the implication is that the secret key is
|
|
already known and need not be negotiated. <P>
|
|
|
|
<DT> <B>Session key</B>
|
|
|
|
<DD> The key to the session cipher. In SSL there are four keys that
|
|
are called session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY,
|
|
SERVER-READ-KEY, and SERVER-WRITE-KEY. <P>
|
|
|
|
<DT> <B>SERVER-READ-KEY</B>
|
|
|
|
<DD> The session key that the server uses to initialize the server read
|
|
cipher. This key has the same value as the CLIENT-WRITE-KEY. <P>
|
|
|
|
<DT> <B>SERVER-WRITE-KEY</B>
|
|
|
|
<DD> The session key that the server uses to initialize the server
|
|
write cipher. This key has the same value as the CLIENT-READ-KEY. <P>
|
|
|
|
<DT> <B>Symmetric Cipher</B>
|
|
|
|
<DD> A symmetric cipher has the property that the same key can be used
|
|
for decryption and encryption. An asymmetric cipher does not have this
|
|
behavior. Some examples of symmetric ciphers: IDEA, RC2,
|
|
RC4. <P>
|
|
|
|
</DL>
|
|
|
|
</DL>
|
|
<H3>References</H3>
|
|
<DL><DD>
|
|
|
|
[1] CCITT. Recommendation X.208: "Specification of Abstract Syntax
|
|
Notation One (ASN.1). 1988. <P>
|
|
|
|
[2] CCITT. Recommendation X.209: "Specification of Basic Encoding
|
|
Rules for Abstract Syntax Notation One (ASN.1). 1988. <P>
|
|
|
|
[3] CCITT. Recommendation X.509: "The Directory - Authentication
|
|
Framework". 1988. <P>
|
|
|
|
[4] CCITT. Recommendation X.520: "The Directory - Selected Attribute
|
|
Types". 1988.<P>
|
|
|
|
[5] RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5,
|
|
November 1993. <P>
|
|
|
|
[6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard,
|
|
Version 1.5, November 1993. <P>
|
|
|
|
[7] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992. <P>
|
|
|
|
[8] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 1992. <P>
|
|
|
|
[9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and
|
|
Source Code in C, Published by John Wiley & Sons, Inc. 1994. <P>
|
|
|
|
[10] M. Abadi and R. Needham. Prudent engineering practice for
|
|
cryptographic protocols. 1994. <P>
|
|
|
|
</DL>
|
|
|
|
<H3>Patent Statement</H3>
|
|
|
|
<DL><DD>
|
|
|
|
This version of the SSL protocol relies on the use of patented public
|
|
key encryption technology for authentication and encryption. The
|
|
Internet Standards Process as defined in RFC 1310 requires a written
|
|
statement from the Patent holder that a license will be made available
|
|
to applicants under reasonable terms and conditions prior to approving
|
|
a specification as a Proposed, Draft or Internet Standard. <P>
|
|
|
|
The Massachusetts Institute of Technology and the Board of Trustees of
|
|
the Leland Stanford Junior University have granted Public Key Partners
|
|
(PKP) exclusive sub-licensing rights to the following patents issued
|
|
in the United States, and all of their corresponding foreign patents: <P>
|
|
|
|
<DL><DD><PRE>
|
|
Cryptographic Apparatus and Method
|
|
("Diffie-Hellman")............................... No. 4,200,770 <P>
|
|
|
|
Public Key Cryptographic Apparatus
|
|
and Method ("Hellman-Merkle").................... No. 4,218,582 <P>
|
|
|
|
Cryptographic Communications System and
|
|
Method ("RSA")................................... No. 4,405,829 <P>
|
|
|
|
Exponential Cryptographic Apparatus
|
|
and Method ("Hellman-Pohlig").................... No. 4,424,414 <P>
|
|
|
|
</PRE></DL>
|
|
|
|
These patents are stated by PKP to cover all known methods of
|
|
practicing the art of Public Key encryption, including the variations
|
|
collectively known as El Gamal. <P>
|
|
|
|
Public Key Partners has provided written assurance to the Internet
|
|
Society that parties will be able to obtain, under reasonable,
|
|
nondiscriminatory terms, the right to use the technology covered by
|
|
these patents. This assurance is documented in RFC 1170 titled
|
|
"Public Key Standards and Licenses". A copy of the written assurance
|
|
dated April 20, 1990, may be obtained from the Internet Assigned
|
|
Number Authority (IANA). <P>
|
|
|
|
The Internet Society, Internet Architecture Board, Internet
|
|
Engineering Steering Group and the Corporation for National Research
|
|
Initiatives take no position on the validity or scope of the patents
|
|
and patent applications, nor on the appropriateness of the terms of
|
|
the assurance. The Internet Society and other groups mentioned above
|
|
have not made any determination as to any other intellectual property
|
|
rights which may apply to the practice of this standard. Any further
|
|
consideration of these matters is the user's own responsibility. <P>
|
|
|
|
</DL>
|
|
|
|
<H3>Security Considerations</H3>
|
|
|
|
<DL><DD>This entire document is about security. <P></DL>
|
|
|
|
<H3>Author's Address</H3>
|
|
|
|
<DL><DD>
|
|
|
|
<address>
|
|
Kipp E.B. Hickman<br>
|
|
Netscape Communications Corp.<br>
|
|
501 East Middlefield Rd.<br>
|
|
Mountain View, CA 94043<br>
|
|
[email protected]<br>
|
|
</address>
|
|
|
|
</DL>
|
|
</BODY>
|
|
</HTML>
|