Diffie-Hellman
Выполняются обычные вычисления по алгоритму Diffie-Hellman. В качестве pre_master_secret используется согласованный ключ (Z), преобразование его в master_secret, описано выше.
Параметры Diffie-Hellman специфицируются сервером и могут быть одноразовыми или взятыми из сертификата сервера.
В отсутствии стандарта на прикладной профайл приложение TLS должно использовать шифровой набор TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
Сообщения прикладных данных вырабатываются уровнем записей, фрагментируются, сжимаются и шифруются на основе параметров состояния соединения. Сообщения рассматриваются как прозрачные данные уровня записей.
A. Значения протокольных констант
A.1. Уровень записей
struct { uint8 major, minor; } ProtocolVersion;
ProtocolVersion version = { 3, 1 }; /* TLS v1.0 */
enum { change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255) } ContentType;
struct { ContentType type; ProtocolVersion version; uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct { ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct { ContentType type; ProtocolVersion version; uint16 length;
select (CipherSpec.cipher_type) { case stream: GenericStreamCipher;
case block: GenericBlockCipher; } fragment;
} TLSCiphertext;
stream-ciphered struct { opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size]; } GenericStreamCipher;
block-ciphered struct { opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
A.2. Сообщение об изменении спецификации шифра
struct { enum { change_cipher_spec(1), (255) } type;} ChangeCipherSpec;
A.3. Сообщения уведомления (Alert)
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { close_notify(0),
| unexpected_message(10), | |
| bad_record_mac(20), | |
| decryption_failed(21), | |
| record_overflow(22), | |
| decompression_failure(30), | |
| handshake_failure(40), | |
| bad_certificate(42), | |
| unsupported_certificate(43), | |
| certificate_revoked(44), | |
| certificate_expired(45), | |
| certificate_unknown(46), | |
| illegal_parameter(47), | |
| unknown_ca(48), | |
| access_denied(49), | |
| decode_error(50), | |
| decrypt_error(51), | |
| export_restriction(60), | |
| protocol_version(70), | |
| insufficient_security(71), | |
| internal_error(80), | |
| user_canceled(90), | |
| no_renegotiation(100), | |
| (255) } AlertDescription; |
struct { AlertLevel level; AlertDescription description; } Alert;
A.4. Протокол диалога
enum { hello_request(0), client_hello(1), server_hello(2),
| certificate(11), server_key_exchange (12), | |
| certificate_request(13), server_hello_done(14), | |
| certificate_verify(15), client_key_exchange(16), | |
| finished(20), (255) |
struct { HandshakeType msg_type; uint24 length;
| select (HandshakeType) | { | |
| case hello_request: | HelloRequest; | |
| case client_hello: | ClientHello; | |
| case server_hello: | ServerHello; | |
| case certificate: | Certificate; | |
| case server_key_exchange: | ServerKeyExchange; | |
| case certificate_request: | CertificateRequest; | |
| case server_hello_done: | ServerHelloDone; | |
| case certificate_verify: | CertificateVerify; | |
| case client_key_exchange: | ClientKeyExchange; | |
| case finished: | Finished; } body; | |
| } Handshake; |
struct { } HelloRequest;
struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random;
opaque SessionID<0..32>;
uint8 CipherSuite[2];
enum { null(0), (255) } CompressionMethod;
struct { ProtocolVersion client_version; Random random;
SessionID session_id;
CipherSuite cipher_suites<2..216-1>;
CompressionMethod compression_methods<1..28-1>;
} ClientHello;
struct { ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
A.4.2. Аутентификация сервера и сообщения обмена ключами
opaque ASN.1Cert<224-1>;
struct { ASN.1Cert certificate_list<1..224-1>;} Certificate;
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct { opaque RSA_modulus<1..216-1>; opaque RSA_exponent<1..216-1>;
} ServerRSAParams;
struct { opaque DH_p<1..216-1>; opaque DH_g<1..216-1>;
opaque DH_Ys<1..216-1>; ServerDHParams;
struct { select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params; };
} ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
select (SignatureAlgorithm)
{ case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20]; };
case dsa:
digitally-signed struct {
opaque sha_hash[20]; };
} Signature;
enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), (255)} ClientCertificateType;
opaque DistinguishedName<1..216-1>;
struct { ClientCertificateType certificate_types<1..28-1>;
DistinguishedName certificate_authorities<3..216-1>;
} CertificateRequest;
struct { } ServerHelloDone;
A.4.3. Аутентификация клиента и сообщения обмена ключами
struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret;
case diffie_hellman: DiffieHellmanClientPublicValue; } exchange_keys;
} ClientKeyExchange;
struct { ProtocolVersion client_version; opaque random[46]; } PreMasterSecret;
struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret;
enum { implicit, explicit } PublicValueEncoding;
struct { select (PublicValueEncoding) { case implicit: struct {};
case explicit: opaque DH_Yc<1..216-1>; } dh_public;
} ClientDiffieHellmanPublic;
struct { Signature signature; } CertificateVerify;
A.4.4. Завершающее сообщение диалога
struct { opaque verify_data[12]; } Finished;
A.5. Коды CipherSuite
Следующие значения определены кодами CipherSuite, используемыми в сообщениях client hello и server hello. CipherSuite определяет шифровую спецификацию, поддерживаемую в TLS версии 1.0.
TLS_NULL_WITH_NULL_NULL специфицировано и является исходным состоянием TLS-соединения во время начала диалога в канале, эта спецификация не согласуется, так как она предоставляет услуги незащищенного соединения.
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
Следующие определения CipherSuite требуют, чтобы сервер предоставлял RSA-сертификат, который можно использовать для ключевого обмена. Сервер может потребовать присылки сертификата RSA или DSS, пригодного для цифровой подписи.
| CipherSuite TLS_RSA_WITH_NULL_MD5 | = { 0x00,0x01 }; |
| CipherSuite TLS_RSA_WITH_NULL_SHA | = { 0x00,0x02 }; |
| CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 | = { 0x00,0x03 }; |
| CipherSuite TLS_RSA_WITH_RC4_128_MD5 | = { 0x00,0x04 }; |
| CipherSuite TLS_RSA_WITH_RC4_128_SHA | = { 0x00,0x05 }; |
| CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 | = { 0x00,0x06 }; |
| CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA | = { 0x00,0x07 }; |
| CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x08 }; |
| CipherSuite TLS_RSA_WITH_DES_CBC_SHA | = { 0x00,0x09 }; |
| CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x0A }; |
Следующие определения CipherSuite используются для аутентифицированного сервером (и опционно клиентом) алгоритма Diffie-Hellman. DH обозначает шифровой набор, в котором сертификат сервера содержит параметры алгоритма Diffie-Hellman, подписанные провайдером сертификата CA (certificate authority). DHE обозначает временный Diffie-Hellman, где параметры Diffie-Hellman подписаны с помощью DSS- или RSA-сертификата, который подписан посредством CA. Используемый алгоритм подписи специфицирован согласно параметрам DH или DHE. Сервер может запросить от клиента сертификат RSA или DSS, пригодный для подписи, чтобы аутентифицировать клиента. Он может запросить также сертификат Diffie-Hellman. Любой сертификат Diffie-Hellman, предоставленный клиентом должен использовать параметры (группа и генератор), описанные сервером.
| CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x0B }; |
| CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA | = { 0x00,0x0C }; |
| CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x0D }; |
| CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x0E }; |
| CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA | = { 0x00,0x0F }; |
| CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x10 }; |
| CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x11 }; |
| CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA | = { 0x00,0x12 }; |
| CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x13 }; |
| CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x14 }; |
| CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA | = { 0x00,0x15 }; |
| CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x16 }; |
| CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 | = { 0x00,0x17 }; |
| CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 | = { 0x00,0x18 }; |
| CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x19 }; |
| CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA | = { 0x00,0x1A }; |
| CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x1B }; |
Все шифровые наборы, чей первый байт равен 0xFF, рассматриваются частными и могут быть использованы для определения локальных/экспериментальных алгоритмов.
Дополнительные шрифтовые наборы могут быть зарегистрированы путем публикации документа RFC, который специфицирует этот набор, включая необходимую протокольную информацию TLS, кодировку сообщений, получение предмастерных секретных кодов, симметричного шифрования, MAC-вычисления и ссылки на описания используемых алгоритмов. Редакционная комиссия RFC по своему разумению может опубликовать и неполное описание шифрового набора, если сочтет, что данное описание представляет определенный интерес.
Коды шифровых наборов { 0x00, 0x1C } и { 0x00, 0x1D } зарезервированы, чтобы избежать конфликта с наборами, базирующимися на Fortezza в SSL 3.
A.6. Параметры безопасности
Эти параметры безопасности определены протоколом диалога TLS и передаются уровню записи TLS, для того чтобы инициализировать состояние соединения. SecurityParameters включают в себя:
enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, idea }
BulkCipherAlgorithm;
enum { stream, block } CipherType;
enum { true, false } IsExportable; enum { null, md5, sha } MACAlgorithm;
/* Алгоритмы специфицированы в CompressionMethod, BulkCipherAlgorithm и MACAlgorithm и могут быть добавлены. */
struct { ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
IsExportable is_exportable;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
B. Словарь
| Протокол приложения | Протокол приложения является протоколом, который функционирует поверх транспортного уровня (напр., TCP/IP). Среди примеров можно назвать HTTP, TELNET, FTP и SMTP. |
| Асимметричный шифр | Смотри криптографию с общедоступным ключом |
| Аутентификация | Аутентификация - это механизм, который предоставляет возможность одному партнеру идентифицировать другого партнера |
| Блочный шифр | Блочный шифр - это алгоритм, который работает с фиксированными группами битов открытого текста, называемых блоками. 64 бита - обычный размер блока |
| Массовый шифр | Алгоритм симметричного шифрования, используемый для кодирования больших объемов данных. |
| Цепочный блок-шифр (CBC) | CBC является режимом, в котором каждый блок исходного текста закодированного блочным шифром сначала объединяется с предыдущим зашифрованным блоком с помощью исключающего ИЛИ (или в случае первого блока, с вектором инициализации). При дешифровании каждый блок сначала дешифруется, а затем объединяется с предыдущим зашифрованным блоком с помощью исключающего ИЛИ (или IV). |
| Сертификат | В качестве части протокола X.509, сертификаты выдаются проверенным провайдером (Certificate Authority) и обеспечивают строгую связь между идентичностью партнера, содержат некоторые другие атрибуты, а также общедоступный ключ |
| Клиент | Субъект, который инициирует TLS-соединение с сервером. Различие между сервером и клиентом заключается в том, что сервер обычно является аутентифицированным, в то время как клиент может быть аутентифицирован только опционно. |
| Ключ записи клиента | Ключ, используемый клиентом для шифрования записываемых данных. |
| Секретный код MAC записи клиента | Секретные данные, используемые для аутентификации информации, которую пишет клиент. |
| Соединение | Соединение - это транспортная среда (согласно определению модели OSI), которая предоставляет приемлемый тип услуг. Для TLS, такие соединения служат для установления канала между партнерами. Соединения прозрачны. Каждое соединение сопряжено с одной сессией. |
| Стандарт шифрования данных DES (Data Encryption Standard) | DES является широко используемым алгоритмом симметричного шифрования. DES представляет собой блочный шифр с 56 битным ключом и размером блока в 8 байтов. Заметим, что в TLS, для целей генерации ключей, DES рассматривается как имеющий 8-байтовую длину ключа (64 бита), но при этом обеспечивает безопасность на уровне 56 бит. (Младший бит каждого ключевого байта устанавливается с учетом формирования определенной четности каждого ключевого байта). DES может также работать в режиме, где используется три независимых ключа и три шифрования для каждого блока данных; при этом ключ имеет длину 168 бит (24 байта в методе генерации ключей TLS) и обеспечивает безопасность, соответствующую 112 битам. [DES], [3DES] |
| Стандарт цифровой подписи DSS (Digital Signature Standard) | Стандарт цифровой подписи, включая алгоритм цифровой подписи DSA, одобренный национальным институтом стандартов и технологии США, определенный в NIST FIPS PUB 186, "Digital Signature Standard," май, 1994. [DSS] |
| Цифровая подпись | Цифровые подписи используют криптографию с общедоступным ключом и однопроходные хэш-функции, для того чтобы аутентифицировать подписанные данные и гарантировать их целостность. |
| Диалог | Начальное согласование между клиентом и сервером, которое позволяет определить параметры транзакции. |
| Вектор инициализации (IV) | Когда используется блочный шифр в режиме CBC, перед шифрованием вектор инициализации объединяется с первым блоком исходного текста с помощью операции исключающее ИЛИ. |
| IDEA | 64-битовый блочный шифр, разработанный Xuejia Lai и James Massey. [IDEA] |
| Код аутентификации сообщения (MAC) | Код аутентификации сообщения представляет собой однопроходный хэш, вычисленный для сообщения и некоторых секретных данных. Его трудно взломать без знания секретных данных. Его целью является определение того, было ли сообщение модифицировано при транспортировке. |
| Мастерный секретный код | Безопасные секретные данные, используемые для генерации ключей шифрования, секретных кодов MAC и IV. |
| MD5 | MD5 представляет собой безопасную хэш-функцию, которая преобразует поток данных произвольного размера в дайджест фиксированного размера (16 байт). [MD5] |
| Криптография с общедоступным ключом | Класс криптографических методов, использующих двух-ключевой шифр. Сообщения, зашифрованные с помощью общедоступного ключа, могут быть дешифрованы посредством ассоциированного с ним секретного ключа. Сообщения, подписанные с помощью секретного ключа могут быть верифицированы посредством общедоступного ключа. |
| Однопроходная хэш-функция | Однопроходное преобразование, которое конвертирует произвольное количество данных в хэш фиксированной длины. С вычислительной точки зрения трудно осуществить обратное преобразование. MD5 и SHA представляют собой примеры однопроходных хэш-функций. |
| RC2 | Блочный шифр, разработанный Ron Rivest в компании RSA Data Security, Inc. [RSADSI] и описанный в [RC2]. |
| RC4 | Поточный шифр, лицензированный компанией RSA Data Security [RSADSI]. Совместимый шифр описан в [RC4]. |
| RSA | Очень широко используемый алгоритм шифрования с общедоступным ключом, который может быть использован для шифрования или цифровой подписи. [RSA] |
| salt | Несекретные случайные данные, используемые для того, чтобы сделать передаваемые ключи шифрования более устойчивыми против атак. |
| Сервер | Сервер - это субъект, который реагирует на запросы клиента по установлению соединения. |
| Сессия | Сессия TLS - это ассоциация клиента и сервера. Сессия создается с помощью протокола диалога. Сессия определяет набор криптографических параметров, которые могут использоваться несколькими соединениями. Сессия служит для того, чтобы избежать издержек, связанных с согласованием параметров безопасности каждого соединения. |
| Идентификатор сессии | Идентификатор сессии представляет собой код, генерируемый сервером для того, чтобы идентифицировать конкретную сессию. |
| Ключ записи сервера | Ключ, используемый сервером для записи шифрованных данных. |
| Секретный код MAC записи сервера | Секретные данные, используемые для аутентификации информации, записанной сервером. |
| SHA (Secure Hash Algorithm) | Алгоритм SHA описан в FIPS PUB 180-1. Он формирует дайджест размером 20-байт. Заметим, что все ссылки на SHA в действительности содержат модифицированный алгоритм SHA-1. [SHA] |
| SSL (Secure Socket Layer) | Протокол Netscape SSL [SSL3]. TLS базируется на версии SSL 3.0 |
| Поточный шифр | Алгоритм шифрования, который преобразует ключ в поток криптографически устойчивых данных, которые объединяются с исходным текстом с помощью операции исключающее ИЛИ |
| Симметричный шифр | Смотри массовый шифр. |
| Безопасность транспортного уровня TLS (Transport Layer Security) | Данный протокол; а также рабочая группа Transport Layer Security комиссии Internet Engineering Task Force (IETF). |
C. Определения CipherSuite
| CipherSuite | Is key Exportable Exchange | Шифр | Хэш |
| TLS_NULL_WITH_NULL_NULL | * NULL | NULL | NULL |
| TLS_RSA_WITH_NULL_MD5 | * RSA | NULL | MD5 |
| TLS_RSA_WITH_NULL_SHA | * RSA | NULL | SHA |
| TLS_RSA_EXPORT_WITH_RC4_40_MD5 | * RSA_EXPORT | RC4_40 | MD5 |
| TLS_RSA_WITH_RC4_128_MD5 | RSA | RC4_128 | MD5 |
| TLS_RSA_WITH_RC4_128_SHA | RSA | RC4_128 | SHA |
| TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 | * RSA_EXPORT | RC2_CBC_40 | MD5 |
| TLS_RSA_WITH_IDEA_CBC_SHA | RSA | IDEA_CBC | SHA |
| TLS_RSA_EXPORT_WITH_DES40_CBC_SHA | * RSA_EXPORT | DES40_CBC | SHA |
| TLS_RSA_WITH_DES_CBC_SHA | RSA | DES_CBC | SHA |
| TLS_RSA_WITH_3DES_EDE_CBC_SHA | RSA | 3DES_EDE_CBC | SHA |
| TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA | * DH_DSS_EXPORT | DES40_CBC | SHA |
| TLS_DH_DSS_WITH_DES_CBC_SHA | DH_DSS | DES_CBC | SHA |
| TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA | DH_DSS | 3DES_EDE_CBC | SHA |
| TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA | * DH_RSA_EXPORT | DES40_CBC | SHA |
| TLS_DH_RSA_WITH_DES_CBC_SHA | DH_RSA | DES_CBC | SHA |
| TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA | DH_RSA | 3DES_EDE_CBC | SHA |
| TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA | * DHE_DSS_EXPORT | DES40_CBC | SHA |
| TLS_DHE_DSS_WITH_DES_CBC_SHA | DHE_DSS | DES_CBC | SHA |
| TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA | DHE_DSS | 3DES_EDE_CBC | SHA |
| TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA | * DHE_RSA_EXPORT | DES40_CBC | SHA |
| TLS_DHE_RSA_WITH_DES_CBC_SHA | DHE_RSA | DES_CBC | SHA |
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA | DHE_RSA | 3DES_EDE_CBC | SHA |
| TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 | * DH_anon_EXPORT | RC4_40 | MD5 |
| TLS_DH_anon_WITH_RC4_128_MD5 | DH_anon | RC4_128 | MD5 |
| TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA | DH_anon | DES40_CBC | SHA |
| TLS_DH_anon_WITH_DES_CBC_SHA | DH_anon | DES_CBC | SHA |
| TLS_DH_anon_WITH_3DES_EDE_CBC_SHA | DH_anon | 3DES_EDE_CBC | SHA |
| Алгоритм ключевого обмена | Описание | Ограничение на размер ключа |
| DHE_DSS | Ephemeral DH with DSS signatures | None |
| DHE_DSS_EXPORT | Ephemeral DH with DSS signatures | DH = 512 bits |
| DHE_RSA | Ephemeral DH with RSA signatures | None |
| DHE_RSA_EXPORT | Ephemeral DH with RSA signatures | DH = 512 bits, RSA = none |
| DH_anon | Anonymous DH, no signatures | None |
| DH_anon_EXPORT | Anonymous DH, no signatures | DH = 512 bits |
| DH_DSS | DH with DSS-based certificates | None |
| DH_DSS_EXPORT | DH with DSS-based certificates | DH = 512 bits |
| DH_RSA | DH with RSA-based certificates | None |
| DH_RSA_EXPORT | DH with RSA-based certificates | DH = 512 bits, RSA = none |
| NULL | Отсутствие ключевого обмена | N/A |
| RSA | Ключевой обмен RSA | None |
| RSA_EXPORT | Ключевой обмен RSA | RSA = 512 бит |
Ограничение на размер ключа характеризуют максимальную длину ключевого общедоступного кода, который может быть легально использован в экспортируемом шифровом наборе.
| Шифр | Тип | <Ключевой материал | Расширенный ключевой материал | Эффективное число бит в ключе | Размер IV | Размер блока |
| NULL * | Поток | 0 | 0 | 0 | 0 | N/A |
| IDEA_CBC | Блок | 16 | 16 | 128 | 8 | 8 |
| RC2_CBC_40 * | Блок | 5 | 16 | 40 | 8 | 8 |
| RC4_40 * | Поток | 5 | 16 | 40 | 0 | N/A |
| RC4_128 | Поток | 16 | 16 | 128 | 0 | N/A |
| DES40_CBC * | Блок | 5 | 8 | 40 | 8 | 8 |
| DES_CBC | Блок | 8 | 8 | 56 | 8 | 8 |
| 3DES_EDE_CBC | Блок | 24 | 24 | 168 | 8 | 8 |
| Тип | Указывает является ли шифр поточным или блочным, работающим в режиме CBC. |
| Key Material | Число байтов из key_block, которые используются для генерации ключей записи. |
| Expanded Key Material | Число байтов действительно передаваемых алгоритму шифрования |
| Эффективные биты ключа | Сколько энтропийного материала, содержащегося в материале ключа, передается программам шифрования. |
| Размер IV | Сколько данных нужно сгенерировать для вектора инициализации (initialization vector). Нуль - для поточных шифров; число, равное размеру блока для блочных шифров. |
| Размер блока | Количество данных, которые блочный шифр преобразует за один раз; блочный шифр, работающий в режиме CBC, может переработать блок с размером четным кратным величине его блока. |
| Хэш-функция | Размер хэша | Размер заполнителя |
| NULL | 0 | 0 |
| MD5 | 16 | 48 |
| SHA | 20 | 40 |
D.1. Временные ключи RSA
Экспортные ограничения США устанавливает верхний предел длины ключей RSA равный 512 битам, но не вводят ограничений на размер RSA ключей, используемых для цифровых подписей. Часто нужны сертификаты длиннее 512 бит, так как 512-битные RSA ключи не достаточно безопасны для особо важных транзакций или для приложений требующих долговременной безопасности. Некоторые сертификаты предназначены исключительно для цифровых подписей и не могут использоваться для ключевого обмена.
Когда общедоступный ключ в сертификате не может быть использован для шифрования, сервер подписывает временный RSA-ключ, который затем пересылается.
В экспортируемых приложениях, временный RSA- ключ должен иметь максимально возможную длину (т.e., 512 бит). Так как 512-битовые RSA-ключи имеют относительно низкую безопасность, они должны часто заменяться. Для обычных коммерческих применений предлагается, чтобы ключи заменялись ежедневно или после каждых 500 транзакций, или даже чаще, если это возможно. Заметим, что, так как допускается многократное использование временного ключа, он должен каждый раз при использовании подписываться.
Генерация ключа RSA является трудоемким процессом. Во многих случаях, процессу формирования ключа может быть приписан низкий фоновый приоритет. Как только сформирован новый ключ, старый временный ключ может быть заменен.
D.2. Генерация псевдослучайных чисел и стартовые коды (Seeding)
TLS требует наличия криптографически безопасного генератора псевдослучайных чисел (PRNG). Должны быть приняты меры для формирования стартовых кодов такого PRNG. Доступны генераторы PRNG, базирующиеся на безопасных хэш операциях, например, MD5 и/или SHA, но они не могут предоставить большую безопасность, чем та, которая определяется размером псевдослучайного генерируемого числа. (Например: генератор, базирующийся на MD5 обычно гарантирует безопасность на уровне 128 бит.)
Чтобы оценить необходимую длину порождающего кода, следует добавить несколько битов непредсказуемой информации к каждому байту порождающего кода. Например: времена нажатия клавиш, полученные от стандартного 18.2 кГц PC таймера, может бать 1-2 безопасных бита, но в любом случае размер этого кода должен быть не менее 16 бит. В качестве порождающего кода для 128-битового генератора PRNG может потребоваться приблизительно 100 таких таймерных кодов.
Функции порождающих кодов в RSAREF и в версиях BSAFE до 3.0 не имеют порядковой зависимости. Например: если предоставлены 1000 бит порождающего кода, по одному за раз в результате 1000 обращений к этой функции, PRNG окажется в состоянии, которое зависит только от числа 0 или 1 в порождающем коде (т.e., имеется 1001 возможных конечных состояний).
Приложения, использующие BSAFE или RSAREF должны предпринимать дополнительные меры для обеспечения нужных порождающих кодов. Это может быть осуществлено путем накопления битов порождающего кода в буфере и обработки их как целое. Нужно только учитывать, что такие меры могут создать автокорреляции кодов.
D.3. Сертификаты и аутентификация
За верификацию целостности сертификата отвечает приложение, оно должно также поддерживать аннулирование сообщений, содержащих сертификат. Сертификаты должны всегда верифицироваться, чтобы гарантировать корректность подписи (СА). Выбор и добавление доверительных провайдеров сертификатов (СА) следует делать осмотрительно. Пользователи должны иметь возможность просмотреть информацию о сертификате и корневом провайдере сертификатов (CA).
D.4. Шифровые наборы
TLS поддерживает широкий диапазон размеров ключей и уровней безопасности, включая те, которые предоставляют минимальную или никакой безопасности. Корректная реализация не будет поддерживать много шифровых наборов. Например: 40-битовое шифрование легко ломается, поэтому приложения, требующие надежной безопасности, не должны разрешать применение 40-битовых ключей. Аналогично, анонимный алгоритм Diffie-Hellman не надежен, так как уязвим для атак 'посредников' (man-in-the-middle). Приложения должны накладывать также ограничения на минимальный и максимальный размер ключей. Например: сертификатные цепочки, содержащие 512-битные ключи RSA или подписи не могут считаться удовлетворительными для задач, требующих высокой безопасности.
E. Совместимость с SSL
По историческим причинам и для того чтобы избежать использования резервных номеров портов, прикладные протоколы, безопасность которых обеспечивается с помощью TLS 1.0, SSL 3.0, и SSL 2.0 часто используют один и тот же порт. Например: протокол HTTPS (HTTP с обеспечением безопасности за счет SSL или TLS) использует порт 443 вне зависимости от того, какой протокол безопасности применен. Таким образом, должен быть определен некоторый механизм согласования применения тех или иных протоколов.
TLS версии 1.0 и SSL 3. 0 очень схожи. Клиенты TLS, которые желают согласовать применение SSL 3.0, должны посылать серверу сообщения client hello, используя формат записей SSL 3.0 и посылая {3, 1} в поле версии (TLS 1.0). Если сервер поддерживает только SSL 3.0, он откликнется server hello SSL 3.0. Если же он поддерживает TLS, то пришлет отклик TLS server hello. Дальнейшее согласование будет продолжено согласно с выбранным протоколом.
Аналогично, TLS-сервер, который хочет работать с клиентами SSL 3.0, должен воспринимать сообщения SSL 3.0 client hello и реагировать на server hello, если получено SSL 3.0 client hello с полем версии равным {3, 0}, означающим, что клиент не поддерживает TLS.
Всякий раз, когда клиент уже знает верхний протокол, известный серверу (например, когда возобновляется сессия), он должен инициировать соединение в рамках этого протокола.
Клиенты TLS 1.0, которые поддерживают работу с серверами SSL версии 2.0, должны посылать сообщения client hello SSL версии 2.0 [SSL2]. Серверы TLS должны воспринимать любой формат client hello, если они хотят поддерживать работу с клиентами SSL 2.0, на том же порту соединения. Единственное отклонение спецификации от версии 2.0 является возможность специфицировать версию со значением три и поддерживать больше шифровых типов в CipherSpec.
Возможность посылать сообщения client hello версии 2.0 следует исключить из употребления так быстро, как это возможно. Разработчики должны предпринять все меры, чтобы ускорить эти работы. Версия 3.0 предоставляет лучшие механизмы для введения новых версий.
Следующие шифровые спецификации являются переходными от SSL версии 2.0. Они предполагают использования RSA для ключевого обмена и аутентификации.
V2CipherSpec TLS_RC4_128_WITH_MD5 | = { 0x01,0x00,0x80 }; |
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 | = { 0x02,0x00,0x80 }; |
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 | = { 0x03,0x00,0x80 }; |
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 | = { 0x04,0x00,0x80 }; |
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 | = { 0x05,0x00,0x80 }; |
| V2CipherSpec TLS_DES_64_CBC_WITH_MD5 | = { 0x06,0x00,0x40 }; |
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 | = { 0x07,0x00,0xC0 }; |
Шифровые спецификации совместимые с TLS могут быть включены в сообщения client hello версии 2.0, используя описанный ниже синтаксис. Любой элемент V2CipherSpec с первым байтом равным нулю будет игнорироваться серверами версии 2.0. Клиенты, посылающие любую из перечисленных выше спецификаций V2CipherSpecs должны также включать и TLS-эквивалент (смотри приложение A.5):
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
E.1. Hello клиента версия 2
Сообщение client hello версии 2.0 представлены ниже. Истинные определения предполагаются совпадающими со спецификацией SSL версии 2.0.
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;
| msg_type | Это поле, в сочетании с полем версии, идентифицирует сообщение client hello версии 2. Значение поля должно быть равно единице (1). |
| Version | Высшее значение версии протокола, поддерживаемое клиентом (равно ProtocolVersion.version, смотри приложение A.1). |
| cipher_spec_length | Это поле равно полной длине поля cipher_specs. Оно не может быть равно нулю и должно быть кратным длине V2CipherSpec (3). |
| session_id_length | Это поле должно иметь значение нуль или 16. Если равно нулю, клиент формирует новую сессию. Если равно 16, поле session_id будет содержать 16 байт идентификации сессии. |
| challenge_length | Длина в байтах обращения клиента к серверу, чтобы аутентифицировать себя. Это значение должно равняться 32. |
| cipher_specs | Это список всех CipherSpecs, которые клиент хочет и может использовать. Здесь должна быть по крайней мере одна спецификация CipherSpec, приемлемая для сервера. |
| session_id | Если длина этого поля не равна нулю, оно будет содержать идентификатор сессии, которую клиент хочет возобновить. |
| Challenge | Обращение клиента к серверу с целью идентификации самого себя. Его значение представляет собой псевдослучайное число произвольной длины. Сервер TLS проверяет обращение клиента, чтобы получить данные ClientHello.random (дополненные лидирующими нулями, если это нужно), как это специфицировано в данном протоколе. Если длина обращения больше чем 32 байта, то используются только последние 32 байта. Допускается (но не обязательно) для сервера V3 отклонять V2 ClientHello, которые имеют меньше 16 байтов обращения клиента. |
Запросы возобновления TLS- сессии должны использовать сообщение TLS client hello.
E.2. Избежание атак понижения версии посредником (man-in-the-middle)
Когда клиенты TLS возвращаются к режиму совместимости с версией 2.0, они должны использовать специальное форматирование блоков PKCS #1. Это сделано так, что TLS-серверы будут отклонять сессии версии 2.0 с совместимыми TLS-клиентами.
Когда клиенты TLS работают в режиме совместимости с версией 2.0, они устанавливают правые случайные 8 байт (менее значимые) заполнителя PKCS (исключая завершающий нулевой заполнитель) для RSA-шифрования поля ENCRYPTED-KEY-DATA CLIENT-MASTER-KEY, равными 0x03 (остальные байты заполнителя содержат произвольные случайные значения). После дешифрования поля ENCRYPTED-KEY-DATA, серверы, которые получают блоки, заполненные по такой схеме, продолжают свою работу обычным образом.
F. Анализбезопасности
Протокол TLS создан для того, чтобы установить безопасное соединение между клиентом и сервером через канал не гарантирующий безопасность. В данном документе делаются несколько традиционных предположений, включая то, что атакующие имеют достаточно большие вычислительные ресурсы и не могут получить секретную информацию из источников, помимо протокольных. Предполагается, что атакующий может перехватить, модифицировать, уничтожать и подменить сообщения, посланные по коммуникационному каналу.
F.1. Протокол диалога
Протокол диалога несет ответственность за выбор CipherSpec и генерацию мастерного секретного кода (Master Secret), которые вместе являются первичными криптографическими параметрами, сопряженными с безопасной сессией. Протокол диалога может также аутентифицировать партнеров, которые имеют сертификаты, подписанные пользующимся доверием провайдером сертификатов.
F.1.1. Аутентификация и обмен ключами
TLS поддерживает три режима аутентификации: аутентификация обоих партнеров, аутентификация сервера не аутентифицированным клиентом, и полностью анонимная. Всякий раз, когда сервер аутентифицирован, канал безопасен со стороны атак 'посредника' (man-in-the-middle), по анонимные сессии полностью беззащитны для такого рода атак.
Анонимные серверы не могут аутентифицировать клиентов. Если сервер аутентифицирован, его сообщение сертификата должно предоставить корректную сертификационную цепочку, ведущую к приемлемому провайдеру сертификатов. Аналогично, аутентифицированные клиенты должны предоставить приемлемый сертификат серверу. Каждый партнер ответственен за верификацию сертификата противоположной стороны, за его пригодность.
Общей целью процесса ключевого обмена является формирование pre_master_secret, известного партнерами обмена, но неизвестного хакерам. Код pre_master_secret будет использован для генерации master_secret (смотри раздел 8.1). Код master_secret необходим, чтобы сформировать сообщения верификации сертификата, шифровальных ключей, секретных кодов MAC финального сообщения (смотри разделы 7.4.8, 7.4.9 и 6.3). Путем посылки корректного финального сообщения (finished) партнеры подтверждают то, что они знают правильное значение pre_master_secret.
F.1.1.1. Анонимный обмен ключами
Полностью анонимные сессии могут быть реализованы с помощью ключевого обмена на основе алгоритмов RSA или Diffie-Hellman. При анонимном RSA, клиент шифрует pre_master_secret с помощью не сертифицированного общедоступного ключа сервера, полученного из его сообщения ключевого обмена. Результат посылается в сообщении ключевого обмена клиента. Так как злоумышленники не знают секретного ключа сервера, практически не реально для них дешифровать pre_master_secret. Заметим, что анонимные шифровые RSA-наборы в данном документе не определены.
В случае алгоритма Diffie-Hellman, общедоступные параметры сервера содержатся в его сообщении ключевого обмена, а параметры клиента посылаются в его сообщении ключевого обмена. Злоумышленники, которые не знают секретных ключей, не способны выполнить вычисления согласно алгоритму Diffie-Hellman и получить правильный результат (т.e. pre_master_secret).
Полностью анонимные соединения предоставляют защиту только против пассивных видов атак. Если только не используется надежно защищенный канал, позволяющий проверку того, что финальное сообщение не подменено злоумышленником, в ситуациях, где возможна активная атака 'посредника' (man-in-the-middle) необходима аутентификация сервера.
F.1.1.2. Обмен ключами по схеме RSA с аутентификацией
В случае RSA, ключевой обмен и аутентификация сервера совмещаются. Общедоступный ключ может содержаться в сертификате сервера или быть временным RSA-ключом, посланным в сообщении ключевого обмена сервера. Когда используются временные RSA-ключи, они подписываются сертификатом сервера RSA или DSS. Подпись включает текущее значение ClientHello.random, поэтому старые подписи и временные ключи не могут быть повторно использованы. Серверы могут использовать одиночный временный RSA-ключ для нескольких сессий.
Опция временного ключа RSA полезна, если серверы нуждаются в больших сертификатах, но вынуждены соглашаться с правительственными регламентациями для размеров ключей при ключевом обмене.
После проверки сертификата сервера, клиент шифрует pre_master_secret с помощью общедоступного ключа сервера. В случае успешной дешифровки pre_master_secret и выработки корректного финального сообщения, сервер демонстрирует, что он знает секретный ключ, соответствующий его сертификату.
Когда RSA используется для ключевого обмена, клиенты аутентифицируются, используя сообщение верификации сертификата (смотри раздел 7.4.8). Клиент подписывает значение, полученное из master_secret и все предыдущие сообщения диалога. Эти сообщения диалога включают сертификат сервера, который связывает подпись с сервером, и ServerHello.random, связывающий подпись с текущим процессом диалога.
F.1.1.3. Обмен ключами по схеме Diffie-Hellman с аутентификацией
Когда используется пересылка ключей по схеме Diffie-Hellman, сервер может либо предоставить сертификат, содержащий фиксированные параметры Diffie-Hellman, либо использовать сообщение ключевого обмена сервера, чтобы послать набор временных параметров, подписанных сертификатом DSS или RSA. Временные параметры хэшируются со значениями hello.random до формирования подписи, чтобы гарантировать, что злоумышленник не сможет воспользоваться старыми параметрами. В любом случае клиент может проверить сертификат или подпись, чтобы убедиться в том, что параметры принадлежат серверу.
Если клиент имеет сертификат, содержащий фиксированные параметры Diffie-Hellman, его сертификат содержит информацию, необходимую для ключевого обмена. Заметим, что в этом случае клиент и сервер получат один и тот же результат (т.e., pre_master_secret) каждый раз, когда они обмениваются информацией. Чтобы предотвратить пребывание в памяти pre_master_secret дольше, чем это требуется, этот код должен быть, как можно быстрее преобразован в master_secret. Параметры клиента Diffie-Hellman должны быть совместимыми с теми, что поставляются сервером для ключевого обмена.
Если клиент имеет стандартный сертификат DSS или RSA или он не аутентифицирован, тогда клиент посылает набор временных параметров серверу в сообщении ключевого обмена клиента, затем опционно использует сообщение верификации сертификата, чтобы аутентифицировать себя.
F.1.2. Атаки понижения версии
Так как TLS содержит существенные улучшения по сравнению с SSL версии 2.0, атакующие могут попытаться создавать TLS-совместимых клиентов и серверов, чтобы вернуться к версии 2.0. Эта атака может произойти, если (и только если) два TLS-совместимых партнера используют диалог в SSL 2.0.
Хотя решение, использующее неслучайное заполнение сообщения блока PKCS #1 типа 2, не является красивым, оно предоставляет безопасный путь для серверов версии 3.0, чтобы заметить такую атаку. Это решение не безопасно по отношению злоумышленников, которые могут попытаться подсунуть ключ и осуществить подмену сообщения ENCRYPTED-KEY-DATA, содержащего тот же ключ (но с нормальным заполнителем) до момента истечения порога ожидания, заданного приложением. Партнеры, озабоченные атаками этого типа, никогда не должны использовать 40-битовые ключи шифрования. Вариация заполнителя младших 8 байт PKCS не увеличивает безопасности, так как это просто эквивалентно увеличению размера входного блока на 8 байт.
F.1.3. Регистрация атак против протокола диалога
Атакующий может попытаться повлиять на диалоговый обмен, чтобы заставить партнеров выбрать другой алгоритм шифрования, отличный от того, который бы они выбрали сами.
Так как многие реализации будут поддерживать 40-битовое экспортное шифрование, а некоторые могут даже поддерживать отсутствие шифрования или алгоритмы MAC, возможность такой атаки должна всегда учитываться.
Для этой атаки злоумышленник должен активно изменить одно или более сообщений диалога. Если это произойдет, клиент и сервер вычислят разные значения для хэшей сообщения диалога. В результате, партнеры не воспримут друг от друга финальные сообщения. Без master_secret, злоумышленник не может восстановить финальные сообщения, таким образом, факт атаки будет раскрыт.
F.1.4. Возобновляемые сессии
Когда соединение установлено путем возобновления сессии, новые значения ClientHello.random и ServerHello.random хэшируются вместе с master_secret сессии. Если установлено, что код master_secret не поврежден и что хэш-операции, использованные для получения ключей и секретных кодов MAC также безопасны, то соединение можно считать безопасным и независимым от предыдущих соединений. Атакующие не могут использовать известные ключи шифрования или секретные коды MAC, для того, чтобы скомпрометировать master_secret без нарушения исполнения операций хэширования.
Сессии не могут возобновляться, если только клиент и сервер не хотят этого. Если любой из партнеров подозревает, что сессия скомпрометирована, или что сертификаты не действительны, он должен потребовать полного диалога. Для верхнего предела времени жизни идентификатора сессии предлагается значение 24 часа, так как атакующий, получивший значение master_secret может подменить скомпрометированного партнера пока сохраняется старое значение ID-сессии. Приложения, которые могут работать в относительно небезопасной среде не должны записывать ID-сессии в постоянную память.
F.1.5. MD5 и SHA
TLS использует хэш-функции весьма консервативно. Где возможно, как MD5, так и SHA используются вместе для того, чтобы не катастрофические дефекты в одном алгоритме не приводили к разрушения всего протокола.
F.2. Защита прикладных данных
Код master_secret кэшируется с помощью ClientHello.random и ServerHello.random, чтобы получить уникальные ключи для шифрования данных и секретные коды MAC для каждого соединения.
Исходящие данные перед посылкой защищаются с помощью MAC. Для того чтобы исключить атаки, связанные с модификаций или воспроизведения сообщений, из секретного кода MAC вычисляется MAC, номер по порядку, длина сообщения, содержимое сообщения и две фиксированные символьные строки. Поле типа сообщения необходимо, чтобы гарантировать то, что сообщения, предназначенные для одного клиента слоя записи TLS, не будут переадресованы другому. Номер по порядку гарантирует, что попытки уничтожить или поменять порядок сообщений будут детектированы. Так как номера по порядку имеют 64 бита, они не могут быть переполнены. Сообщения от одного партнера не могут быть вставлены в выходные сообщения другого, так как они используют независимые секретные коды MAC. Аналогично, ключи записи сервера и клиента независимы, так что ключи поточных шифров используются только раз.
Если атакующий расколол ключ шифрования, все сообщения, зашифрованные этим ключом, могут быть прочитаны. Аналогично, раскрытие ключа MAC может сделать возможной атаку, сопряженную с модификацией передаваемых сообщений. Так как MAC зашифрован, атаки модификации сообщений требуют также взлома и алгоритма шифрования.
Секретные коды MAC могут быть больше, чем ключи шифрования, поэтому сообщения могут оставаться устойчивы против повреждений, даже если взломаны ключи шифрования.
G. Патентное заявление
Следует иметь в виду, что применение ряда алгоритмов ограничено действующими патентами. К их числу относятся, например, SSL (патент США No. 5,657,390; Netscape). Существуют ограничения на коммерческое использование алгоритма RSA (RSA Data Security, Inc.). Политика компании Netscape в этой области достаточно либеральна.
Ссылки
| [3DES] | W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. |
| [BLEI] | Bleichenbacher D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1" in Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1--12, 1998. |
| [DES] | ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption," American National Standards Institute, 1983. |
| [DH1] | W. Diffie and M. E. Hellman, "New Directions in Cryptography," IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977, pp. 74-84. |
| [DSS] | NIST FIPS PUB 186, "Digital Signature Standard," National Institute of Standards and Technology, U.S. Department of Commerce, May 18, 1994. |
| [FTP] | Postel J., and J. Reynolds, "File Transfer Protocol", STD-9, RFC-959, October 1985. |
| [HTTP] | Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC-1945, May 1996. |
| [HMAC] | Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC-2104, February 1997. |
| [IDEA] | X. Lai, "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992. |
| [MD2] | Kaliski, B., "The MD2 Message Digest Algorithm", RFC-1319, April 1992. |
| [MD5] | Rivest, R., "The MD5 Message Digest Algorithm", RFC-1321, April 1992. |
| [PKCS1] | RSA Laboratories, "PKCS #1: RSA Encryption Standard," version 1.5, November 1993. |
| [PKCS6] | RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax Standard," version 1.5, November 1993. |
| [PKCS7] | RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax Standard," version 1.5, November 1993. |
| [PKIX] | Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC-2459, January 1999. |
| [RC2] | Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, January 1998. |
| [RC4] | Thayer, R. and K. Kaukonen, A Stream Cipher Encryption Algorithm, Work in Progress. |
| [RSA] | R. Rivest, A. Shamir, and L. M. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126. |
| [RSADSI] | Contact RSA Data Security, Inc., Tel: 415-595-8782 |
| [SCH] | B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C, Published by John Wiley & Sons, Inc. 1994. |
| [SHA] | NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, Work in Progress, May 31, 1994. |
| [SSL2] | Hickman, Kipp, "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995. |
| [SSL3] | A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996. |
[TCP] | Postel, J., "Transmission Control Protocol," STD-7, RFC 793, September 1981. |
| [TEL] | Postel J., and J. Reynolds, "Telnet Protocol Specifications", STD-8, RFC-854, May 1993. |
| [TEL] | Postel J., and J. Reynolds, "Telnet Option Specifications", STD-8, RFC-855, May 1993. |
| [X509] | CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988. |
| [XDR] | R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data Representation Standard, August 1995. |
http://www.imc.org/ietf-tls/mail-archive/
