Online Documentation Server
Net technology
Web technology
Data bases
Other docs



Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.

Previous page | Next page | Contents

Appendix E

E. Version 2.0 Backward Compatibility

Version 3.0 clients that support Version 2.0 servers must send Version 2.0 client hello messages [SSL-2]. Version 3.0 servers should accept either client hello format. The only deviations from the Version 2.0 specification are the ability to specify a version with a value of three and the support for more ciphering types in the CipherSpec.

Warning: The ability to send Version 2.0 client hello messages will be phased out with all due haste. Implementors should make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for transitioning to newer versions.

The following cipher specifications are carryovers from SSL Version 2.0. These are assumed to use RSA for key exchange and authentication.

V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 = { 0x04,0x00,0x80 };
V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };

Cipher specifications introduced in Version 3.0 can be included in Version 2.0 client hello messages using the syntax below. Any V2CipherSpec element with its first byte equal to zero will be ignored by Version 2.0 servers. Clients sending any of the above V2CipherSpecs should also include the Version 3.0 equivalent (see Appendix A.6):

V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite };

E.1 Version 2 client hello

The Version 2.0 client hello message is presented below using this document's presentation model. The true definition is still assumed to be the SSL Version 2.0 specification.
uint8 V2CipherSpec[3];
struct {
    uint8        msg_type;
    Version      version;
    uint16       cipher_spec_length;
    uint16       session_id_length;
    uint16       challenge_length;
    V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
    opaque       session_id[V2ClientHello.session_id_length];
    Random       challenge;
} V2ClientHello;

This field, in conjunction with the version field, identifies a version 2 client hello message. The value should equal one (1).

The highest version of the protocol supported by the client (equals ProtocolVersion.version, see Appendix A.1.1 ).

This field is the total length of the field cipher_specs. It cannot be zero and must be a multiple of the V2CipherSpec length (3).

This field must have a value of either zero or 16. If zero, the client is creating a new session. If 16, the session_id field will contain the 16 bytes of session identification.

The length in bytes of the client's challenge to the server to authenticate itself. This value must be 32.

This is a list of all CipherSpecs the client is willing and able to use. There must be at least one CipherSpec acceptable to the server.

If this field's length is not zero, it will contain the identification for a session that the client wishes to resume.

The client's challenge to the server for the server to identify itself is a (nearly) arbitrary length random. The Version 3.0 server will right justify the challenge data to become the ClientHello.random data (padded with leading zeroes, if necessary), as specified in this Version 3.0 protocol. If the length of the challenge is greater than 32 bytes, then only the last 32 bytes are used. It is legitimate (but not necessary) for a V3 server to reject a V2 ClientHello that has fewer than 16 bytes of challenge data.

Note: Requests to resume an SSL 3.0 session should use an SSL 3.0 client hello.

E.2 Avoiding man-in-the-middle version rollback

When SSL Version 3.0 clients fall back to Version 2.0 compatibility mode, they use special PKCS #1 block formatting. This is done so that Version 3.0 servers will reject Version 2.0 sessions with Version 3.0-capable clients.

When Version 3.0 clients are in Version 2.0 compatibility mode, they set the right-hand (least-significant) 8 random bytes of the PKCS padding (not including the terminal null of the padding) for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random). After decrypting the ENCRYPTED-KEY-DATA field, servers that support SSL 3.0 should issue an error if these eight padding bytes are 0x03. Version 2.0 servers receiving blocks padded in this manner will proceed normally.

Previous page | Next page | Contents

With any suggestions or questions please feel free to contact us