A Значения протокольных констант

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)

} HandshakeType;

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;

A.4.1. Сообщения Hello

struct { } HelloRequest;

struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random;

opaque SessionID;

uint8 CipherSuite[2];

enum { null(0), (255) } CompressionMethod;

struct { ProtocolVersion client_version; Random random;

SessionID session_id;

CipherSuite cipher_suites16-1>;

CompressionMethod compression_methods8-1>;

} ClientHello;

struct { ProtocolVersion server_version;

Random random;

SessionID session_id;

CipherSuite cipher_suite;

CompressionMethod compression_method;

} ServerHello;

A.4.2. Аутентификация сервера и сообщения обмена ключами

opaque ASN.1Cert24-1>;

struct { ASN.1Cert certificate_list24-1>;} Certificate;

enum { rsa, diffie_hellman } KeyExchangeAlgorithm;

struct { opaque RSA_modulus16-1>; opaque RSA_exponent16-1>;

} ServerRSAParams;

struct { opaque DH_p16-1>; opaque DH_g16-1>;

opaque DH_Ys16-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 DistinguishedName16-1>;

struct { ClientCertificateType certificate_types8-1>;

DistinguishedName certificate_authorities16-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_Yc16-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 };

Следующие шифровые наборы используются для полностью анонимного обмена с применением алгоритма Diffie-Hellman, в котором ни один из партнеров не аутентифицирован. Заметим, что этот режим уязвим для атак 'посредника' (man-in-the-middle) и по этой причине неприемлем.

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;

Алгоритм установления связи В

Рисунок 4.4.3.3. Алгоритм установления связи. В рамках представлены состояния клиента и сервера; пунктиром отмечены изменения cостояния после посылки сообщения (см. также Рисунок 4.4.3.4)

Префикс S на рисунке указывает на сервер, а С – на клиента. Параметры в скобках обозначают относительные значения ISN. После установления соединения ISN(S) = s_seq_1, а ISN(C) = c_seq_1.

Каждое соединение должно иметь свой неповторимый код ISN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа ("passive open"), а операционная система на другом конце ставится в режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11 состояний (established, closed, listen, syn_sent, syn_received и т.д.; см. также RFC-793), переход между которыми строго регламентирован. Машина состояний для протокола TCP может быть описана диаграммой, представленной на Рисунок 4.4.3.4. Здесь состояние closed является начальной и конечной точкой последовательности переходов. Каждое соединение стартует из состояния closed. Из диаграммы машины состояний видно, что ни одному из состояний не поставлен в соответствие какой-либо таймер. Это означает, что машина состояний TCP может оставаться в любом из состояний сколь угодно долго. Исключение составляет keep-alive таймер, но его работа является опционной, а время по умолчанию составляет 2 часа. Это означает, что машина состояния может оставаться 2 часа без движения. В случае, когда две ЭВМ (C и S) попытаются установить связь друг с другом одновременно, реализуется режим simultaneous connection (RFC-793). Обе ЭВМ посылают друг другу сигналы SYN. При поучении этого сигнала партнеры посылают отклики SYN+ACK. Обе ЭВМ должны обнаружить, что SYN и SYN+ACK относятся к одному и тому же соединению. Когда C и S обнаружат, что SYN+ACK соответствует посланному ранее SYN, они выключат таймер установления соединения и перейдут непосредственно в состояние syn_recvd.

В состоянии established пакет будет принят сервером, если его ISN лежит в пределах s_ack, s_ack+s_wind (s_wind – ширина окна для сервера; см.
Рисунок 4.4.3.5). Аналогичный диапазон isn для клиента выглядит как: c_ack, c_ack+c_wind (c_wind – ширина окна для клиента). c_wind и s_wind могут быть не равны. Пакеты, для которых эти условия не выполняются, будут отброшены.

Рассмотрим пример установления соединения для случая FTP-запроса (См. также http://www.cis.ohio-state.edu/~dolske/gradwork/cis694q). Пусть клиент С запускает процесс установления FTP-соединения с сервером s. Обычный порядок установления соединения показан ниже (см. Рисунок 4.4.3.3):

c -> s:syn(isnc)

s -> c:syn(isns), ack(isnc)

c -> s: ack(isns) (Связь установлена)

c -> s: данные

и/или

s -> c: данные

isn – идентификатор пакета, посылаемого клиентом (С) или сервером (S). Клиент, послав syn серверу S, переходит в состояние syn_sent. При этом запускается таймер установления соединения. Как при установлении соединения так и при его разрыве приходится сталкиваться с проблемой двух армий. Представим себе, что имеется две армии А и Б, причем Б больше по численности чем А. Армия Б разделена на две части, размещенные по разные стороны от армии А. Если две части армии Б одновременно нападут на армию А, победа гарантирована. В то же время нападение на А одной из частей армии Б обрекает ее на поражение. Но как обеспечить одновременность? Здесь предполагается, что радио еще не изобретено и передача сообщений осуществляется вестовыми, которые в нашем случае могут быть перехвачены врагом. Как убедиться, что вестовой дошел? Первое, что приходит в голову, это послать другого вестового с подтверждением. Но он также с некоторой вероятностью может быть перехвачен. А отправитель не будет знать, дошел ли он. Ведь если сообщение перехвачено, отправитель первичного запроса не выдаст команды на начало, так как не уверен, дошло ли его первое сообщение. Возникает вопрос, существует ли алгоритм, который бы гарантировал надежность синхронизации решений путем обмена сообщениями при ненадежной доставке? Повысит ли достоверность увеличение числа обменов между партнерами? Ответом на этот вопрос будет - нет не существует.

В этом читатель, порассуждав логически, может убедиться самостоятельно. Не трудно видеть, что схожие проблемы возникают в любом протоколе, работающем через установление соединения. Чаще всего эта проблема решается путем таймаутов и повторных попыток (это, слава богу, не война и все обходится без людских жертв).

Сервер, получив SYN, откликается посылкой другого SYN. Когда С получает SYN от S (но не получает ACK, например, из-за его потери или злого умысла), он предполагает, что имеет место случай одновременного открытия соединения. В результате он посылает s syn_ack, отключает таймер установления соединения и переходит в состояние syn_received. Сервер получает syn_ack от C, но не посылает отклика. Тогда С ожидает получения syn_ack в состоянии syn_received. Так как время пребывания в этом состоянии не контролируется таймером, С может остаться в состоянии syn_received вечно. Из-за того, что переходы из состояния в состояние не всегда четко определены, протокол tcp допускает и другие виды атак (некоторые из них описаны в разделе “Сетевая безопасность”), там же рассмотрены алгоритмы задания и изменения ISN.

Хотя TCP-соединение является полнодуплексным, при рассмотрении процесса разрыва связи проще его рассматривать как два полудуплексных канала, каждый из которых каналов ликвидируется независимо. Сначала инициатор разрыва посылает сегмент с флагом FIN, сообщая этим партнеру, что не намерен более что-либо передавать. Когда получение этого сегмента будет подтверждено (ACK), данное направление передачи считается ликвидированным. При этом передача информации в противоположном направлении может беспрепятственно продолжаться. Когда партнер закончит посылку данных, он также пошлет сегмент с флагом FIN. По получении отклика ACK виртуальный канал считается окончательно ликвидированным. Таким образом, для установление связи требуется обмен тремя сегментами, а для разрыва - четырьмя. Но протокол допускает совмещение первого ACK и второго FIN в одном сегменте, сокращая полное число закрывающих сегментов с четырех до трех.

Машина состояний для протокола TCP не предусматривает изменения состояний при посылке или получении обычных пакетов, содержащих данные.

B Словарь

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

* Указывает, что IsExportable = истинно

Алгоритм ключевого обмена	Описание	Ограничение на размер ключа
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

* Указывает IsExportable = 'истинно'.

Тип	Указывает является ли шифр поточным или блочным, работающим в режиме CBC.
Key Material	Число байтов из key_block, которые используются для генерации ключей записи.
Expanded Key Material	Число байтов действительно передаваемых алгоритму шифрования
Эффективные биты ключа	Сколько энтропийного материала, содержащегося в материале ключа, передается программам шифрования.
Размер IV	Сколько данных нужно сгенерировать для вектора инициализации (initialization vector). Нуль - для поточных шифров; число, равное размеру блока для блочных шифров.
Размер блока	Количество данных, которые блочный шифр преобразует за один раз; блочный шифр, работающий в режиме CBC, может переработать блок с размером четным кратным величине его блока.

Хэш-функция	Размер хэша	Размер заполнителя
NULL	0	0
MD5	16	48
SHA	20	40

Цели

2. Цели

Целями протокола TLS в порядке приоритетности являются:

Криптографическая безопасность. TLS должен использоваться для установления безопасного соединения между двумя партнерами.

Совместимость. Независимые программисты должны быть способны разрабатывать приложения, использующие TLS, которые будут способны успешно обмениваться криптографическими параметрами без знания особенностей программ друг друга.

Расширяемость. TLS ищет способ, как при необходимости встроить в систему новые ключи и методы шифрования. Здесь имеются две побочные цели: исключить необходимость создания нового протокола (что может быть сопряжено с введением новых слабых мест) и сделать ненужным внедрение новой библиотеки, обеспечивающей безопасность.

Относительная эффективность. Криптографические операции требуют больших мощностей ЦПУ, особенно этим славятся операции с открытыми ключами. По этой причине, протокол TLS имеет опционную схему кэширования сессии, что позволяет уменьшить число соединений, устанавливаемых с использованием новых временных буферов. Были приняты меры, чтобы уменьшить сетевую активность.

3. Цели данного документа

Этот документ и сам протокол TLS базируются на спецификации протокола SSL 3.0, опубликованного Netscape. Различие между этим протоколом и SSL 3.0 не значительны, но они вполне достаточны, чтобы сделать TLS 1.0 и SSL 3.0 не совместимыми (хотя TLS 1.0 имеет механизм, с помощью которого приложения могут поддерживать SSL 3.0). Этот документ предназначен, прежде всего, для читателей, которые будут создавать протокольные приложения, и осуществлять их криптографический анализ. Спецификация была написана именно с такими намерениями и именно для этих двух групп разработчиков. Для этой цели многие правила и структуры данных, зависимые от алгоритма, включены в текст (а не в приложение), обеспечивая более легкий к ним доступ.

4. Язык представления

Представление данных в этом документе напоминает синтаксис языка Си и XDR [XDR], но эти параллели достаточно приблизительны и не имеют никакого отношения к самому протоколу TSL.
эти представления применены лишь для целей упрощения восприятия материала.

4.1. Базовый размер блока

Базовым блоком данных считается один байт (т.e. 8 бит). Многобайтовые информационные элементы представляют собой объединение последовательности байтов слева направо и сверху вниз. Многобайтовые элементы извлекаются из байтового потока (используя нотацию Си) следующим образом:

value = (байт[0]

Этот порядок байтов для многобайтовых последовательностей является стандартным для сетей (big endian).

4.2. Разное

Комментарии начинаются с "/*" и завершаются "*/". Опционные компоненты выделяются с помощью помещения их в двойные квадратные скобки "[[ ]]". Однобайтовые объекты, содержащие не интерпретируемые данные, имеют 'непрозрачный' тип (opaque).

4.3. Векторы

Вектор (одномерный массив) является потоком однородных информационных элементов. Размер вектора может быть специфицирован во время документирования или оставаться не специфицированным вплоть до начала работы. В любом случае длина определяет число байтов, а не число элементов в векторе. Синтаксис спецификации нового типа T', который является вектором фиксированной длины типа T, имеет вид T T'[n];

Здесь T' занимает в информационном потоке n байт, где n кратно размеру T. Длина вектора не включается в кодированный поток.

В следующем примере Datum определен, как три последовательные байта, которые не интерпретируются протоколом, в то время как Data представляет собой три вектора Datum, состоящие из девяти байт.

opaque Datum[3];	/* три не интерпретируемые байта */
Datum Data[9];	/* 3 последовательных 3-байтовых вектора */

Векторы переменной длины определяются путем спецификации субдиапазона легальных длин, используя нотацию . При кодировании реальная длина предшествует потоку байтов, образующих вектор. Длина имеет форму числа, занимающего столько байт, сколько нужно, чтобы специфицировать максимально возможную длину вектора (ceiling). Вектор переменной длины с действительным полем длины равным нулю является пустым вектором.

T T';

В следующем примере, обязательным является вектор, который должен содержать от 300 до 400 байт непрозрачного типа. Он не должен быть пустым. Поле действительной длины занимает два байта, uint16, достаточных, чтобы представить значение 400 (смотри раздел 4.4). С другой стороны, longer может представить до 800 байт данных, или 400 uint16 элементов, и может быть пустым. Его кодовое представление будет включать два байта поля реальной длины, за которым будет следовать вектор. Длина закодированного вектора должна быть четной, кратной длине одиночного элемента (например: 17-байтовый вектор uint16 будет нелегальным).

opaque mandatory;	/* поле длины имеет 2 байта, не может быть пустым */
uint16 longer;	/* 0 - 400 16-битовое целое число без знака */

4.4. Числа

Базовый числовой тип данных представляет собой байт без знака (uint8). Все более длинные типы цифровых данных образуются из фиксированной последовательности байт без знака, объединенных вместе, как это описано в разделе 4.1,. Следующие числовые типы являются предопределенными.

uint8 uint16[2];

uint8 uint24[3];

uint8 uint32[4];

uint8 uint64[8];

Все значения здесь и в дальнейшем записываются в 'сетевом порядке' (big-endian); uint32 представленное шестнадцатеричными байтами 01 02 03 04 эквивалентно десятичному значению 16909060.

4.5. Нумерованный тип

Еще одним типом данных является enum (enumerated). Поле типа enum предполагает, что величина декларирована при определении. Каждое определение дает новый тип. Только нумерованные элементы того же типа могут присваиваться и сравниваться. Каждому нумерованному элементу должно быть присвоено значение, как это показано в следующем примере. Так как нумерованные элементы неупорядочены, им может быть присвоено любое уникальное значение в любом порядке.

enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

Нумерованные элементы занимают в байтовом потоке столько места, сколько требует максимальное определенное порядковое значение. Следующее определение требует использования одного байта для поля типа Color (цвет).

enum { red(3), blue(5), white(7) } Color;

Можно опционно специфицировать значение без ассоциированной с ним метки, чтобы задать ширину без определения избыточного элемента. В следующем примере, Taste в потоке данных занимает два байта, но может предполагать значения 1, 2 или 4.

enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

Имена элементов нумерации собраны в пределах определенного типа. В первом примере, полная ссылка на второй элемент будет выглядеть как Color.blue. Такое описание не требуется, если объект присвоения (target) хорошо специфицирован.

Color color = Color.blue;	/* чрезмерная спецификация, допустимо */
Color color = blue;	/* правильно, тип задан неявно */

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

enum { low, medium, high } Amount;

4.6. Сконструированные типы

Типы структуры могут быть сформированы для удобства из примитивных типов. Каждая спецификация декларирует новый, уникальный тип. Синтаксис определения весьма похож на используемый в Си.

struct {

	T1 f1;
	T2 f2;
	...
	Tn fn;} [[T]];

Поля в структуре могут быть квалифицированы, используя имена типов, которые синтаксис подобный нумерованным элементам. Например, T.f2 относится ко второму полю предыдущей декларации. Структурные определения допускают вложения.

4.6.1. Варианты

Определенные структуры могут иметь варианты, базирующиеся на некотором знании того, что доступно в среде. Селектор должен иметь тип нумерованного элемента, который определяет возможные варианты структуры. Телу структуры варианта может быть присвоена метка для ссылок. Механизм, с помощью которого при работе выбирается вариант, языком презентации не определен.

struct {

	T1 f1;
	T2 f2;
	....
	Tn fn;
	select (E) {
	case e1: Te1;
	case e2: Te2;
	....
	case en: Ten;
	} [[fv]];} [[Tv]];

Например:

enum { apple, orange } VariantTag;

struct {

	uint16 number;
	opaque string; /* переменная длина */
	} V1;

struct {

	uint32 number;
	opaque string[10]; /* фиксированная длина */
	} V2;

struct {

	select (VariantTag) {	/* value of selector is implicit */
	case apple: V1;	/* VariantBody, tag = apple */
	case orange: V2;	/* VariantBody, tag = orange */
	} variant_body;	/* optional label on variant */
	} VariantRecord;

Структуры варианта могут быть подготовлены (сужены) путем спецификации значения селектора до спецификации типа. Например: orange VariantRecord является суженным типом для VariantRecord, содержащего variant_body типа V2.

4.7. Криптографические атрибуты

В TSL используются четыре криптографические операции: цифровая подпись, блочное и поточное шифрование и шифрование с помощью общедоступного ключа. Криптографические ключи соответствуют состоянию текущей сессии (смотри раздел 6.1).

Алгоритм цифровой подписи включает в себя однопроходные хэш-функции, служащие для преобразования подписываемого текста. Элемент с цифровой подписью кодируется как непрозрачный вектор 16-1>, где длина специфицируется алгоритмом подписи и ключом.

В подписи RSA, 36-байтовая структура двух хэшей (один SHA и один MD5) кодируется с помощью секретного ключа. Описание кодировки смотри в [PKCS1].

В DSS, 20 байтов хэша SHA передаются непосредственно алгоритму цифровой подписи DSA (Digital Signing Algorithm) без дополнительного хэширования. В результате получаются числа r и s. Подпись DSS представляет собой непрозрачный вектор, содержимое которого представляет собой результат DER-кодирования:

DssSigValue ::= SEQUENCE {	r	INTEGER,
	s	INTEGER}

При поточном шифровании, исходный текст сначала объединяется с псевдослучайным кодом идентичной длины (формируется специальным генератором) с помощью операции исключающее ИЛИ.

При использовании блочного шифра, каждый блок исходного текста преобразуется в зашифрованный кодовый блок той же длины. Все блочные шифрования выполняются в режиме CBC (Cipher Block Chaining), и все зашифрованные блочные элементы будут иметь размер, кратный длине шифрового блока.

При шифровании с использованием общедоступного ключа, алгоритм открытого ключа используется для шифрования данных так, чтобы их можно было дешифровать только с помощью секретного ключа, который образует пару с открытым ключом. Элемент, зашифрованный с помощью открытого ключа, выглядит как непрозрачный вектор 16-1>, где длина определяется алгоритмом подписи и ключом.

В следующем примере:

stream-ciphered struct {

	uint8 field1;
	uint8 field2;
	digitally-signed opaque hash[20];} UserType;

Содержимое хэша передается алгоритму подписи, затем вся структура шифруется с привлечением поточного шифра. Длина этой структуры в байтах будет равна 2 байтам для поля field1 и field2, плюс два байта для длины подписи, плюс длина выходных данных алгоритма подписи. Это известно благодаря тому факту, что алгоритм и ключ для подписи известны до кодирования или декодирования этой структуры.

4.8. Константы

Типофицированные константы могут быть определены для целей спецификации путем декларации символа нужного типа и присвоения ему определенных значений. Не полностью специфицированные типы (непрозрачные элементы, векторы переменной длины, и структуры, которые содержат непрозрачные элементы) не могут стать объектами присвоения. Нельзя опускать ни одно поле многоэлементной структуры или вектора.

Например,

struct { uint8 f1; uint8 f2;} Example1;

Example1 ex1 = {1, 4};

/* assigns f1 = 1, f2 = 4 */

T1 имеют пропускную способность, соответствующую

2.3 Цифровые каналы T1 и Е1

Системы (каналы) T1 имеют пропускную способность, соответствующую 24 аналоговым каналам с полосой 0-3.3 кГц (американская версия стандарта). Частота стробирования равна 8 кГц, что соответствует передаче 8000 кадров в сек. После каждых 6000 футов коаксиального кабеля ставятся системы регенерации сигналов. Все 24 канала мультиплексируются на общий коаксиальный кабель, предварительно производится PCM-преобразование сигналов. 24 канала по 8 бит (при 8-битном АЦП) дает 192 бита на кадр. Один дополнительный (193-ий) бит используется для целей синхронизации (F). Таким образом частота бит в канале Т1 составляет 193*8000=1,554 Мбит/с (это стандарт США, его европейский аналог - Е1 имеет 30 каналов и пропускную способность 2048 кбит/c). Это соответствует частоте кадров 667/с. Каждый восьмой бит (младший) байта (временного домена на Рисунок 2.3.1) используется для целей управления, что несколько снижает пропускную способность. В ISDN каналы 1,544 и 2,048 Мбит/с, форматы которых здесь описаны, называются первичными.

8-битовые pcm-блоки генерируются каждые 125мксек (8000/с). Структура данных при передаче со скоростью 1,544 Мбит/с представлена ниже (isdn 2*B+D):

D Замечания о реализации

D. Замечания о реализации

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

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 Анализбезопасности

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 могут быть больше, чем ключи шифрования, поэтому сообщения могут оставаться устойчивы против повреждений, даже если взломаны ключи шифрования.

Формат блока данных Telnet

Рисунок 4.5.3.1. Формат блока данных Telnet

Первый байт в соответствии с таблицей содержит 8 единиц, далее следует байт команды (табл. 4.5.3.4). Третий октет служит для размещения кода опции, он может и отсутствовать.

Рассмотрим несколько примеров этих команд. Допустим, вы хотите, чтобы обмен данными производился в виде 8-битовых посылок. Для реализации вашего пожелания достаточно выдать команду:

IAC WILL TRANSMIT-BINARY,

которая в цифровых кодах выглядит как - (255 251 0).

Для прекращения этого (двоичного) режима передачи нужно выдать команду:

IAC DON'T TRANSMIT-BINARY (255 254 0).

Субкоманды Telnet позволяют управлять откликом при работе с клавиатурой. Обычно отклик-эхо присылается удаленной ЭВМ, реже формируется локально. Для включения отклика можно выдать команду: IAC WILL ECHO (255 251 1) (часто это реализовано по умолчанию). Далее можете поупражняться самостоятельно и проверить какие команды и их опции доступны в используемом вами программном продукте.

При работе с Telnet рекомендуется сначала ознакомиться с конкретными возможностями команды с помощью описания (или F10/?). Это позволит вам, например, спасать результаты поиска в файле с указанным вами именем и т.д. Например, для PCTCP такая команда выдаст на экран:

Telnet with VT220 and 3270 emulation, escape character is alt-F10 or F10

?	display this help message	a	sends Telnet AYT request
^h	debugging command help	b	send Telnet Interrupt Process
o	write receive data to output file	z	send Telnet Abort output
i	read keystrokes from an input file	t	send Telnet Break
c	close connection gracefully	!	escape to command interpret
q/Q	quit current/all telnet connections	I	show local internet address
F	toggle build-in FTP-server on/off	U	turn status line on
W	toggle FTP server write-protect mode	u	turn status line off
0-9	switch to connection #	s	Enable pop-up TSR with hot-key
p	Select code page remapping	S	Toggle screen-saver key-passing

-------------------------- VT220 emulator commands ------------------------------

R	Enter key send CR	l	local echo mode
N	Enter key send newline (CRLF)	r	remote echo mode
E	send characters as typed	w	turn end-of-line wrap on
E	send line when ENTER is typed	d	turn end-of-line wrap off
B			set emulator mode (VT52\|100\|220)
D

---------------------------- 3270 emulator commands ----------------------------

set Yale Null Processing off

set Yale Null Processing on

[Press SPACE to return to session, or enter another command (? for Help]

Многие telnet-клиенты позволяют также указывать явно номер порта, через который должна быть установлена связь. По умолчанию это порт 23. Обычный пользователь не интересуется, через какой порт он работает. Но иногда желательно реализовывать telnet через разные порты системы, обеспечивающие различные услуги, это бывает полезно и с отладочными целями. Используя команду:

telnet XXXXXX.domain

можно осуществить связь через порт с заданным номером с узлом XXXXXX.domain. Многие библиотеки используют метод портов для обеспечения доступа к своим ресурсам внешних Inernet-пользователей. Ссылки на RFC-документы по протоколу TELNET смотрите в приложении. Помимо telnet существуют и другие стандартные процедуры, выполняющие схожие задачи.

SUN Microsistems разработала и широко использует программный модуль RPC (Remote Procedure Call, RFC-1057), он используется для удаленного вызова программ почти во всех системах, базирующихся на UNIX. RPC может использоваться как на TCP, так и UDP транспортных уровнях.

Для удаленного исполнения программ может служить команда REXECD, которая активно используется на IBM-системах в рамках ОС AIX и DOS. Уязвимость протокола Telnet для хакеров привела к тому, что в последнее время эта утилита часто заменяется SSH

(Secure Shell) или другими программами, обеспечивающими безопасный удаленный доступ.

Формат опций для TCP-сегментов

Рисунок 4.4.3.2. Формат опций для TCP-сегментов

Поле данные в TCP-сегменте может и отсутствовать, характер и формат передаваемой информации задается исключительно прикладной программой, максимальный размер этого поля составляет в отсутствии опций 65495 байт. TCP является протоколом, который ориентируется на согласованную работу ЭВМ и программного обеспечения партнеров, участвующих в обмене информацией. Установление связи клиент-сервер осуществляется в три этапа:

Клиент посылает SYN-сегмент с указанием номера порта сервера, который предлагается использовать для организации канала связи (active open).

Сервер откликается, посылая свой SYN-сегмент, содержащий идентификатор (ISN - initial sequence number). Начальное значение isn не равно нулю. Процедура называется passive open.

Клиент отправляет подтверждение получения syn-сегмента от сервера с идентификатором равным ISN (сервера)+1.

Стандартная процедура установления связи представлена на рисунке 4.4.3.3 (под словом “стандартная” подразумевается отсутствие каких-либо отклонений от штатного режима, например, одновременного открывание соединения со стороны сервера и клиента). Если же соединение одновременно инициируется клиентом и сервером, в конечном итоге будет создан только один виртуальный канал.

Формат TCP-сегмента

Рисунок 4.4.3.1 Формат TCP-сегмента

Поле опции зарезервировано на будущее и в заголовке может отсутствовать, его размер переменен и дополняется до кратного 32-бит с помощью поля заполнитель. Формат поля опции представлен на Рисунок 4.4.3.2. В настоящее время определены опции:

0 Конец списка опций.

1 Никаких операций. Используется для заполнения поля опции до числа октетов, кратного 4.

2 Максимальный размер сегмента (MSS).

В поле вид записывается код опции, поле LEN содержит число октетов в описании опции, включая поля вид и LEN. Определены также опции со значением вид=4,5,6,7. В предложении T/TCP (RFC-1644) описаны опции 11, 12 и 13.

Форматы TFTP-сообщений

Рисунок 68. Форматы TFTP-сообщений

Операции запросов (RRQ и WRQ) требуют присылки пакета-отклика (ACK). Сначала устанавливается связь между клиентом и сервером, для этого посылаются запросы read или write. При этом сообщается имя файла и режим доступа (Mode). Предусмотрено три режима доступа, которые определяются значением поля MODE: NetASCII (американский стандарт для информационных обменов), побайтный (режим binary) и почтовый (данные поступают пользователю, а не заносятся в файл, при этом используется система кодов NetASCII). Предусмотрено шесть типов сообщений об ошибках:

0 - не определен;

1 - файл не найден;

2 - ошибка доступа;

3 - переполнение диска или превышение выделенной квоты;

4 - нелегальная TFTP-операция;

5 - неизвестный идентификатор обмена.

Если запросы read или write успешно выполнены, сервер использует IP-адрес и номер UDP-порта клиента для идентификации последующих операций. Таким образом, ни при пересылке данных, ни при передаче подтверждений (ACK) не нужно указывать явно имя файла. Блоки данных нумеруются, начиная с 1, подтверждение получения пакета имеет тот же номер. Получение блока с размером менее 512 байт означает конец файла. Получение сигнала об ошибке прерывает обмен. При возникновении тайм-аута производится повторная передача последнего блока данных или подтверждения. При задержке отклика, превышающей значение тайм-аута, возможно удвоение всех последующих блоков. Это происходит в некоторых реализациях программного обеспечения оттого, что из-за тайм-аута происходит повторная пересылка блока, а запоздавший отклик на блок i вызовет посылку блока i+1. Это будет продолжаться вплоть до конца пересылки файла. TFTP-протокол используется также и при реализации электронной почты (посылка файлов почтовой программе).

Отсутствие авторизации делает доступность TFTP одной из угроз безопасности. Именно по этой причине во многих инструкциях вы можете найти рекомендацию запретить применение этой утилиты.

G Патентное заявление

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/

HMAC и псевдослучайные функции

5. HMAC и псевдослучайные функции

Ряд операций на уровне записей и диалога требуют ключевого MAC; это дайджест определенных данных, защищенных секретным кодом. Фальсификация MAC невозможна без знания секретного кода. Конструкция, которая используется для этой операции, имеет название HMAC и описана в [HMAC].

HMAC может использоваться с разными хэш-алгоритмами. TLS использует ее при диалоге с другими алгоритмами: MD5 и SHA-1, обозначая их как HMAC_MD5(secret, data) и HMAC_SHA(secret, data). Для других шифровых наборов и защищенных данных могут быть определены дополнительные хэш-алгоритмы, но в данной версии протокола для целей диалога жестко заданы MD5 и SHA-1.

Кроме того, необходима схема расширения применения секретных кодов (secret) на блоки данных с целью генерации ключей и валидации. Такая псевдослучайная функция (PRF) использует в качестве входной информации секретный код, порождающий код (seed) и идентификационную метку (label). При этом формируется выходной массив произвольной длины.

Для того чтобы сделать PRF максимально секретной, она использует два хэш-алгоритма так, чтобы гарантировать секретность при сохранении работоспособности хотя бы одного из них.

Сначала, определена функция разложения данных, P_hash(secret, data), которая использует одну хэш функция для распространения секретного кода на произвольное число выходов:

P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +

	HMAC_hash(secret, A(2) + seed) +
	HMAC_hash(secret, A(3) + seed) + ...

где + обозначает объединение.

A() определено как:

	A(0) = seed
	A(i) = HMAC_hash(secret, A(i-1))

Для требуемого качества данных P_hash может итерироваться столько раз, сколько нужно. Например: если P_SHA-1 использовался для формирования 64 байт данных, его следует итерировать четыре раза (до A(4)), создавая 80 байт выходных данных; последние 16 байт последней итерации будут отброшены, оставляя 64 байта.

PRF TLS создана путем расщепления секретного кода на две части и использования одной половины для генерации данных с помощью P_MD5, а другой половины - для формирования данных посредством P_SHA-1, выходные данных этих двух процедур объединяются затем с помощью операции исключающего ИЛИ.

S1 и S2 являются двумя равными по длине половинами секретного кода. Их длина определяется путем округления результата деления исходного секретного кода на два. Таким образом, если исходный секретный код имеет длину в байтах, характеризуемую нечетным числом, то последний байт S1 будет тем же, что и первый байт S2.

L_S = длина секретного кода в байтах;

L_S1 = L_S2 = ceil(L_S / 2);

PRF определяется как результат смешения двух псевдослучайных потоков с помощью операции исключающее ИЛИ.

PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);

Метка представляет собой ASCII-строку. Она должна быть включена в исходном виде без байта длины или завершающего нуля. Например: метка "slithy toves" будет представлена в виде:

73 6C 69 74 68 79 20 74 6F 76 65 73

Заметим, что, так как MD5 выдает на выход 16 байт, а SHA-1 - 20 байт, границы их внутренних итераций не будут выровнены; чтобы сформировать на выходе 80 байт P_MD5 осуществит итерации до A(5), в то время как P_SHA-1 - до A(4).

Имена временных зон

10.22 Имена временных зон

Временная зона	Сокращение
Универсальное время (Universal Time, тоже, что и GMT)	UT
Время по Гринвичу (Greenwich Mean Time)	GMT
Восточное стандартное время (Eastern Standard Time)	EST
Центральное стандартное время (Central Standard Time)	CST
Центральное дневное время (Central Daylight Time)	CDT
Mountain Standard Time	MST
Mountain Daylight Time	MDT
Pacific Standard Time	PST
Pacific Daylight Time	PDT

IP-туннели

4.4.1.2 IP-туннели

Особенность IP-протокола (опция принудительной маршрутизации) позволяет переадресовывать IP-дейтограммы определенным узлам сети. На первый взгляд эта возможность может показаться совершенно бесполезной, ведь существуют механизмы динамической маршрутизации, которые несравненно эффективнее и надежней обеспечивают обмен данными. Но тем не менее существуют приложения, где принудительная маршрутизация на IP-уровне представляет возможности недоступные для традиционных решений. Это прежде всего сети, работающие с использованием протоколов IPX/SPX (Novell), где традиционная маршрутизация не предусмотрена. Для подключений удаленных серверов, находящихся вне локальной сети, здесь используется технология так называемых IP-туннелей. При реализации этой технологии IPX-пакеты инкапсулируются в IP-дейтограммы и доставляются в соответствие с протоколами TCP/IP. Процедура инкапсуляции осуществляется специальным драйвером (IPtunnel; использует протокол IPxodi), который работает так, как если бы он был драйвером аппаратного сетевого интерфейса. При этом необходимо модифицировать конфигурационный файл net.cfg (См., например, www2.ncsu.edu/cc-consult/usinglwp/tunnel.html ).

;Техника IP-туннелей может оказаться иногда полезной и при администрировании маршрутизации, так как метрика внешних протоколов маршрутизации может не учитывать пропускную способность каналов и некоторые другие факторы, например, QoS. В этом случае IP-дейтограммы вкладываются в IP-дейтограммы отправителем (начало туннеля) и извлекаются оттуда в конце туннеля. Конец туннеля не обязательно совпадает с местом назначения пакетов. Такая простая схема туннелирования может порождать некоторые проблемы (см. Рисунок 4.4.1.2.1).

Эквилизация с помощью решающей обратной связи

Рисунок 2.1.4. Эквилизация с помощью решающей обратной связи

На практике линейное выравнивание и эквилизация с обратной связью совмещаются друг с другом и со специальными методами формирования передаваемых сигналов. Проблема усугубляется тем, что одна и та же линия используется для передачи данных в обоих направлениях одновременно.

Для улучшения отношения сигнал/шум следует поднимать амплитуду передаваемого по линии сигнала. Выбранное значение определяется требованиями перекрестных наводок и возможностями существующих БИС. В результате компромисса выбрана амплитуда 2.5 В на нагрузке 135 ом. Любые нелинейные искажения должны быть менее 36 дБ по отношению к основному сигналу. Учитывая динамический диапазон сигналов в линиях связи, отношение сигнал шум предполагается равным 20 дБ, что соответствует ограничению 6дБ на число ошибок 1/106 для гауссова распределения шума. При аналого-цифровом преобразовании одному биту соответствует 6 дБ.

Обычно двухпроводная линия (тем более 4-х проводная) используется для одновременного двухстороннего обмена (full duplex). Эта задача может быть решена схемотехнически мультиплексированием по времени (TDD - Time Division Duplex) или частоте (FDD - Frequency Division Duplex). TDD довольно легко реализовать, этот метод не требует сложных фильтров и эквилайзеров. Метод TDD привлекателен при малых длинах кабеля для коммутируемых телефонных сетей.

Эволюция ширины окна при медленном старте

Рисунок 4.4.3.6. Эволюция ширины окна при медленном старте

Здесь предполагается, что MSS=1 Кбайт. Началу диаграммы соответствует установка значения ssthresh=16 Kбайт. Данная схема позволяет более точно выбрать значение cwnd. После таймаута, который на рисунке произошел при передаче c номером 12, значение порога понижается до 12 Кбайт (=cwnd/2). Ширина окна cwnd снова начинает расти от передачи к передаче, начиная с одного сегмента, вплоть до нового значения порога ssthresh=12 Кбайт. Стратегия с экспоненциальным и линейным участками изменения ширины окна переполнения позволяет несколько приблизить среднее его значение к оптимальному. Для локальных сетей, где значение RTT невелико, а вероятность потери пакета мала, оптимизация задания cwnd не так существенна, как в случае протяженных внешних (например, спутниковых) каналов. Ситуация может поменяться, если в локальной сети имеется фрагмент, где вероятность потерь пакетов велика. Таким фрагментом может быть МАС-бридж (или переключатель), один из каналов которого подключен к сегменту Fast Ethernet, а другой к обычному Ethernet на 10 Мбит/c. Если такой мост не снабжен системой подавления перегрузки (до сих пор такие приборы не имели подобных систем), то каждый из пакетов будет потерян в среднем 9 раз, прежде чем будет передан (здесь предполагается, что передача идет из сегмента FE). При этом cwnd будет практически все время равно MSS, что крайне неэффективно при передаче по каналам Интернет. Такие потери вызовут определенные ошибки при вычислении среднего значения и дисперсии RTT, а как следствие и величин таймаутов. Применение в таких местах маршрутизаторов или других приборов, способных реагировать на перегрузку посредством ICMP(4), решает эту проблему.

Для взаимного согласования операций в рамках TCP-протокола используется четыре таймера:

Таймер повторных передач (retransmission; RTO) контролирует время прихода подтверждений (ACK). Таймер запускается в момент посылки сегмента. При получении отклика ACK до истечения времени таймера, он сбраcывается. Если же время таймера истекает до прихода ACK, сегмент посылается адресату повторно, а таймер перезапускается.

Таймер запросов (persist timer), контролирующий размер окна даже в случае, когда приемное окно закрыто. При window=0 получатель при изменении ситуации посылает сегмент с ненулевым значением ширины окна, что позволит отправителю возобновить свою работу. Но если этот пакет будет потерян, возникнет тупик, тогда каждая из сторон ждет сигнала от партнера. Именно в этой ситуации и используется таймер запросов. По истечении времени этого таймера отправитель пошлет сегмент адресату. Отклик на этот сегмент будет содержать новое значение ширины окна. Таймер запускается каждый раз, когда получен сегмент с window=0.

Таймер контроля работоспособности (keepalive), который регистрирует факты выхода из строя или перезагрузки ЭВМ-партнеров. Время по умолчанию равно 2 часам. Keepalive-таймер не является частью TCP-спецификации. Таймер полезен для выявления состояний сервера half-open при условии, что клиент отключился (например, пользователь выключил свою персональную ЭВМ, не выполнив LOGOUT). По истечении времени таймера клиенту посылается сегмент проверки состояния. Если в течение 75 секунд будет получен отклик, сервер повторяет запрос 10 раз с периодом 75 сек, после чего соединение разрывается. При получении любого сегмента от клиента таймер сбрасывается и запускается вновь.

2MSL-таймер (Maximum Segment Lifetime) контролирует время пребывания канала в состоянии TIME_WAIT. Выдержка таймера по умолчанию равно 2 мин (FIN_WAIT-таймер). См. Рисунок 4.4.3.4. и RFC-793. Таймер запускается при выполнении процедуры active close в момент посылки последнего ACK.

Важным параметром, определяющим рабочие параметры таймеров, является RTT (время путешествия пакета до адресата и обратно). TCP-агент самостоятельно измеряет RTT. Такие измерения производятся периодически и по их результатам корректируется среднее значение RTT:

RTTm = a*RTTm + (1-a)*RTTi,

где RTTi - результат очередного измерения, RTTm - величина, полученная в результате усреднения предыдущих измерений, а - коэффициент сглаживания, обычно равный 0.9. RFC-793 рекомендует устанавливать время таймаута для ретрансмиссии (повторной передачи), значение RTO - Retransmission TimeOut равно RTO=RTTm*b, где b равно 2. От корректного выбора этих параметров зависит эффективная работа каналов. Так занижение времени ретрансмиссии приводит к неоправданным повторным посылкам сегментов, перегружая каналы связи. Для более точного выбора RTO необходимо знать дисперсию RTT. Несколько более корректную оценку RTO можно получить из следующих соотношений:

RTTm = RTTm + g(RTTi-RTTm)

D = D + d(|RTTi - RTTm| - D)

RTO = RTTm + 4D,

где D - среднее отклонение RTT от равновесного значения, а коэффициенты g = 0,125, D = 0,25. Чем больше g, тем быстрее растет RTO по отношению к RTT. Это хорошо работает до тех пор, пока не произойдет таймаут и ретрансмиссия. В этом случае, получив ACK, трудно решить, какому сегменту соответствует это подтверждение, первому или второму. На эту проблему впервые обратил внимание Фил Карн. Решением проблемы является приостановка коррекции RTTm при таймауте и ретрансмиссиях. Значение RTO зависит от пропускной способности канала и от специфических задержек, например в случае спутниковых каналов. В основном RTO лежит в секундном диапазоне (5-15 сек). Наиболее вероятная причина потери пакетов - это перегрузка канала на участках между отправителем и приемником. Указанием на то, что пакет потерян, может служить таймаут или получение дубликата сегмента ACK. Если произошел таймаут, система переходит в режим "медленного старта" (ширина окна перегрузки делается равной 1 сегменту, а значение порога медленного старта - ssthresh делается равным двум сегментам). При инициализации канала переменная ssthresh обычно равна 65535. Дублирование ACK индицирует потерю пакета до наступления таймаута. В этом случае сначала меняется алгоритм приращения величины окна перегрузки cwnd (замедляется темп его роста). После прихода очередного ACK новое значение cwnd вычисляется по формуле:

cwndi+1 = cwndi + (размер_сегмента*размер_сегмента)/cwndi + размер_сегмента/8

Если же в этот момент величина окна перегрузки меньше или равна некоторому порогу (ssthresh - slow start threshold, обычно измеряется в байтах), осуществляется "медленный старт". Следует помнить, что TCP требует посылки немедленного подтверждения (дублированного ACK) при обнаружении прихода сегментов с нарушением порядка следования. Причиной нарушения порядка следования может быть флуктуация задержки в сети или потеря пакета. Если получено три или более задублированных ACK, это является убедительным указанием на потерю пакета и, не дожидаясь таймаута, осуществляется его повторная передача. Перехода в режим медленного старта в этом случае не производится, но понижаются значения cwnd и ssthresh (почти вдвое).

Когда TCP-канал закрывается и за время сессии переслано более 16 полых окон, а адресат достижим не через маршрут по умолчанию, то в таблицу маршрутизации заносится следующая информация: усредненное значение RTT, значение дисперсии RTT и ssthresh.

Если в ходе TCP-сессии получено сообщение ICMP(4) (переполнение канала - quench), требующее снижения потока данных, то cwdn делается равным одному сегменту, а величина порога медленного старта ssthresh не изменяется. На ICMP-сообщения о недостижимости сети или ЭВМ программы TCP-уровня не реагируют вообще.

Нулевой размер окна блокирует посылку информации и этим система время от времени пользуется. Что произойдет, если получатель послал сегмент, объявляющий окно ненулевым, а подтверждение получения этого сегмента не прошло? TCP-протокол не предусматривает посылки ACK на само подтверждение. Адресат ждет в этом случае данных, так как он уже объявил о существовании ненулевого окна с помощью соответствующего ACK, а отправитель ждет этого недошедшего ACK, чтобы начать передачу данных. Для разрешения этой тупиковой ситуации используется таймер запросов, который периодически посылает зондирующие сегменты получателю. Цель этого зондирования - выяснение существования окна ненулевой ширины. Таймер запросов запускается при получении информации об обнулении ширины окна приемником. Если за определенное время не поступает сегмента, сообщающего об изменении размера окна, таймер начинает посылать зондирующие сегменты. Таймер запросов использует базовую временную шкалу с периодом в 500 мсек, а период посылки зондирующих сегментов лежит в диапазоне 5-60 сек. Такой сегмент содержит только один байт данных. Таймер запросов не прерывает своей работы до тех пор, пока не будет подтверждено открытие окна или пока прикладная задача не завершит свою работу, выключив канал связи.

Будучи однажды создан, канал TCP может существовать "вечно". Если клиент и сервер пассивны, они не заметят того, например, что какой-то бульдозер оборвал кабель или спутник связи покоится на дне океана. Чтобы это обнаружить, либо клиент либо сервер должны попытаться послать какую-то информацию. Чтобы информировать систему об этих и подобных им жизненных неурядицах, предусмотрен таймер контроля работоспособности (keepalive). Многим читателям, возможно, приходилось легкомысленно выключать питание своего персонального компьютера, не позаботившись о корректном logout из процедуры telnet или FTP. Если бы не существовало этого таймера, включив ЭВМ, вы бы обнаружили, что "находитесь" в заморском депозитарии, где были вчера. Но таймер контроля работоспособности может и прервать сессию, если какой-то промежуточный маршрутизатор произвел перезагрузку или был вынужден поменять маршрут. Принцип работы таймера работоспособности предельно прост. Если канал пассивен, например, 2 часа, сервер посылает клиенту сегмент-зонд. При этом ЭВМ-клиент может быть в одном из четырех состояний.

Работоспособен и достижим для сервера. Отклик от клиента сбросит таймер работоспособности в ноль (начало отсчета очередных двух часов).

Вышел из строя, выключен или перезагружается. Сервер посылает 10 запросов с интервалом 75 сек. Если отклика нет, канал закрывается и со стороны сервера.

Перезагрузился. Сервер получит отклик типа RESET и канал будет закрыт.

Работоспособен, но не достижим для сервера. Случай тождественен, описанному во втором по порядку пункте.

Временная постоянная таймера keepalive является системной переменной единой для всех пользователей ЭВМ или даже локальной сети.

Расширение пропускной способности и надежности телекоммуникационных каналов делает актуальной совершенствование протоколов. Так как TCP является основным транспортным протоколом, попытки усовершенствовать его предпринимаются, начиная с 1992 года (RFC-1323, Якобсон, Браден и Борман). Целью этих усовершенствований служит повышение эффективности и пропускной способности канала, а также обеспечение безопасности. При этом рассматриваются следующие возможности:

увеличение MTU (максимальный передаваемый блок данных);

расширение окна за пределы 65535 байт;

исключение "трех-сегментного" процесса установления связи и "четырехсегментного" ее прерывания (T/TCP, RFC-1644);

совершенствование механизма измерения RTT. оптимизация отслеживания CWND.

Оптимальный выбор MTU позволяет минимизировать или исключить фрагментацию (и последующую сборку) сегментов. Верхняя граница на MTU налагается значением MSS (максимальный размер сегмента). Разумно находить и запоминать оптимальные значения MTU для каждого конкретного маршрута. Так как в современных системах используются динамические протоколы маршрутизации, поиск оптимального MTU рекомендуется повторять каждые 10 мин (RFC-1191).

Как уже отмечалось, размер TCP-окна определяется произведением полосы канала (в бит/с) на RTT в сек. Для Ethernet c полосой 10 Мбит/с и RTT=3 мсек это произведение равно 3750 байт, а для канала ИТЭФ-ДЕЗИ с пропускной способностью 1,5 Мбит/с и RTT=710 мсек (спутник) - 88750 байт, а это отнюдь не предел современной телекоммуникационной технологии. Но уже эти примеры говорят о том, что максимально возможный размер окна должен быть увеличен в раз 10-100 уже сегодня. Протокол же разрешает 65535 байт. Появление столь мощных каналов порождает и другие проблемы - потеря пакетов в них обходится слишком дорого, так как "медленный старт" и другие связанные с этим издержки сильно снижают пропускную способность. В последнее время алгоритм медленного старта заменяется более эффективными алгоритмами.

Простое увеличение ширины окна до тех пор, пока не произойдет сбой, плохая стратегия при использовании традиционного медленного старта, так как заметную часть времени ширина окна будет неоптимальной – то слишком большой, то слишком малой. Оптимальная стратегия должна включать в себя прогнозирование оптимальной ширины окна. В новых версиях модулей TCP реализуются именно такие алгоритмы. В 1994 году Бракмо предложил вариант стратегии изменения параметров передачи, который на 40-70% повышает пропускную способность TCP-канала.

Существуют и другие, могущие показаться забавными проблемы. Каждый сегмент в TCP-протоколе снабжается 32-битным идентификатором. Время жизни IP-пакета (TTL) определяется по максимуму 255 шагами или 255 секундами в зависимости оттого, что раньше наступит. Трудно предсказуемая ситуация может произойти, когда канал ликвидирован, затем создан снова (для той же комбинации IP-адресов и портов), а какой-то пакет из предшествующей сессии, погуляв по Интернет, придет уже во время следующей. Есть ли гарантия, что он будет верно идентифицирован? Одной из мер, упомянутых ранее, можно считать использование ограничения по максимальному времени жизни сегмента (MSL) или TTL, хотя снижение значения TTL не всегда возможно - ведь IP-пакетами пользуется не только TCP-протокол и нужна очень гибкая система задания его величины. Во многих приложениях MSL=30 сек (рекомендуемое значение 2 мин слишком велико). Технический прогресс ставит и некоторые новые проблемы. Высокопроизводительные каналы (1 Гбит/с) уже сегодня могут исчерпать разнообразие идентификационных кодов пакетов за один сеанс связи. Появление же двух пакетов с равными идентификаторами может породить неразрешимые трудности. Для передачи мегабайтного файла по гигабитному каналу требуется около 40 мсек (при этом предполагается, что задержка в канале составляет 32 мсек (RTT=64 мсек)). Собственно передача этой информации занимает 8 мсек. Из этих цифр видно, что традиционные протоколы, размеры окон и пр. могут свести на нет преимущества скоростного (дорогостоящего) канала. Пропускная способность такого канала определяется уже не его полосой, а задержкой. Понятно также, что необходимо расширить поле размера окна с 16 до 32 бит. Чтобы не изменять формат TCP-сегментов, можно сделать код размера окна в программе 32-разрядным, сохранив соответствующее поле в сегменте неизменным. Размер окна в этом случае задается как бы в формате с плавающей запятой. При установлении канала определяется масштабный коэффициент n (порядок) лежащий в интервале 0-14. Передача этого коэффициента (один байт) осуществляется сегментом SYN в поле опций. В результате размер окна оказывается равным 65535*2n. Если один из партнеров послал ненулевой масштабный коэффициент, но не получил такого коэффициента от своего партнера по каналу, то n считается равным нулю. Эта схема позволит сосуществовать старым и новым системам. Выбор n возлагается на TCP-модуль системы.

Для того чтобы точнее отслеживать вариации RTT, предлагается помещать временные метки в каждый посылаемый сегмент. Так как в TCP используется одно подтверждение ACK на несколько сегментов, правильнее будет сказать, что RTT измеряется при посылке каждого ACK. Способность и готовность партнеров работать в таком режиме временных меток определяется на фазе установления канала. Более точное вычисление RTT позволяет не только корректно выбрать временные постоянные для таймеров, правильно вычислить задержку TIME_WAIT (TIME_WAIT=8*RTO), но и отфильтровать "старые" сегменты. Идеология временных меток используется и в алгоритме PAWS (Protection Against Wrapped Sequence Numbers) для защиты против перепутывания номеров сегментов.

Предлагаемое усовершенствование TCP - T/TCP модифицирует алгоритмы выполнения операций. T/TCP вводит новую 32-битную системную переменную - число соединений (CC). СС позволяет сократить число пересылаемых сегментов при установлении канала, а также отфильтровывать "старые" сегменты, не принадлежащие данной сессии (установленной связи). Время отклика клиента в рамках указанных алгоритмов сокращается до суммы RTT и времени обработки запроса процессором. Данные пришедшие до SYN-сегмента должны буферизоваться для последующей обработки, а не отбрасываться.

Ethernet (10 Мбит/c) в идеальных условиях позволяет осуществить обмен в рамках протокола TCP (например, при FTP-сессии) со скоростью 1,18 Мбайт/с.

Как уже отмечалось, максимальная длина сегмента (MSS - Maximum Segment Size) в TCP-обменах величина переменная. Длина сегмента определяет длину кадра, в который он вложен. Для локальных Ethernet-сетей MSS=1460 октетов. Чем длиннее кадр, тем выше пропускная способность сети (меньше накладные расходы на заголовок кадра). С другой стороны, при передаче дейтограмм по внешним каналам, где размер пакета не столь велик, большое значение MSS приведет к фрагментации пакетов, которая замедлит обмен, поэтому администратор сети должен взвешивать последствия, задавая значения размера сегментов. Если MSS явно не задан, устанавливается значение по умолчанию (536 байт), что соответствует 576-байтной IP-дейтограмме. Для нелокальных адресов - это, как правило, разумный выбор.

Ликвидация связи требует посылки четырех сегментов. TCP-протокол допускает возможность, когда один из концов канала объявляет о прекращении посылки данных (посылает FIN-сегмент), продолжая их получать (режим частичного закрытия - half-close). Посылка сегмента FIN означает выполнение операции active close. Получатель FIN-сегмента должен послать подтверждение его получения. Когда противоположный конец, получивший FIN, закончит пересылку данных, он пошлет свой FIN-сегмент. Прием подтверждения на получение этого сегмента означает закрытие данного канала связи. Возможно прерывание связи и с помощью посылки RST-сегмента. В этом случае все буферы и очереди очищаются немедленно и часть информации будет потеряна.

Криптографические вычисления

8. Криптографические вычисления

Для того чтобы начать защиту соединения, протоколу записей TLS необходима спецификация набора алгоритмов, мастерный секретный код и случайные коды клиента и сервера. Алгоритмы аутентификации, шифрования и MAC определяются cipher_suite, выбранным сервером и указанным в сообщении server hello. Алгоритм сжатия согласуется в сообщениях hello, а случайные коды пересылаются в сообщениях hello. Все что остается - это вычислить мастерный секретный код.

8.1. Вычисление мастерного секретного кода

Для всех методов ключевого обмена используется один и тот же алгоритм преобразования pre_master_secret в master_secret. Значение pre_master_secret следует стереть из памяти, как только завершится вычисление master_secret.

master_secret = PRF(pre_master_secret, "master secret",

ClientHello.random + ServerHello.random) [0..47];

Мастерный секретный код всегда имеет длину 48 байт. Длина предмастерного секретного кода варьируется в зависимости от метода ключевого обмена.

8.1.1. RSA

Когда для аутентификации сервера и ключевого обмена используется RSA, 48- байтовый pre_master_secret генерируется клиентом, шифруется с помощью общедоступного ключа сервера и посылается серверу. Сервер использует свой секретный ключ для дешифрования pre_master_secret. Оба партнера преобразуют затем pre_master_secret в master_secret, как это специфицировано выше.

Цифровые подписи RSA реализуются с помощью PKCS #1 [PKCS1] с типом блока 1. Шифрование RSA с использованием общедоступного ключа выполняется с помощью PKCS #1 с типом блока 2.

8.1.2. Diffie-Hellman

Выполняются обычные вычисления по алгоритму Diffie-Hellman. В качестве pre_master_secret используется согласованный ключ (Z), преобразование его в master_secret, описано выше.

Параметры Diffie-Hellman специфицируются сервером и могут быть одноразовыми или взятыми из сертификата сервера.

В отсутствии стандарта на прикладной профайл приложение TLS должно использовать шифровой набор TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

Сообщения прикладных данных вырабатываются уровнем записей, фрагментируются, сжимаются и шифруются на основе параметров состояния соединения. Сообщения рассматриваются как прозрачные данные уровня записей.

Линейное выравнивание (эквилизация)

Рисунок 2.1.3. Линейное выравнивание (эквилизация)

Машина состояний для протокола

Рисунок 4.4.3.4. Машина состояний для протокола tcp (W.R. Stivens, TCP/IP Illustrated. V1. Addison-Wesley publishing company. 1993.)

Когда оператор, работая в диалоговом режиме, нажимает командную клавишу, сегмент, в который помещается эта управляющая последовательность, помечается флагом PSH (push). Это говорит приемнику, что информация из этого сегмента должна быть передана прикладному процессу как можно скорее, не дожидаясь прихода еще какой-либо информации. Сходную функцию выполняет флаг URG. URG позволяет выделить целый массив данных, так как активизирует указатель последнего байта важной информации. Будет ли какая-либо реакция на эту "важную" информацию определяет прикладная программа получателя. urg-режим используется для прерываний при работе с FTP, telnet или rlogin. Если до завершения обработки "важной" информации придет еще один сегмент с флагом URG, значение старого указателя конца "важного" сообщения будет утеряно. Это обстоятельство должно учитываться прикладными процессами. Так telnet в командных последовательностях всегда помещает префиксный байт с кодом 255.

В режиме удаленного терминала (telnet) при нажатии любой клавиши формируется и поcылается 41-октетный сегмент (здесь не учитываются издержки ethernet), который содержит всего один байт полезной информации. Эффективность работы может быть улучшена с помощью алгоритма Нагля (Nagle, 1984; RFC-896). Нагль предложил при однобайтовом обмене посылать первый байт, а последующие буферизовать до прихода подтверждения получения посланного. После этого посылаются все буферизованные октеты, а запись в буфер вводимых кодов возобновляется. Если оператор вводит символы быстро, а сеть работает медленно, этот алгоритм позволяет заметно понизить загрузку канала. Встречаются, впрочем, случаи, когда алгоритм Нагля желательно отключить, например, при работе в Интернет в режиме Х-терминала, где сигналы перемещения мышки должны пересылаться немедленно, чтобы не ввести в заблуждение пользователя относительно истинного положения маркера.

Существует еще одна проблема при пересылке данных по каналам TCP, которая называется синдром узкого окна (silly window syndrome; Clark, 1982). Такого рода проблема возникает в том случае, когда данные поступают отправителю крупными блоками, а интерактивное приложение адресата считывает информацию побайтно. Предположим, что в исходный момент времени буфер адресата полон и передающая сторона знает об этом (window=0). Интерактивное приложение считывает очередной октет из TCP-потока, при этом TCP-агент адресата поcылает уведомление отправителю, разрешающее ему послать один байт. Этот байт будет послан и снова заполнит до краев буфер получателя, что вызовет отправку ACK со значением window=0. Этот процесс может продолжаться сколь угодно долго, понижая коэффициент использования канала ниже паровозного уровня.

Кларк предложил не посылать уведомление о ненулевом значении ширины окна при считывании одного байта, а лишь после освобождения достаточно большого пространства в буфере. Например, когда адресат готов принять MSS байтов или когда буфер наполовину пуст.

Предполагается, что получатель пакета практически всегда посылает отправителю пакет-отклик. Отправитель может послать очередной пакет, не дожидаясь получения подтверждения для предшествующего. Таким образом, может быть послано k пакетов, прежде чем будет получен отклик на первый пакет (протокол "скользящего окна"). В протоколе tcp "скользящее окно" используется для регулировки трафика и препятствия переполнения буферов. Идея скользящего окна отображена на Рисунок 4.4.3.5. Здесь предполагается, что ширина окна равна 7 (k=7; это число может меняться в очень широких пределах).

Минимальное отношение сигнал-шум

Рисунок 2.1.8. Минимальное отношение сигнал-шум при скорости передачи ~150кбит/с

На Рисунок 2.1.8 показана зависимость отношения сигнал-шум от сопротивления петли для разных схем передающего канала. Пунктиром проведены зависимости для случая четырехуровневого кодирования. Кривые 1 соответствует случаю амплитудной модуляции с линейным выравниванием, а кривые 2 - варианту эквилизации с обратной связью.

Обмен сообщениями для упрощенного диалога

Рисунок .2. Обмен сообщениями для упрощенного диалога

7.4. Протокол диалога

Протокол диалога TLS представляет собой один из фиксированных клиентов высокого уровня протокола записей TLS. Этот протокол используется для согласования атрибутов безопасности сессии. Сообщения диалога передаются уровню записей TLS, где они инкапсулируются в одну или более структур TLSPlaintext, которые обрабатываются и передаются так, как это специфицировано текущим состоянием активной сессии.

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)

} HandshakeType;

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;

Сообщения протокола диалога представлены ниже в порядке, в котором они должны быть посланы. Посылка сообщений диалога в неправильном порядке приведет к фатальной ошибке. Ненужные сообщения диалога могут быть опущены. Обратите внимание на одно исключение: сообщение сертификата используется в диалоге дважды (от клиента к серверу, а затем от сервера к клиенту), но оно описано лишь для первого случая его использования. Одно сообщение не привязано к этим правилам порядка обмена, это сообщение запроса Hello, которое может быть послано в любое время, но которое должно игнорироваться клиентом, если приходит в середине диалога.

7.4.1. Сообщения Hello

Сообщения фазы hello используются для выяснения возможностей клиента и сервера по повышению безопасности информационного обмена.
Когда начинается новая сессия, состояние шифрования уровня записей, алгоритмы хэширования и сжатия инициализируются нулем. Текущее состояние соединения используется для сообщений согласования параметров.

7.4.1.1. Запрос Hello

Сообщение-запрос hello может быть послано сервером в любое время.

Значение этого сообщения:

Запрос Hello является простым уведомлением о том, что клиент должен начать согласование путем посылки сообщения client hello. Это сообщение будет проигнорировано клиентом, если он участвует в сессии согласования. Это сообщение может игнорироваться клиентом, если он не хочет заново согласовывать параметры сессии, или клиент может, если хочет, реагировать уведомлением no_renegotiation. Так как сообщения диалога предназначены для осуществления определенных действий над прикладными данными, ожидается, что согласование начнется до того, как будут получены новые записи от клиента. Если сервер посылает запрос hello, но не получает отклика client hello, он может разорвать соединение с фатальным уведомлением.

После посылки запроса hello, серверы не должны повторять запрос до тех пор, пока диалог согласования не завершится.

Структура этого сообщения:

struct { } HelloRequest;

Это сообщение не должно никогда включаться в хэши сообщений и использоваться в завершающих сообщениях (finished), а также в сообщении верификации сертификатов.

7.4.1.2. Hello клиента

Когда клиент инициализирует соединение с сервером, первым должно быть послано сообщение client hello. Клиент может также послать client hello в качестве отклика на запрос hello или по своей собственной инициативе, для того чтобы заново согласовать параметры безопасности существующего соединения.

Сообщение hello клиента включает в себя случайную структуру, которая позднее используется протоколом.

struct { uint32 gmt_unix_time; opaque random_bytes[28];} Random;

gmt_unix_time

Текущее время и дата согласно стандарта UNIX в 32-битовом формате (число секунд с момента полуночи 1-го января, 1970, GMT) согласно показаниям внутренних часов отправителя. Часы могут и не быть точно выверены на уровне протокола TLS. Прикладные протоколы могут накладывать дополнительные ограничения.

random_bytes

28 байт сформированных безопасным генератором случайных чисел.

Сообщение client hello включает в себя идентификатор сессии переменной длины. Если это поле не пусто, его значение идентифицирует сессию, чьи параметры безопасности клиент желает использовать повторно. Идентификатор сессии может соответствовать какому-то предшествующему соединению, текущему соединению, или другому активному соединению. Вторая опция полезна, если клиент хочет изменить случайные структуры и получить текущие значения параметров соединения, в то время как третья опция делает возможным установить несколько независимых безопасных соединений без повторения всей процедуры протоколы диалога. Эти независимые соединения могут существовать последовательно или одновременно; SessionID становится действенным, когда диалог согласования завершается обменом сообщениями Finished, и сохраняется до тех пор, пока не состарится или из-за фатальной ошибки в соединении данной сессии. Действительное содержимое SessionID определяется сервером.

opaque SessionID;

Так как SessionID передается без шифрования или MAC-защиты, серверы не должны помещать конфиденциальные данные в идентификаторы сессий, что могло бы привести к возрастанию уязвимости. Заметим, что содержимое диалога в целом, включая SessionID, защищено сообщениями Finished, пересылаемыми в конце диалога.

Список CipherSuite, передаваемый от клиента серверу в сообщении client hello, содержит комбинации криптографических алгоритмов, поддерживаемых клиентом в порядке их предпочтения (предпочтительный вариант - первый). Каждый CipherSuite определяет алгоритм пересылки ключей, алгоритм массового шифрования (включая длину секретного ключа) и алгоритм MAC. Сервер выберет шифровой набор или, если приемлемого варианта нет, пришлет уведомление об ошибке и прервет соединение.

uint8 CipherSuite[2]; /* Cryptographic suite selector */

Hello клиента включает в себя список алгоритмов сжатия, поддерживаемых клиентом, в порядке их предпочтения.

enum { null(0), (255) } CompressionMethod;

struct	{ ProtocolVersion client_version;
	Random random;
	SessionID session_id;
	CipherSuite cipher_suites16-1>;
	CompressionMethod compression_methods8-1>;
	} ClientHello;

client_version	Версия протокола TLS, которой хочет воспользоваться клиент во время сессии. Это должна быть последняя версия (с наибольшим кодом), поддерживаемая клиентом. Для данной спецификации значение версии равно 3.1 (Смотри приложение E об обратной совместимости).
Random	Псевдослучайная структура, генерируемая клиентом.
session_id	ID-сессия, которую клиент хочет использовать для данного соединения. Это поле должно быть пустым, если нет ни одного session_id или клиент хочет выработать новые параметры безопасности.
cipher_suites	Список криптографических опций, поддерживаемых клиентом в порядке предпочтения. Если поле session_id не пусто (запрос восстановления сессии), этот вектор должен включать по крайней мере cipher_suite данной сессии. Значения определены в приложении A.5.
compression_methods	Список методов сжатия, поддерживаемых клиентом в порядке их предпочтения. Если поле session_id не пусто (запрос восстановления сессии) он должен включать compression_method данной сессии. Этот вектор должен содержать, а все реализации должны поддерживать CompressionMethod.null. Таким образом, клиент и сервер всегда могут согласовать метод сжатия информации.

После посылки сообщения client hello, клиент ждет сообщения server hello. Любое другое сообщение диалога, присланное сервером, за исключением запроса hello, рассматривается как фатальная ошибка.

В интересах прямой совместимости, клиенту разрешено включать в сообщение client hello после методов сжатия дополнительные данные. Эти данные должны быть включены в хэши диалога, в противном случае они игнорируются. Это единственное сообщение диалога, для которого это допускается; для всех остальных сообщений, объем данных должен точно соответствовать описанию сообщения.

7.4.1.3. Hello сервера

Сервер посылает это сообщение в ответ на сообщение client hello, когда он может найти приемлемый набор алгоритмов. Если он не может сделать приемлемый выбор, он реагирует уведомлением об ошибке диалога.

Структура этого сообщения:

Struct	{ ProtocolVersion server_version;
	Random random;
	SessionID session_id;
	CipherSuite cipher_suite;
	CompressionMethod compression_method;
	} ServerHello;

server_version	Это поле будет содержать самое низкое значение, которое предлагается клиентом в client hello и наибольшее значение версии, поддерживаемое сервером. Значение версии данной спецификации равно 3.1 (по поводу обратной совместимости смотри Приложение E).
Random	Эта структура генерируется сервером и должна быть отличной от ClientHello.random.
session_id	Идентифицирует сессию, соответствующую данному соединению. Если ClientHello.session_id не пусто, сервер будет искать соответствие с содержимым своего кэша сессий. Если соответствие найдено и сервер хочет установить новое соединение, используя специфицированное состояние сессии, он откликнется тем же значением ID, что было прислано клиентом. Это индицирует возобновляемую сессию и диктует, что партнеры должны продолжить обмен сообщениями finished. В противном случае это поле будет содержать другое значение идентифицирующее новую сессию. Сервер может вернуть пустое поле session_id, чтобы индицировать, что сессия не будет кэшироваться и, следовательно, не может быть возобновлена. Если сессия возобновлена, она должна использовать тот же шифровой набор, который был согласован ранее.
cipher_suite	Шифровой набор, выбранный сервером из списка в ClientHello.cipher_suites. Для возобновленных сессий это поле несет в себе значение, взятое из состояния возобновляемой сессии.
compression_method	Алгоритм сжатия, выбранный сервером из списка в ClientHello.compression_methods. Для возобновляемых сессий это поле содержит значение из состояния возобновляемой сессии.

7.4.2. Сертификат сервера

Сервер должен послать сертификат, всякий раз, когда согласованный метод обмена ключами не является анонимным. За этим сообщением всегда непосредственно следует сообщение server hello.

Тип сертификата должен соответствовать выбранному алгоритму обмена ключами шифров, обычно это сертификат X.509v3.

Он должен содержать ключ, который соответствует методу обмена ключами. Если не специфицировано обратного, алгоритм подписи для сертификата должен быть тем же, что и алгоритм для ключа сертификата. Если не специфицировано обратного, общедоступный ключ может иметь любую длину.

Алгоритм обмена ключами	Тип сертификата ключа
RSA	Общедоступный ключ RSA; сертификат должен допускать использование ключа для шифрования.
RSA_EXPORT	Общедоступный ключ RSA с длиной больше чем 512 бит, который может быть использован для подписи, или ключ длиной 512 бит или короче, который может быть использован для шифрования или подписи.
DHE_DSS	Общедоступный ключ DSS.
DHE_DSS_EXPORT	Общедоступный ключ DSS.
DHE_RSA	Общедоступный ключ RSA, который может использоваться для подписи.
DHE_RSA_EXPORT	Общедоступный ключ RSA, который может использоваться для подписи.
DH_DSS	Ключ Diffie-Hellman. Алгоритмом, используемым для подписи сертификата, должен быть DSS.
DH_RSA	Ключ Diffie-Hellman. Алгоритмом, используемым для подписи сертификата, должен быть RSA.

Все сертификатные профайлы, ключи и криптографические форматы определены рабочей группой IETF PKIX [PKIX]. Когда присутствует расширение использования ключа, бит digitalSignature должен быть установлен для ключа выбранного для подписи, как это описано выше, а бит keyEncipherment должен присутствовать, чтобы разрешить шифрование, как это описано выше. Бит keyAgreement должен быть установлен для сертификатов Diffie-Hellman.

Так как CipherSuites, который специфицирует методы нового ключевого обмена, заданы для протокола TLS, они используют формат сертификата и необходимые ключевые данные.

Структура этого сообщения:

opaque ASN.1Cert24-1>;

struct { ASN.1Cert certificate_list24-1>; } Certificate;

certificate_list

Это последовательность (цепочка) сертификатов X.509v3. Сертификат отправителя должен быть записан в списке первым. Каждый следующий сертификат должен непосредственно сертифицировать предшествующий сертификат. Так как верификация сертификата требует, чтобы корневые ключи распределялись независимо, самоподписывающий сертификат, который специфицирует корневой источник сертификата, может быть опционно удален из цепочки, в предположении, что партнер должен уже иметь его, чтобы проверить его в любом случае.

Тот же тип сообщения и структура будут использоваться для отклика клиента на сообщение запроса сертификата. Заметим, что клиент может не посылать сертификата, если он не имеет подходящего, чтобы послать его серверу в ответ на его аутентификационный запрос.

7.4.3. Сообщение ключевого обмена сервера

Это сообщение будет послано немедленно после сообщения сертификата сервера (или сообщения server hello, если это анонимное согласование параметров).

Сообщение ключевого обмена сервера посылается сервером только когда сообщение сертификата сервера (если послано) не содержит достаточно данных, чтобы позволить клиенту осуществлять обмен предмастерными секретными кодами (premaster secret). Это верно для следующих методов обмена ключами:

RSA_EXPORT (если открытый ключ в сертификате длиннее, чем 512 бит)

DHE_DSS

DHE_DSS_EXPORT

DHE_RSA

DHE_RSA_EXPORT

DH_anon

Нелегально посылать сообщение ключевого обмена сервера для следующих методов пересылки ключей:

RSA

RSA_EXPORT (когда открытый ключ в сертификате сервера короче чем или равен 512 бит)

DH_DSS

DH_RSA

Это сообщение передает криптографическую информацию, чтобы позволить клиенту оперировать с premaster секретным кодом: либо общедоступный ключ RSA, чтобы зашифровать предмастерный секретный код, либо общедоступный ключ Diffie-Hellman, с помощью которого клиент может завершить обмен ключами.

В качестве дополнительных определены наборы CipherSuites TLS, которые включают в себя новые алгоритмы обмена ключами. Сервер пошлет сообщение обмена ключами тогда и только тогда, когда тип сертификата, ассоциированный с алгоритмов обмена ключами, не предоставил достаточно информации клиенту, чтобы осуществить пересылку предмастерного секретного кода.

Согласно настоящему закону США об экспорте, модули RSA больше 512 бит не могут использоваться для ключевого обмена в программах, экспортируемых из США. Более длинные ключи RSA, зашифрованные в сертификатах, могут быть использованы для подписи более коротких ключей RSA в случае метода ключевого обмена RSA_EXPORT.

Структура этого сообщения:

enum { rsa, diffie_hellman } KeyExchangeAlgorithm;

struct { opaque rsa_modulus; opaque rsa_exponent;} ServerRSAParams;

rsa_modulus	Модуль временного RSA-ключа сервера.
rsa_exponent	Общедоступный показатель временного RSA-ключа сервера.

struct { opaque dh_p;

opaque dh_g	1>;
opaque dh_Ys	1>;} ServerDHParams; /* Временные DH параметры */

dh_p	Простой модуль, используемый для операции Diffie-Hellman.
dh_g	Генератор, используемый для операции Diffie-Hellman.
dh_Ys	Общедоступное значение (gX mod p) метода Diffie-Hellman для сервера.

struct { select (KeyExchangeAlgorithm) {

	case diffie_hellman:
	ServerDHParams params;
	Signature signed_params;
	case rsa:
	ServerRSAParams params;
	Signature signed_params; };
	} ServerKeyExchange;

Params	Параметры ключевого обмена сервера.
signed_params	Для не анонимных ключевых обменов, хэш соответствующих значений параметров с подписью, согласованной с примененным хэшем.
md5_hash	MD5(ClientHello.random + ServerHello.random + ServerParams);
sha_hash	SHA(ClientHello.random + ServerHello.random + ServerParams);

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;

7.4.4. Запрос сертификата

Не анонимный сервер может опционно запросить сертификат от клиента, если это возможно для выбранного шифрового набора. За этим сообщением, если оно послано, непосредственно следует сообщение ключевого обмена сервера (Server Key Exchange) (в противном случае, сообщение сертификата сервера).

Структура этого сообщения:

enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),

(255)} ClientCertificateType;

opaque DistinguishedName16-1>;

struct { ClientCertificateType certificate_types8-1>;

DistinguishedName certificate_authorities16-1>;

} CertificateRequest;

certificate_types

Это поле представляет собой список типов запрошенных сертификатов, расположенных в порядке предпочтения сервера.

certificate_authorities

Список имен приемлемых провайдеров сертификатов. Эти имена могут специфицировать уникальное имя корневого или подчиненного CA. Таким образом, это сообщение может быть использовано как для описания известных корней и желательного пространства авторизации.

DistinguishedName получается из [X509]. Считается фатальной ошибкой (оповещение handshake_failure), если анонимный сервер запрашивает идентификацию клиента.

7.4.5. Hello done сервера

Сообщение сервера hello done посылается сервером, чтобы индицировать конец hello сервера и связанных с ним сообщений. После отправки этого сообщения сервер ждет отклика клиента.

Это сообщение означает, что сервер завершил подготовку для ключевого обмена, и клиент может приступить к процедуре пересылки ключей.

По получении сообщения сервера hello done клиент должен проверить, что сервер предоставил корректный сертификат, если это требуется, и что параметры, присланные сервером приемлемы.

Структура этого сообщения: struct { } ServerHelloDone;

7.4.6. Сертификат клиента

Это первое сообщение, которое может послать клиент после получения сообщения от сервера hello done. Это сообщение посылается только в случае запроса присылки сертификата со стороны сервера. Если приемлемого сертификата нет, клиент должен послать пустое сообщение сертификата. Если сервером для продолжения диалога требуется аутентификация клиента, он может откликнуться, послав уведомление о фатальной ошибке. Сертификаты клиента посылаются с использованием структуры сертификата, определенной в разделе 7.4.2.

Когда используется метод ключевого обмена, базирующийся на статическом методе Diffie-Hellman (DH_DSS или DH_RSA), если требуется аутентификация клиента, группа Diffie-Hellman и генератор закодированные в сертификате клиента должны соответствовать параметрам Diffie-Hellman'а, специфицированным сервером, если параметры клиента планируется использовать для ключевого обмена.

7.4.7. Сообщение обмена ключами клиента

Это сообщение посылается клиентом всегда. За ним непосредственно следует сообщение сертификата клиента, если оно посылается. В противном случае оно будет первым сообщением, посылаемым клиентом после получения сообщения сервера hello done.

С помощью этого сообщения устанавливается предмастерный секретный код, либо путем прямой передачи его, зашифровав с применением RSA, либо с помощью передачи параметров Diffie-Hellman, которые позволят каждой из сторон согласовать применение одного и того же предмастерного секретного кода. Когда в качестве метода передачи ключей использован DH_RSA или DH_DSS, запрашивается сертификация клиента, и клиент может откликаться посылкой сертификата, который содержит общедоступный ключ Diffie-Hellman, чьи параметры (группа и генератор) соответствуют, специфицированным в сертификате сервера. Это сообщение не содержит никаких других данных.

Структура этого сообщения:

Выбор сообщений зависит от выбранного метода ключевого обмена. Смотри раздел 7.4.3, где дано определение KeyExchangeAlgorithm.

struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret;

case diffie_hellman: ClientDiffieHellmanPublic; } exchange_keys;

} ClientKeyExchange;

7.4.7.1. Сообщение зашифрованного RSA предмастерного секретного кода

Если для согласования ключей и аутентификации применен алгоритм RSA, клиент генерирует 48-байтовый предмастерный секретный код, шифрует его с помощью общедоступного ключа из сертификата сервера или временного RSA-ключа, переданного в сообщении ключевого обмена сервера, и посылает результат в сообщении зашифрованного предмастерного секретного кода (encrypted premaster secret). Эта структура является вариантом сообщения ключевого обмена клиента.

Структура этого сообщения:

struct { ProtocolVersion client_version; opaque random[46];} PreMasterSecret;

client_version

Последняя (новейшая) версия, поддерживаемая клиентом. Она используется для детектирования атак связанных с понижением номера версии. По получении предмастерного секретного кода сервер должен проверить, что данное значение согласуется с величиной, переданной клиентом в сообщении hello.

random

46 байт псевдослучайного кода.

struct { public-key-encrypted PreMasterSecret pre_master_secret;} EncryptedPreMasterSecret;

Атака, рассмотренная Даниэлем Блайбенбахером (Daniel Bleichenbacher) [BLEI], может быть предпринята против TLS-сервера, который использует PKCS#1, закодированный с помощью RSA.

Наилучший способ избежать уязвимости от этой атаки является обработка некорректно форматированных сообщений точно также как и корректно сформатированные RSA-блоки. Таким образом, когда сервер получает некорректно сформатированный RSA-блок, он должен сформировать случайное 48-байтовое число и использовать его в дальнейшем в качестве предмастерного секретного кода. Таким образом, сервер будет действовать идентично вне зависимости оттого, является ли полученный RSA-блок корректным.

pre_master_secret

Это случайное число генерируется клиентом и используется для формирования мастерного секретного кода, как это специфицировано в разделе 8.1.

7.4.7.2. Общедоступный Diffie-Hellman-ключ клиента

Эта структура передает общедоступную величину (Yc) Diffie-Hellman-алгоритма для клиента, если она не была уже включена в сертификат клиента. Шифрование, используемое для Yc, определяется нумерованным параметром PublicValueEncoding. Эта структура является вариантом сообщения ключевого обмена клиента.

Структура этого сообщения:

enum { implicit, explicit } PublicValueEncoding;

implicit

Если сертификат клиента уже содержит подходящий ключ алгоритма Diffie-Hellman, тогда Yc является неявным и не должно пересылаться снова. В этом случае будет послано сообщение ключевого обмена клиента (Client Key Exchange), но оно будет пустым.

explicit

Yc должно быть послано.

struct { select (PublicValueEncoding) {

case implicit: struct { };

case explicit: opaque dh_Yc; } dh_public;

} ClientDiffieHellmanPublic;

dh_Yc

Общедоступный Diffie-Hellman-ключ клиента (Yc).

7.4.8. Верификация сертификата

Это сообщение используется для осуществления в явной форме верификации сертификата клиента. Оно посылается вслед за сертификатом клиента, который имеет возможность подписи (т.e.

все сертификаты кроме тех, которые содержат фиксированные параметры Diffie-Hellman). При посылке это сообщение следует немедленно за сообщением ключевого обмена клиента.

Структура этого сообщения имеет вид:

struct { Signature signature; } CertificateVerify;

Тип подписи определен в 7.4.3.

CertificateVerify.signature.md5_hash MD5(handshake_messages);

Certificate.signature.sha_hash SHA(handshake_messages);

Здесь handshake_messages относятся ко всем сообщениям диалога, посланным или полученным, начиная с hello клиента, и вплоть до (но исключая) данное сообщение, содержащее поля типа и длины сообщений диалога. Это представляет собой соединение всех структур диалога, как это определено в 7.4.

7.4.9. Сообщение Finished

Сообщение finished всегда посылается немедленно после сообщения изменения шифровой спецификации, чтобы верифицировать процессы ключевого обмена и аутентификации. Существенно, чтобы сообщение об изменении шрифтовой спецификации было получено между другими сообщениями диалога и сообщением Finished.

Сообщение finished является первым, защищенным с использованием только что согласованных алгоритмов, ключей и секретных кодов. Получатели сообщений finished должны верифицировать корректность содержимого. Раз партнер послал свое сообщение Finished и получил корректное сообщение от другой стороны, он может начать посылать и получать через данное соединение прикладные данные.

struct { opaque verify_data[12];} Finished;

verify_data	PRF(master_secret, finished_label, MD5(handshake_messages) + SHA1(handshake_messages)) [0..11];
finished_label	Для сообщений Finished, посланных клиентом, это строка "client finished". Для сообщений Finished, посланных сервером, это строка "server finished".
handshake_messages	Все данные от сообщений диалога до этого сообщение (но не включительно). Это единственные данные, видимые на уровне диалога, они не включают заголовки уровня записей. Это соединение всех структур диалога, определенных в 7.4.

Если в соответствующей точке диалога за сообщением finished не следует сообщение об изменении шифровой спецификации, это считается фатальной ошибкой.

Хэши, содержащиеся в сообщениях finished, посланных серверам, включает в себя Sender.server; а посланные клиентом содержат Sender.client. Значение handshake_messages включает все сообщения диалога, начиная с hello клиента и вплоть до (но не включая) это сообщение finished. Здесь могут быть отличия от handshake_messages из раздела 7.4.8, так как сюда может входить сообщение верификации сертификата. Следует также иметь в виду, что, handshake_messages для сообщения finished, посланного клиентом, будет отличаться от посланного сервером, так как второе, включает первое.

Сообщения об изменении шифровой спецификации, уведомления и любые другие типы записей не являются сообщениями диалога и не включаются в вычисления хэшей. В хэши диалога не включаются также сообщения запроса Hello Request.

Обмен сообщениями в процессе диалога

Рисунок .1. Обмен сообщениями в процессе диалога

* отмечает опционные или зависящие от ситуации сообщения, которые посылаются не всегда.

Когда клиент и сервер решают возобновить предыдущую сессию или задублировать существующую сессию (вместо согласования новых параметров безопасности), следует обмен следующими сообщениями:

Клиент посылает ClientHello, используя ID-сессии, которая должна быть возобновлена. Сервер проверяет свой кэш сессий на соответствие. Если соответствие имеется, а сервер желает возобновить соединение со специфицированным состоянием сессии, он посылает ServerHello с тем же значением ID-сессии. В этой точке, как клиент, так и сервер должны послать сообщения об изменении шифровой спецификации, после чего перейти к завершающим сообщениям finished. Раз восстановление сессии завершилось, клиент и сервер могут начать обмен прикладными данными. Смотри диаграмму на Рисунок .2. Если соответствия с ID-сессии не найдено, сервер генерирует новый ID сессии, а клиент TLS и сервер осуществляют полный диалог.

Клиент	Сервер
ClientHello -------->
	ServerHello
	[ChangeCipherSpec]

[ChangeCipherSpec]

Finished ----------->
Прикладные данные	Прикладные данные

Протокол диалога TLS

7. Протокол диалога TLS

Протокол диалога TLS содержит набор из трех суб-протоколов, которые используются, чтобы партнеры могли согласовать используемые параметры безопасности для уровня записи, аутентифицировать себя, и уведомлять друг друга об ошибках.

Протокол диалога ответственен за согласования характеристик сессии, куда входят следующие объекты:

идентификатор сессии	Произвольная последовательность байтов, выбранная сервером для идентификации состояния сессии (активная/ возобновляемая).
сертификат партнера	X509v3 [X509] сертификат партнера. Этот элемент состояния может быть равен нулю.
метод сжатия	Алгоритм, используемый для сжатия информации перед шифрованием.
спецификация шифра	Специфицирует алгоритм массового шифрования (такой как нуль, DES, и т.д.) и алгоритм MAC (такой как MD5 или SHA). Она определяет также криптографические атрибуты, такие как hash_size. (Смотри приложение A.6)
мастерный секретный код	48-байтовый секретный код, общий для сервера и клиента.
'is resumable'	Флаг, указывающий, может ли сессия использоваться для инициализации нового соединения.

Эти объекты используются затем для определения параметров безопасности для уровня записей при защите прикладных данных. Многие соединения могут реализоваться в рамках той же сессии с помощью процедуры возобновления (resumption) протокола диалога.

7.1. Протокол изменения спецификации шифра

Протокол изменения спецификации шифра предназначен для оповещения об изменении стратегии шифрования. Протокол использует одно сообщение, которое зашифровано и архивировано в рамках текущего состояния соединения. Сообщение состоит из одного байта со значением 1.

struct { enum { change_cipher_spec(1), (255) } type;} ChangeCipherSpec;

Сообщение изменения спецификации шифра посылается как клиентом, так и сервером, для того чтобы уведомить партнера о том, что последующие записи будут защищены с помощью только что согласованных ключей и спецификации CipherSpec. Получение этого сообщения заставляет получателя на уровне записей немедленно скопировать состояние ожидания чтения в текущее состояние чтения.
Сразу после посылки сообщения отправитель должен дать команду уровню записей преобразовать состояние ожидания записи в активное состояние записи. (Смотри раздел 6.1.) Сообщение изменения спецификации шифра посылается во время диалога после согласования набора параметров безопасности, но до посылки проверочного завершающего сообщения (смотри раздел 7.4.9).

7.2. Протокол оповещения

Одним из типов содержимого, поддерживаемого слоем записей TLS, является оповещение. Сообщения оповещения передают описание возникшей ситуации. Оповещения с аварийным уровнем вызывают немедленное прерывание соединения. В этом случае, другие соединения сессии могут оставаться в рабочем состоянии, но идентификатор сессии должен быть объявлен не действительным, блокируя установление новых соединений. Подобно другим сообщениям, оповещения шифруются и сжимаются, как это специфицировано состоянием текущего соединения.

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;

7.2.1. Оповещения закрытия

Клиент и сервер должны оба знать, что соединение завершается, для того чтобы избежать атаки усечения (truncation). Оба партнера могут запустить обмен сообщениями закрытия.

close_notify

Это сообщение обращает внимание получателя, что отправитель не будет посылать более каких-либо данных через это соединение. Сессия становится не возобновляемой (unresumable), если любое соединение разорвано без соответствующих сообщений close_notify с уровнем равным предупреждению.

Оба партнера могут инициализировать закрытие, послав уведомление close_notify. Любые данные, полученные после оповещения о закрытии, игнорируются.

Каждый из партнеров обязан послать уведомление close_notify, прежде чем разрывать соединение со стороны записи. Требуется, чтобы другой партнер реагировал своим уведомлением close_notify и закрывал соединение немедленно, аннулируя все не завершенные записи. Для инициатора закрытия не требуется ждать получения отклика close_notify, прежде чем закрыть соединение со стороны чтения. Если прикладной протокол, использующий TLS, гарантирует, что любые данные могут быть переданы через используемое TLS-соединение после его закрытия, реализация TLS должна получить уведомление-отклик close_notify до оповещения прикладного уровня о том, что соединение TLS завершает свою работу. Если прикладной протокол не передает никаких дополнительных данных, но лишь закрывает ниже лежащее транспортное соединение, тогда реализация может выбрать вариант закрытия транспорта, не дожидаясь отклика close_notify.

Предполагается, что закрытие соединения надежно доставляет все данные, ждущие передачи, прежде чем транспортная система будет блокирована.

7.2.2. Оповещения об ошибках

Обработка ошибок в протоколе диалога TLS очень проста. Когда обнаруживается ошибка, обнаруживший партнер посылает сообщение другому партнеру. При передаче или получении сообщения о фатальной ошибке, оба партнера немедленно закрывают соединение. Серверы и клиенты должны забыть любые идентификаторы сессии, ключи и секретные коды, связанные с неудачным соединением. Определены следующие оповещения об ошибках:

unexpected_message	Получено не предусмотренное сообщение. Это оповещение является всегда фатальным и не должно встречаться при обменах между корректными реализациями.
bad_record_mac	Это оповещение присылается, если получена запись с неверным MAC. Это сообщение всегда вызывает фатальную ошибку.
decryption_failed	TLSCiphertext дешифрован не верно: либо текст не имел длину четную и кратную размеру блока или их значения (заполнители) при проверке оказались некорректными. Это сообщение всегда вызывает фатальную ошибку.
record_overflow	Получена запись TLSCiphertext, которая имеет длину больше 214+2048 байт, запись дешифрована TLSCompressed в запись с более чем 214+1024 байтов. Это сообщение всегда вызывает фатальную ошибку.
decompression_failure	Функция декомпрессии получила неприемлемые данные (напр., данные, которые после восстановления будут иметь слишком большой объем). Это сообщение вызывает фатальную ошибку.
handshake_failure	Получение сообщения оповещения handshake_failure указывает, что отправитель не мог согласовать приемлемый набор параметров безопасности из числа предлагаемых опций. Это фатальная ошибка.
bad_certificate	Сертификат был поврежден, содержал подписи, которые не прошли проверку и т.д..
unsupported_certificate	Сертификат имел не поддерживаемый тип.
certificate_revoked	Сертификат был отозван его подписантом.
certificate_expired	Сертификат имеет исчерпанный срок годности или не пригоден по другой причине.
certificate_unknown	Некоторая другая, не специфицированная причина при обработке сертификата, делающая его неприемлемым.
illegal_parameter	Поле при диалоге оказалось вне диапазона допустимых значений или не согласуется с другими полями. Это фатальная ошибка..
unknown_ca	Получена корректная сертификатная последовательность или ее часть, но сертификат не был воспринят из-за того, что CA-сертификат не может быть обнаружен или не согласуется с известным проверенным CA. Это сообщение всегда вызывает фатальную ошибку.
access_denied	Получен правильный сертификат, но при проверке доступа отправитель решил не продолжать согласование. Это сообщение всегда вызывает фатальную ошибку.
decode_error	Сообщение не может быть дешифровано из-за того, что некоторое поле выходит за пределы допустимого или сообщение имеет не верный размер. Это сообщение всегда вызывает фатальную ошибку.
decrypt_error	Диалог криптографической операции не прошел, это может включать неудачу проверки подписи, обмена ключами или контроль завершающего сообщения.
export_restriction	Согласование параметров вошло в противоречие с экспортными регламентациями. Например: попытка передать 1024 битов ephemeral RSA-ключа для метода диалога RSA_EXPORT. Это сообщение всегда вызывает фатальную ошибку.
protocol_version	Протокольная версия клиента распознана, но не поддерживается. (Например: старые версии протокола могут отвергаться по соображениям безопасности). Это сообщение всегда вызывает фатальную ошибку.
insufficient_security	Возвращается вместо handshake_failure, когда согласование не прошло в частности из-за того, что сервер требует более секретного шифра, чем может поддержать клиент. Это сообщение всегда вызывает фатальную ошибку.
internal_error	Внутренняя ошибка, не связанная с партнером, или требования протокола не допускают продолжения процедуры (например, ошибка при выделении памяти). Это сообщение всегда вызывает фатальную ошибку.
user_canceled	Этот диалог аннулирован по какой-то причине, не связанной с протокольной ошибкой. Если пользователь аннулирует операцию после завершения диалога, закрытие соединения путем посылки close_notify является более приемлемым. За этим оповещением должно следовать close_notify. Это сообщения является предупреждением.
no_renegotiation	Посылается клиентом в ответ на запрос hello или сервером - в ответ на hello клиента после стартового диалога. Любое из этих сообщений должно, в норме, вызывать повторное согласование параметров. Когда это не приемлемо, получатель должен реагировать посылкой этого уведомления (alert). В этой точке отправитель исходного запроса может решить, следует ли сохранять соединение. Случаем, когда это приемлемо, может оказаться ситуация, когда сервер запускает процесс, чтобы удовлетворить запросу. Процесс может получить параметры безопасности (длину ключа, аутентификацию и т.д.) при запуске, и может быть, трудно сообщить об изменении этих параметров в этой точке процесса. Это сообщение всегда является предупреждением.

Для всех ошибок, где уровень оповещения не специфицирован явно, отправитель может сам определить, является ли ошибка фатальной. Если получено оповещение с уровнем предупреждения, получатель может сам решить, воспринимать ли ее как фатальную. Однако все сообщения, которые переданы с фатальным уровнем, должны рассматриваться как фатальные.

7.3. Обзор протокола диалога

Криптографические параметры состояния сессии формируются протоколом диалога TLS, который работает поверх уровня записей TLS. Когда клиент и сервер TLS впервые начинают взаимодействие, они согласуют версию протокола, выбирают криптографические алгоритмы, опционно аутентифицируют друг друга и используют методику с общедоступным ключом для формирования общего секретного кода. Протокол диалога TLS включает в себя следующие шаги:

Обмен сообщениями hello, чтобы согласовать алгоритмы, обмен случайными кодами, и проверка перезапуска сессии.

Обмен необходимыми криптографическими параметрами, чтобы позволить клиенту и серверу согласовать предмастерные секретные коды.

Обмен сертификатами и криптографической информацией, чтобы позволить клиенту и серверу аутентифицировать друг друга.

Генерация мастерного секретного кода из предмастерного и обмен случайными кодами.

Предоставление параметров безопасности уровню записей.

Разрешение клиенту и серверу проверить, что их партнер вычислил те же самые параметры безопасности и что диалог прошел без вмешательства хакера.

Заметим, что верхние слои не должны слишком полагаться на TLS, всегда согласуя самые безопасные из возможных соединений между партнерами: существует много способов, с помощью которых злоумышленник, включившийся в разрыв соединения, может попытаться заставить партнеров принять наименее безопасный метод связи из числа поддерживаемых ими. Протокол был устроен так, чтобы минимизировать этот риск, но, тем не менее, существуют некоторые возможности атак. Например, хакер может блокировать доступ к порту, через который обеспечивается безопасное обслуживание, или попытаться заставить партнеров установить не аутентифицированное соединение.

Фундаментальным правилом является то, что верхние уровни должны знать, каковы требования безопасности и никогда не передавать данные по каналам, которые менее безопасны, чем это предписано этими требованиями. Протокол TLS является безопасным, здесь любой шифровой набор предлагает свой уровень безопасности. Если вы согласуете использование 3DES с 1024-битовым RSA-ключом при связи с ЭВМ, чей сертификат вы проверили, вы можете быть уверены в безопасности. Однако вы никогда не должны посылать данные по каналу, где используется 40-битовая шифрование, если только вы не уверены, что данные не стоят того, чтобы кто-то тратил силы на их дешифрование.

Эти цели достигаются протоколом диалога, который может быть суммирован следующим образом. Клиент посылает сообщение hello, на которое сервер должен также откликнуться сообщением hello, в противном случае возникает ситуация фатальной ошибки и соединение разрывается. Сообщения client hello и server hello используются для установления более безопасного взаимодействия клиента и сервера. Сообщения client hello server hello устанавливают следующие атрибуты: версия протокола, ID-сессии, шифровой набор и метод сжатия. Кроме того, партнеры генерируют и пересылают друг другу два случайных числа: ClientHello.random и ServerHello.random.

Реальный обмен ключами использует до четырех сообщений: сертификат сервера, ключевой обмен сервера, сертификат клиента и ключевой обмен клиента. Новые методы ключевого обмена могут быть созданы с помощью спецификации формата для этих сообщений, чтобы позволить клиенту и серверу согласовать использование общего секретного кода. Этот секретный код должен быть достаточно длинным. Современные методы ключевого обмена пересылают коды длиной от 48 до 128 байт.

Вслед за сообщениями hello, сервер, если он должен быть аутентифицирован, посылает свой сертификат. Кроме того, если необходимо, может быть послано сообщение ключевого обмена (например, если сервер не имеет сертификата, или если его сертификат служит только для подписи).

Если сервер аутентифицирован, он может затребовать сертификат от клиента, если выбран соответствующий шифровой набор. После этого сервер пошлет сообщение hello done, указывающее, что фаза диалога hello завершена. Сервер ждет отклика клиента. Если сервер послал сообщение сертификатного запроса, клиент должен послать сообщение сертификата. Сообщение ключевого обмена клиента послано, и его содержимое зависит от алгоритма с общедоступным ключом, который выбрали клиент и сервер при обмене сообщениями hello.

В этой точке клиентом посылается сообщение об изменении спецификации шифра, и клиент копирует записанную шифровую спецификацию в текущую спецификацию. После этого клиент немедленно посылает сообщение finished для новых алгоритмов, ключей и секретных кодов. В качестве отклика сервер пошлет свое сообщение об изменении шифровой спецификации, перенесет записанную шифровую спецификацию в текущую, и пошлет свое сообщение finished с использованием новой шифровой спецификации. В этой точке диалог завершается, а клиент и сервер могут начать обмен прикладными данными (смотри блок-схему обмена ниже на Рисунок .1).

Клиент	Сервер
ClientHello -------->
	ServerHello
	Certificate*
	ServerKeyExchange*
	CertificateRequest*

Certificate*

ClientKeyExchange

CertificateVerify*

[ChangeCipherSpec]

Finished -------->
	[ChangeCipherSpec]

Прикладные данные	Прикладные данные

Протокол TCP

4.4.3 Протокол TCP

Протокол TCP (transmission control protocol, RFC-793, -1323) в отличии от udp осуществляет доставку дейтограмм, называемых сегментами, в виде байтовых потоков с установлением соединения. Протокол TCP применяется в тех случаях, когда требуется гарантированная доставка сообщений. Он использует контрольные суммы пакетов для проверки их целостности и освобождает прикладные процессы от необходимости таймаутов и повторных передач для обеспечения надежности. Для отслеживания подтверждения доставки в TCP реализуется алгоритм "скользящего" окна. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (file transfer protocol - протокол передачи файлов) и telnet. Кроме того, TCP используют системы SMTP, HTTP, X-windows, RCP (remote copy), а также "r"-команды. Внутренняя структура модуля TCP гораздо сложнее структуры UDP. Подобно UDP прикладные процессы взаимодействуют с модулем TCP через порты (см. таблицу 4.4.2.1 в предыдущей главе). Под байтовыми потоками здесь подразумевается то, что один примитив, например, read или write (см. раздел "Программирование для сетей") может вызвать посылку адресату последовательности сегментов, которые образуют некоторый блок данных (сообщение).

Примером прикладного процесса, использующего ветвь TCP, может служить FTP, при этом будет работать стек протоколов ftp/tcp/ip/ethernet. Хотя протоколы UDP и TCP могли бы для сходных задач использовать разные номера портов, обычно этого не происходит. Модули TCP и UDP выполняют функции мультиплексоров/демультиплексоров между прикладными процессами и IP-модулем. При поступлении пакета в модуль IP он будет передан в TCP- или UDP-модуль согласно коду, записанному в поле протокола данного IP-пакета. Формат сегмента (пакета) tcp представлен ниже на Рисунок 4.4.3.1.

Если IP-протокол работает с адресами, то TCP, также как и UDP, с портами. Именно с номеров портов отправителя и получателя начинается заголовок TCP-сегмента. Поле код позиции в сообщении определяет порядковый номер первого октета в поле данных пользователя.
При значении флага syn=1 в этом поле лежит код isn (смотри ниже описание процедуры установления связи). Поле HLEN – определяет длину заголовка сегмента, которая измеряется в 32-разрядных словах. Далее следует поле резерв, предназначенное для будущего использования, в настоящее время должно обнуляться. Поле размер окна сообщает, сколько октетов готов принять получатель (флаг ACK=1). Окно имеет принципиальное значение, оно определяет число сегментов, которые могут быть посланы без получения подтверждения. Значение ширины окна может варьироваться во время сессии (смотри описание процедуры "медленного старта"). Значение этого поля равное нулю также допустимо и указывает, что байты вплоть до указанного в поле номер октета, который должен прийти следующим, получены, но адресат временно не может принимать данные. Разрешение на посылку новой информации может быть дано с помощью посылки сегмента с тем же значением поля номер октета, который должен прийти следующим, но ненулевым значением поля ширины окна. Поле контрольная сумма предназначено для обеспечения целостности сообщения. Контрольное суммирование производится по модулю 1. Перед контрольным суммированием к TCP-сегменту добавляется псевдозаголовок, как и в случае протокола udp, который включает в себя адреса отправителя и получателя, код протокола и длину сегмента, исключая псевдозаголовок. Поле указатель важной информации представляет собой указатель последнего байта, содержащий информацию, которая требует немедленного реагирования. Поле имеет смысл лишь при флаге URG=1, отмечающем сегмент с первым байтом "важной информации". Значение разрядов в 6-битовом коде (флаги) описано в таблице 4.4.3.1. Если флаг ACK=0, значение поля номер октета, который должен прийти следующим, игнорируется. Флаг urg=1 в случае нажатия пользователем клавиш Del или Ctrl-c.

Протокол TFTP

4.5.4.1 Протокол TFTP

TFTP (Trivial FTP, RFC-1350, -783, RFC-906, STD0033) представляет собой упрощенную версию FTP. TFTP не имеет системы безопасности и идентификации, она в отличии от FTP базируется на протоколе UDP (порт 69), а не TCP. Обычно передача осуществляется блоками по 512 байт с ожиданием подтверждения приема каждого пакета (протокол "стой-и-жди"). TFTP используется при загрузке операционной системы в бездисковые рабочие станции (напр. X-терминалы, см. BOOTP) или для загрузки конфигурационных файлов в маршрутизатор. Возможно и непосредственное исполнение команды TFTP (TFTP имя_ЭВМ), хотя эта процедура и не дает каких-либо серьезных преимуществ перед FTP (кроме скорости обмена). При выполнении команды без параметров машина выдает приглашение TFTP> и вам предоставляется возможность выполнить определенные команды (ЭВМ SUN):

connect имя_ЭВМ [ порт ]

Задает имя ЭВМ, с которой будет осуществляться обмен, и, если это необходимо порт. Но реального соединения не производится, так как это не предусмотрено протоколом.

mode модификация_обмена.

В качестве модификаций обмена данными могут использоваться аргументы ASCII или BINARY. По умолчанию используется ASCII.

put имя_файла

put местный_файл удаленный_файл

put имя_файла1 имя_файла2 ... имя_файлаn удаленный_каталог

Копирование файла или группы файлов в указанный файл или каталог. Здесь предполагается, что имя удаленной ЭВМ было указано ранее. Если же это не так, возможно одновременное указание имени удаленной ЭВМ и имя файла-адресата: имя_ЭВМ:имя_файла. Имя_ЭВМ становится именем по умолчанию для последующих обменов. Субкоманда GET имеет аналогичную форму обращения. Субкоманда trace позволяет отследить путь пакетов, а команда status сообщит текущее состояние системы. Уход из TFTP по команде exit или quit.

Существует пять форматов пакетов tftp:

Протокол TLS версия

6. 8 Протокол TLS версия 1.0

'The TLS Protocol Version 1.0'. T. Dierks, C. Allen. January 1999. RFC-2246.

Протокол записей TLS

6. Протокол записей TLS

Протокол записей TLS является послойным. На каждом уровне, сообщения могут включать поля длины, описания и содержимого. Протокол записей берет сообщения, подлежащие пересылке, разбивает их на блоки, опционно сжимает данные, применяет MAC, шифрует и передает результат. Полученные данные дешифруются, верифицируются, декомпрессируются, восстанавливается их первоначальный вид, результат передается клиентам верхнего уровня.

Четыре протокола описаны в данном документе: протокол диалога, протокол уведомления, протокол спецификации изменения шифра, и прикладной информационный протокол. Для того чтобы позволить расширение протокола TLS, разрешена поддержка протоколом дополнительных типов записей. Любые новые типы записей должны размещать значения типа немедленно за величинами ContentType четырех типов, описанных здесь (смотри Приложение A.2). Если реализация TLS получает рекорд нераспознаваемого типа, она должна его игнорировать. Любой протокол, предназначенный для использования поверх TLS, должен быть тщательно сконфигурирован, для того чтобы противостоять любым атакам. Заметим, что из-за того, что тип и длина записи не защищены шифрованием, следует принимать меры, чтобы минимизировать трафик анализа этих величин.

6.1. Состояния соединений

Состояние соединения TLS является операционной средой протокола записей TLS. Оно специфицирует алгоритмы сжатия, шифрования и MAC. Кроме того, известны параметры этих алгоритмов: секретный код MAC, а также ключи шифрования и IV соединения для направлений чтения и записи. Логически существует четыре состояния соединения: текущие состояния чтения и записи, и отложенные состояния чтения и записи. Все записи обрабатываются в текущих состояниях чтения или записи. Параметры безопасности для отложенных состояний могут быть установлены протоколом диалога TLS. Протокол диалога может селективно переводить любое отложенное состояние в текущее, при этом соответствующее текущее состояние становится отложенным. Не допускается формировать состояние, которое не инициализировано с учетом параметров безопасности текущего состояния.
Исходное текущее состояние всегда специфицировано без компрессии, шифрования или MAC. Параметры безопасности для состояния чтения и записи соединения TLS задаются путем определения следующих величин:

Конец соединения	Клиент или сервер участник соединения.
Алгоритм массового шифрования	Алгоритм, используемый для массового шифрования. Эта спецификация включает размер ключа алгоритма, степень секретности ключа, является ли этот шифр блочным или поточным, размер блока и является ли шифр экспортным.
Алгоритм MAC	Алгоритм аутентификации сообщений. Эта спецификация включает размер хэша, который возвращается алгоритмом MAC.
Алгоритм сжатия	Алгоритм сжатия данных. Эта спецификация должна включать всю информацию, необходимую для выполнения компрессии.
Секретный код сервера (master secret)	48 байтовый секретный код, общий для обоих партеров в соединении.
Случайный код клиента	32 байтный код, предоставляемый клиентом.
Случайный код сервера	32 байтный код, предоставляемый сервером.

Эти параметры определены в языке представления в виде:

enum { server, client } ConnectionEnd;

enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;

enum { stream, block } CipherType;

enum { true, false } IsExportable;

enum { null, md5, sha } MACAlgorithm;

enum { null(0), (255) } CompressionMethod;

/* Алгоритмы, специфицированные в 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;

Уровень записей будет использовать параметры безопасности для формирования следующих шести объектов:

Секретный код MAC записи клиента

>Секретный код MAC записи сервера

>Ключ записи клиента

Ключ записи сервера

IV записи клиента (только для блочного шифра)

IV записи сервера (только для блочного шифра)

Параметры записи клиента используются сервером при получении и обработке записей и наоборот. Алгоритм, использованный для генерирования этих объектов с помощью параметров безопасности, описан в разделе 6.3. Раз параметры безопасности определены и ключи сформированы, состояния соединения могут быть в любой момент реализованы путем перевода их в текущее состояние. Эти текущие состояния должны актуализоваться после обработки каждой записи. Каждое состояние соединения включает в себя следующие элементы:

Состояние сжатия	Текущее состояние алгоритма сжатия.
Состояние шифра	Текущее состояние алгоритма шифрования. Оно состоит из текущего ключа для данного соединения. Кроме того, для блочного шифра, работающего в режиме CBC (единственный режим, специфицированный в TLS), оно в исходный момент содержит IV для данного состояния соединения и должно актуализоваться, чтобы содержать текст последнего шифрованного или дешифрованного блока. Для поточных шифров, оно содержит всю необходимую информацию для продолжения шифрования или дешифрования данных.
Секретный код MAC	Секретный код MAC для данного соединения.
Номер по порядку	Каждое состояние соединения содержит номер по порядку, который поддерживается независимо для состояний чтения и записи. Номер по порядку должен быть установлен равным нулю, как только соединение переведено в активное состояние. Номера по порядку имеют тип uint64 и не может превышать 264-1. Номер по порядку инкрементируется после прихода каждой записи: в частности, первая запись, передаваемая через некоторое соединение, имеет порядковый номер 0.

6.2. Уровень записей

Уровень записей TLS получает не интерпретированные данные от верхних уровней в непустых блоках произвольного размера.

6.2.1. Фрагментация

Уровень записей фрагментирует информационные блоки и превращают их в записи TLSPlaintext, несущие данные в виде последовательностей длиной 214 байтов или меньше.

Границы сообщения клиента на уровне записей не сохраняются (т.e., несколько сообщений клиента одного и того же ContentType могут быть объединены в одну запись TLSPlaintext, или одно сообщение может быть фрагментировано).

struct { uint8 major, minor;} ProtocolVersion;

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;

type	Протокол верхнего уровня, использованный для обработки вложенного фрагмента .
version	Версия примененного протокола. В данном документе описывается TLS версии 1.0, который использует версию { 3, 1 }. Значение версии 3.1 является исторической: TLS версии 1.0 является минимальной модификацией протокола SSL 3.0, который несет значение версии 3.0. (Смотри приложение A.1).
length	Длина (в байтах) следующего TLSPlaintext.fragment. Длина не должна превосходить 214.
Fragment	Прикладные данные. Эти данные прозрачны и обрабатываются как независимые блоки, с которыми должен работать протокол верхнего уровня, который специфицирован полем тип.

Данные различных типов содержимого уровня записей TLS могут перекрываться. Прикладные данные вообще имеют более низкий приоритет при передаче, чем другие типы содержимого.

6.2.2. Сжатие и восстановление записи

Все записи сжаты с использованием алгоритма сжатия, определенным состоянием текущей сессии. Всегда имеется активный алгоритм сжатия; однако в исходный момент он определен как CompressionMethod.null. Алгоритм сжатия преобразует структуру TLSPlaintext в структуру TLSCompressed. Функции сжатия инициализируются информацией по умолчанию при переходе соединения в активное состояние.

Должно использоваться сжатие без потерь, а длина содержимого не может стать больше чем 1024 байт. Если функция восстановления встречает фрагмент TLSCompressed.fragment, длина которого окажется больше 214 байт, она должна выдать уведомление о фатальной ошибке преобразования.

Struct	{ ContentType type;	/* то же самое, что и TLSPlaintext.type */
	ProtocolVersion version;	/* то же самое, что и TLSPlaintext.version */
	uint16 length;
	opaque fragment[TLSCompressed.length];
	} TLSCompressed;

length	Длина (в байтах) следующего TLSCompressed.fragment. Длина не должна превосходить 214 + 1024.
Fragment	Сжатая форма TLSPlaintext.fragment.

Операция CompressionMethod.null является идентификационной; ни одно из полей не изменено.

Функции декомпрессии (восстановления) отвечают за то, что внутренний буфер не будет переполнен при обработке сообщения.

6.2.3. Защита поля данных записи

Функции шифрования и MAC преобразуют структуру TLSCompressed в TLSCiphertext. Функции дешифрования выполняют обратную процедуру. MAC записи включает также номер по порядку, чтобы было можно детектировать лишние или повторные сообщения.

Struct	{ ContentType type;
	ProtocolVersion version;
	uint16 length;
	select (CipherSpec.cipher_type) {
	case stream: GenericStreamCipher;
	case block: GenericBlockCipher; } fragment;
	} TLSCiphertext;

type	Поле тип идентично TLSCompressed.type.
Version	Поле версия идентично TLSCompressed.version.
length	Длина (в байтах) последующего TLSCiphertext.fragment. Длина не может превосходить 214 + 2048.
Fragment	Зашифрованная форма TLSCompressed.fragment, с MAC.

6.2.3.1. Нуль или стандартный поточный шифр

Поточные шифры (включая BulkCipherAlgorithm.null - смотри приложение A.6) преобразуют структуры TLSCompressed.fragment в (или из) структуры TLSCiphertext.fragment.

stream-ciphered struct { opaque content[TLSCompressed.length];

opaque MAC[CipherSpec.hash_size];} GenericStreamCipher;

MAC генерируется как:

HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +

TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));

где "+" означает объединение (слияние).

seq_num	Номер по порядку для данной записи.
hash	Алгоритм хэширования, специфицированный в SecurityParameters.mac_algorithm.

Заметим, что MAC вычисляется до шифрования. Поточный шифр преобразует весь блок, включая MAC. Для поточных шифров, которые не используют вектор синхронизации (такой как RC4), состояние шифра записи используется в последующих пакетах. Если CipherSuite равен TLS_NULL_WITH_NULL_NULL, шифрование представляет собой операцию идентичного преобразования (т.e., данные не шифруются, а размер MAC равен нулю, что говорит о том, что MAC не используется). TLSCiphertext.length равна TLSCompressed.length плюс CipherSpec.hash_size.

6.2.3.2. Блочный шифр CBC

Для блочных шифров (таких как RC2 или DES), функции шифрования и MAC преобразуют структуры TLSCompressed.fragment в блоки структур TLSCiphertext.fragment или обратно.

block-ciphered struct {

	opaque content[TLSCompressed.length];
	opaque MAC[CipherSpec.hash_size];
	uint8 padding[GenericBlockCipher.padding_length];
	uint8 padding_length;
	} GenericBlockCipher;

MAC генерируется, как это описано в разделе 6.2.3.1.

Padding

Заполнитель, который добавлен, чтобы сделать длину исходного текста целой кратной длине блока блочного шифра. Заполнитель может иметь длину вплоть до 255 байт. Длины больше необходимой могут оказаться желательными, для того чтобы блокировать атаки на протокол, базирующийся на анализе длин сообщений. Каждый uint8 в векторе заполняющих данных должен быть заполнен значением длины.

padding_length

Длина заполнения должна быть такой, чтобы общий размер структуры GenericBlockCipher являлся кратным длине блока шифра. Диапазон легальных значений лежит в диапазоне 0-255, включительно. Эта длина специфицирует длину поля заполнителя, исключая само поле padding_length.

Длина шифрованных данных (TLSCiphertext.length) на единицу больше чем сумма TLSCompressed.length, CipherSpec.hash_size и padding_length.

Пример. Если длина блока равна 8 байт, длина содержимого (TLSCompressed.length) равна 61 байтов, а длина MAC равна 20 байтов, длина до заполнения составляет 82 байта. Таким образом, длина заполнения по модулю 8 должна быть равна 6, для того чтобы сделать полную длину четной, кратной 8 байтам (длина блока).

Длина заполнения может быть 6, 14, 22 и т.д. до 254. Если бы длина заполнения была минимально необходимой (6), заполнитель имел бы 6 байтов, каждый из которых содержал число 6. Таким образом, последние 8 октетов GenericBlockCipher до блочного шифрования были бы xx 06 06 06 06 06 06 06, где xx последний октет MAC.

Для блочного шифра в режиме CBC (Cipher Block Chaining) вектор инициализации (IV) для первой записи генерируется с другими ключами и секретными кодами, когда параметры безопасности заданы. IV для последующих записей равен последнему блоку шифрованного текста предыдущей записи.

6.3. Вычисление ключа

Протокол записей требует алгоритма для генерации ключей, IV и секретных кодов MAC из параметров безопасности, поставляемых протоколом диалога.

Мастерный секретный код (master secret) хэшируется в последовательность байтов, которая присваивается секретным кодам MAC, ключам и IV, требуемых текущим состоянием соединения (смотри приложение A.6). CipherSpecs требует чтобы клиент записал секретный код MAC, чтобы сервер записал секретный код MAC, клиент и сервер записали ключ и IV, которые сформированы из мастерного секретного кода в указанном порядке. Не использованные значения остаются пустыми.

Для генерации ключей вычисляется

key_block = PRF(SecurityParameters.master_secret, "key expansion",

SecurityParameters.server_random + SecurityParameters.client_random);

до тех пор пока не будет сформирован выход. Затем key_block позиционируется следующим образом:

client_write_MAC_secret[SecurityParameters.hash_size]

server_write_MAC_secret[SecurityParameters.hash_size]

client_write_key[SecurityParameters.key_material_length]

>server_write_key[SecurityParameters.key_material_length]

client_write_IV[SecurityParameters.IV_size]

server_write_IV[SecurityParameters.IV_size]

Значения client_write_IV и server_write_IV генерируются только для не экспортных блочных шифров. Для экспортируемых блочных шифров, векторы инициализации генерируются позже, как это описано ниже.

Любой лишний материал key_block отбрасывается.

Спецификация шифра, которая определена в данном документе, требует 2 x 24 байтовых ключей, 2 x 20 байтовых секретных кодов MAC, и 2 x 8 байтов IV, для 104 байтов материала ключей.

Алгоритмы экспортируемого шифрования (для которого CipherSpec.is_exportable равно 'истинно') требуют дополнительной обработки для получения ключей записи, как это показано ниже:

final_client_write_key =

PRF(SecurityParameters.client_write_key,

	"client write key",
	SecurityParameters.client_random +
	SecurityParameters.server_random);

final_server_write_key =

PRF(SecurityParameters.server_write_key,

	"server write key",
	SecurityParameters.client_random +
	SecurityParameters.server_random);

Алгоритмы экспортируемого шифрования получают свои IV исключительно из случайных кодов сообщений hello:

iv_block = PRF("", "IV block", SecurityParameters.client_random +

SecurityParameters.server_random);

Блок iv_block делится на два инициализационных векторов, как это делалось выше для key_block:

client_write_IV[SecurityParameters.IV_size]

server_write_IV[SecurityParameters.IV_size]

Заметим, что PRF используется в этом случае без секретного кода: это означает, что секретный код имеет длину нуль байт и не вносит ничего в хэширование PRF.

6.3.1. Пример генерации экспортного ключа

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 требует пяти случайных байт для каждого из двух ключей шифрования и 16 байт для каждого ключа MAC, что составляет 42 байта ключевого материала. Выход PRF запоминается в key_block. Блок key_block делится, а ключи записи запоминаются, так как это алгоритм экспортного шифрования.

key_block	= PRF(master_secret,
	"key expansion",
	server_random +
	client_random)[0..41]
client_write_MAC_secret	= key_block[0..15]
server_write_MAC_secret	= key_block[16..31]
client_write_key	= key_block[32..36]
server_write_key	= key_block[37..41]
final_client_write_key	= PRF(client_write_key,
	"client write key",
	client_random +
	server_random)[0..15]
final_server_write_key	= PRF(server_write_key,
	"server write key",
	client_random +
	server_random)[0..15]
iv_block	= PRF("", "IV block", client_random +
	server_random)[0..15]
client_write_IV	= iv_block[0..7]
server_write_IV	= iv_block[8..15]

Схема использования скользящего окна

Рисунок 4.4.3.5. Схема использования скользящего окна

После прихода отклика на пакет окно смещается вправо на одну позицию. Теперь отправитель может послать и пакет . Если порядок прихода откликов нарушается, сдвиг окна может задержаться. Размер окна в сегментах определяется соотношением:

window > RTT*B/MSS,

где B – полоса пропускания канала в бит/с, а MSS – максимальный размер сегмента в битах, а window - в сегментах.

Для протокола TCP механизм скользящего окна может работать на уровне октетов или сегментов. В первом случае нужно учитывать каждый раз размер поля данных переданного и подтвержденного сегмента. В TCP-протоколе используется три указателя (стрелки на Рисунок 4.4.3.3б):

Первый указатель определяет положение левого края окна, отделяя посланный сегмент, получивший подтверждение, от посланного сегмента, получение которого не подтверждено. Второй указатель отмечает правый край окна и указывает на сегмент, который может быть послан до получения очередного подтверждения. Третий указатель помечает границу внутри скользящего окна между уже посланными сегментами и теми, которые еще предстоит послать. Получатель организует аналогичные окна для обеспечения контроля потока данных. Если указатель 3 совпадет с указателем 2, отправитель должен прервать дальнейшее отправление пакетов до получения хотя бы одного подтверждения. Обычно получатель посылает одно подтверждение (ACK) на два полученных сегмента.

Регулирование трафика в TCP подразумевает существование двух независимых процессов: контроль доставки, управляемый получателем с помощью параметра window, и контроль перегрузки, управляемый отправителем с помощью окна перегрузки cwnd (congestion window) и ssthreth (slow start threshold). Первый процесс отслеживает заполнение входного буфера получателя, второй - регистрирует перегрузку канала, а также связанные с этим потери и понижает уровень трафика. В исходный момент времени при установлении соединения cwnd делается равным одному MSS, а ssthreth=65535 байтам.
Программа, управляющая пересылкой, никогда не пошлет больше байт, чем это задано cwnd и объявленным получателем значением window. Когда получение очередного блока данных подтверждено, значение cwnd увеличивается. Характер этого увеличения зависит от того, осуществляется медленный старт или реализуется процедура подавления перегрузки. Если cwnd меньше или равно ssthreth, выполняется медленный старт, в противном случае осуществляется подавление перегрузки. В последнем случае cwndi+1 = cwndi + MSS/8 +(MSS*MSS)/cwnd. Если возникает состояние перегрузки канала значение cwnd снова делается равным одному MSS.

В качестве модуля приращения cwnd используется MSS. При получении подтверждения (ACK) окно перегрузки увеличивается на один сегмент ("медленный старт", CWNDi+1 = CWNDi + размер_сегмента, последнее слагаемое нужно, если размер окна задан в октетах, в противном случае вместо него следует использовать 1) и теперь отправитель может послать, не дожидаясь ACK, уже два сегмента и т.д.. Ширина окна, в конце концов, может стать настолько большой, что ошибка доставки в пределах окна станет заметной. Тогда будет запущена процедура “медленного старта” или другой алгоритм, который определит новое, уменьшенное значение окна. Окно перегрузки позволяет управлять информационным потоком со стороны отправителя, блокируя возможные перегрузки и потери данных в промежуточных узлах сети (о других методах подавления перегрузки канала смотри раздел "Сети передачи данных"). Если переполнения не происходит, CWND становится больше окна, объявленного получателем, и именно последнее будет ограничивать поток данных в канале. Размер окна, объявленный получателем, ограничивается произведением полосы пропускания канала (бит/с) на RTT (время распространения пакета туда и обратно). Максимально допустимый размер окна в TCP равен 65535 байт (задается размером поля). Конечной целью регулирования трафика является установление соответствия между темпом передачи и возможностями приема.

Причиной перегрузки может быть не только ограниченность размера буфера, но и недостаточная пропускная способность какого-то участка канала. С учетом этого обстоятельства каждый отправитель формирует два окна: окно получателя и окно перегрузки (ширина этого окна равна cwnd). Каждое из этих окон задает число байтов, которое может послать отправитель. Реальное число байтов, которое разрешено послать, равно минимальному из этих окон. При инициализации соединения окно перегрузки имеет ширину равную максимальному сегменту, который может быть использован в данном канале. Отправитель посылает такой сегмент. Если будет прислано подтверждение до истечения времени таймаута, размер окна перегрузки удваивается и посылается два сегмента максимальной длины. При получении подтверждения доставки каждого из сегментов окно перегрузки увеличивается на один сегмент максимальной длины. Когда ширина окна перегрузки становится равной B сегментов и все B посланных сегментов получают подтверждение, окно перегрузки возрастает на число байт, содержащихся в этих сегментах. Таким образом, ширина окна перегрузки последовательно удваивается, пока доставка всех сегментов подтверждается. Рост ширины окна перегрузки при этом имеет экспоненциальный характер. Это продолжается до тех пор, пока не наступит таймаут или окно перегрузки не сравняется с окном получателя. Именно эта процедура и называется медленным стартом (Джекобсон, 1988).

Как было сказано выше, помимо окон перегрузки и получателя в TCP используется третий параметр - порог (иногда он называется порогом медленного старта ssthresh). При установлении соединения ssthresh=64 Kбайт. В случае возникновения таймаута значение ssthresh делается равным CWND/2, а само значение CWND приравнивается MSS (см. Рисунок 4.4.3.6). Далее запускается процедура медленного старта, чтобы выяснить возможности канала. При этом экспоненциальный рост cwnd осуществляется вплоть до значения ssthresh. Когда этот уровень cwnd достигнут, дальнейший рост происходит линейно с приращением на каждом шагу равным MSS (Рисунок 4.4.3.6).

Схема эхо-компенсации с адаптивным

Рисунок 2.1.6. Схема эхо-компенсации с адаптивным фильтром

На Рисунок 2.1.7 показана зависимость скорости пропускания от сопротивления петли передающей линии для разных схем кодирования сигнала (пунктирной линией отображен вариант четырехуровневого кодирования). Те, кто работал с выделенными линиями, усвоили эту зависимость на практике. Если сопротивление линии более 1,5 кОм вы скоро будете знать дежурных вашей телефонной станции по имени, узнаете, что такое грозовые вставки и что они имеют привычку окисляться.

Схема подключения UPS

Рисунок 6.1.1. Схема подключения UPS.

При исчезновении первичного напряжения ~220V спустя некоторое время UPS выдает сигнал shutdown вычислительной машине. Современный UPS может мониторировать не только напряжение питание, но температуру окружающей среды, своевременно осуществляя спасение жизненно важных файлов до наступления чрезмерного перегрева системы. При этом значение напряжения питания и температуры можно считывать с использованием протокола SNMP. Некоторые продвинутые системы автономного питания допускают подключение агентов SNMP непосредственно к локальной сети, что открывает дополнительные возможности дистанционного управления и мониторинга.

Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами.

Создавая сеть, следует сразу закладывать некоторые элементы, обеспечивающие безопасность. Так прокладку сетевых кабелей желательно производить в металлических коробах или трубах, что сделает подключение к ним более затруднительным. Повторители и концентраторы нужно размещать в запираемых шкафах. Некоторые концентраторы контролируют MAC-адреса пакетов. Такое оборудование позволяет блокировать порт, если обнаруживаются пакеты с неизвестным MAC-адресом, а также выявлять случаи подключения одного и того же MAC-адреса к разным портам. Определенную угрозу сетевой безопасности может представлять возможность присвоение хакером “чужого” MAC-адреса своей сетевой карте. Современные концентраторы запрещают подключенному к порту узлу передавать кадры с MAC-адресом, не совпадающим с определенным администратором для данного порта. Это обеспечивает дополнительную надежность канального уровня.

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

Так как современные системы шифрования предполагают использование довольно трудоемких вычислений, которые заметно замедляют процесс, разрабатываются специальные микросхемы.

Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр. дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа Exabyte емкостью 2.5-10Гбайт еще достаточно широко используются, высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи на них оставляет желать лучшего). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более .

В последнее время широкое распространение получают панели касания, способные распознавать людей по отпечатку пальца или ладони (см. http://elce.quarta.msk.ru/UCC/t_scrb_e.htm). Сходные устройства используются для непосредственного ввода подписи клиента (устройство типа планшет, иногда совмещаемое с дисплеем) и сверки ее с имеющимся образцом.

Схема транспортировки запросов при использовании прокси-сервера

Рисунок 4.4.1.2.2. Схема транспортировки запросов при использовании прокси-сервера

Схема с “невидимым” прокси-сервером работает следующим образом. Сначала запрос поступает в маршрутизатор, там он анализируется и, если выясняется что это HTTP или FTP-запросы, переадресуется прокси-серверу. Если запрашиваемый файл находится в буфере сервера, заказ клиента удовлетворяется локально. В противном случае запрос снова посылается маршрутизатору. Запросы прокси-сервера маршрутизатор переправляет во внешнюю сеть. В случае использования персональной ЭВМ в качестве прокси-сервера можно ее снабдить двумя сетевыми интерфейсами для приема и посылки запросов, что сделает работу более эффективной. Если маршрутизатор не поддерживает описанный режим, то при конфигурации сетевого программного обеспечения клиента можно явно прописать адрес прокси-сервера и все соответствующие запросы пойдут непосредственно туда.

Туннели широко используются и при передаче мультимедийных данных.

Схема туннелирования пакетов Квадратными

Рисунок 4.4.1.2.1 Схема туннелирования пакетов. Квадратными скобками отмечено вложение пакетов. В числителе приводится адрес места назначения, в знаменателе адрес отправителя. Адрес вне скобок – адрес места назначения.

Из рисунка видно, что простой туннель может породить асимметричный маршрут, при котором путь туда и обратно не совпадают. Чтобы такого не произошло, применяется техника “маскарада” (masquerading). Для этого “маршрутизатор конца туннеля” должен извлечь вложенный пакет (как это он делает и на Рисунок 4.4.1.2.1) и вложить его в пакет с адресом места назначения IP3, указав при этом в качестве отправителя себя (IP3/IP2[IP3/IP1]). Тогда конечный адресат IP3 будет посылать отклики по адресу IP2, а не IP1. А уже маршрутизатор конца туннеля будет пересылать их первоисточнику запроса IP1.

В последнее время техника туннелей нашла применение при построении так называемых прокси-серверов, популярность которых связана с возможностью заметно сократить внешний (часто зарубежный) трафик за счет запоминания в дисковом буфере файлов, наиболее часто запрашиваемых клиентами. Заметно упрощает решение данной задачи многие современные маршрутизаторы, которые могут отфильтровывать запросы по определенным портам и переадресовывать их прокси-серверу (см. Рисунок 4.4.1.2.2).

Структура кадров для американского (вверху) и европейского (внизу) стандартов передачи данных

Рисунок 2.3.1. Структура кадров для американского (вверху) и европейского (внизу) стандартов передачи данных

Скорости передачи 1,544 (кодирование B8ZS) и 2,048 Мбит/с (HDB3) называются первичными скоростями. Кадры структурированы так, что временные домены (таймдомен на Рисунок 2.3.1) для передачи данных по каналам B1 и B2 чередуются. В Европе используется 2048Мбит/с интерфейс. Каждый 6-ой кадр используется для сигнальных целей. Количество временных доменов в кадре определяет число телефонных разговоров, которые могут осуществляться одновременно. Для американского стандарта это число равно 24, а для европейского 30 (в последнем случае учтено то, что часть доменов используется в служебных целях).

Все современные коммутаторы управляются центральным процессором. Такие коммутаторы обычно называются коммутаторами, управляемыми встроенной памятью (SPC - Stored Program Controlled exchanges).

Коды команд TELNET

Таблица 4.5.3.4. Коды команд TELNET

Имя субкоманды TELNET	Код	Описание
EOF	236	Признак конца файла
SUSP	237	Отложить исполнение текущего процесса
ABORT	238	Абортировать процесс
EOR	239	Конец записи
NOP	241	Никаких действий
DM(Метка данных)	242	Блок данных процедуры SYNCH
BRK (Остановка)	243	brk-символ (break);
IP(Прерывание процесса)	244	IP-функция
io (Прерывание вывода)	245	AO-функция
AYT (Вы здесь?)	246	ayt-функция
EC (Стереть символ)	247	EC-функция
EL (Стереть строку)	248	EL-функция
GA (Продолжайте)	249	GA-функция
SB	250	Начало субопции
SE	240	Завершение согласования параметров (конец субопции)
Will ("будет")	251	Начало исполнения (опционно)
Won't (не будет)	252	Отказ исполнения или продолжения выполнения (опционно)
Do("исполнить")	253	Индицирует запрос, который другая система исполняет (опционно)
Don't ("Нет")	254	Требует, чтобы другая система остановила исполнение (опционно)
IAC	255	Интерпретируется как начало командной последовательности

Операция прерывание процесса (IP) позволяет прервать, удалить или завершить процесс пользователя (например, выйти из бесконечного цикла).

Процедура прерывание вывода (AO) позволяет процессу пользователя продолжаться, но вывод на его рабочую станцию прерывается, при этом очищается буфер от уже записанной, но не отображенной информации.

Запрос "Вы здесь?" (AYT) удобен, когда необходимо выяснить выполняется ли пользовательская задача или нет.

Операция стереть символ (EC) позволяет пользователю удалить символ из потока данных, применяется для редактирования текста на экране.

Операция стереть строку (EL) позволяет пользователю при редактировании удалить целую строку.

Команда "go ahead" (GA, "продолжайте") устанавливает полудуплексный режим передачи данных. Каких-либо воздействий на удаленную ЭВМ обычно не производит. В таблице 4.5.3.5 приведен список комбинаций клавиш, нажатие которых вызывает определенный результат.

Коды опций в Telnet

Таблица 4.5.3.1. Коды опций в Telnet

Код опции в Telnet	Описание	Номер RFC
0	Двоичный обмен	856
1	Эхо	857
2	Повторное соединение	NIC 15391
3	Подавление буферизации ввода	858
4	Диалог о размере сообщения	NIC 15393
5	Статус	859
6	Временная метка	860
7	Удаленный доступ и отклик	726
8	Длина выходной строки	nic 20196
9	Размер выходной страницы	nic 20197
10	Режим вывода символов	652
11	Вывод горизонтальной табуляции	653
12	Установка положения табуляции при выводе	654
13	Режим вывода команды смены страницы	655
14	Вывод вертикальной табуляции	656
15	Определяет положение вертикальной табуляции	657
16	Режим вывода символа	658
17	Расширенный набор кодов ASCII	698
18	Возврат (logout)	727
19	Байт-макро	735
20	Терминал ввода данных	732
21	Supdup	736
22	Supdup вывод	747
23	Место отправления	779
24	Тип терминала	930
25	Конец записи	885
26	Tacacs- идентификация пользователя	927
27	Пометка вывода	933
28	Код положения терминала	946
29	Режим 3270	1041
30	X.3 PAD	1053
31	Размер окна	1073

Когда связь с удаленной ЭВМ уже осуществлена, переход в командный режим может быть выполнен с помощью нажатия '^]' (escape).

В этом режиме доступны команды:

open имя_ЭВМ [ порт ]	open открывает связь с ЭВМ, имя которой указано в обращении. Если номер порта явно не указан, telnet пытается использовать для связи с сервером номер порта по умолчанию. Вместо имени ЭВМ-сервера может использоваться ее IP-адрес.
display [ аргумент ... ]	Отображает все, или часть, набора параметров telnet (см. описание команды send).
close	Закрывает сессию telnet и возвращает систему в командный режим.
quit	Закрывает любую сессию telnet.
mode type	Управляет режимом ввода ("построчный" или "посимвольный"). Удаленной машине посылается запрос на переход в соответствующий режим. Если она готова (способна) работать в запрошенном режиме, будет произведено соответствующее переключение.
status	Отображает текущий статус telnet. В перечень информации входит имя удаленной ЭВМ и действующий режим обмена.
? [ команда ]	Выдает справочную информацию о команде, название которой приведено в качестве аргумента
send arguments	Посылает удаленной ЭВМ один или несколько символьных аргументов. В качестве аргументов могут использоваться: escape, synch, brk, ip, ao, ayt, ecel, ga и др. Смотри таблицу 4.5.3.3.
escape	Посылает escape символ (например, `^]').
SYNCH	Посылает synch-последовательность. Эта последовательность позволяет аннулировать все, что было до этого напечатано, но еще не считано. Эта последовательность посылается как срочная (важная) TCP-информация (может не сработать, если удаленной системой является 4.2 BSD). Если она не сработала, на терминал будет послан символ "r".
brk	Посылает Break-последовательность при нажатии клавиши Break (Pause). (Исчерпывающую информацию об аргументах можно найти в описании используемого программного обеспечения или с помощью команд Help или Man)
set argument value	Присваивает любому числу переменных telnet новые значения. Специальное значение "off" выключает функцию, соответствующую данной переменной

Значения переменных можно узнать с помощью команды display. Такими переменными могут быть: echo, escape, interrupt, quit, flushoutput, erase, kill, eof, echo. Последняя переменная (в исходном состоянии `^E') в построчном режиме осуществляет переключение между локальным эхо на ввод символа (режим по умолчанию) и подавлением эхо, например при вводе пароля. Переменные процедуры telnet представлены в таблице 4.5.3.2.

Практически стандарт TELNET описан во многих RFC документах, которые определяют различные варианты реализации этой команды. Список опций команды telnet приведен в таблице 4.5.3.1 (не все эти возможности доступны в конкретных программных продуктах).

Переменные telnet

Таблица 4.5.3.2. Переменные telnet

Название переменной

Назначение

Echo

Определяет, будет ли отображаться на экране то, что вы вводите с клавиатуры. При значении off ввод не отображается, например, при вводе пароля.

Escape

Задает символ, который используется в качестве escape. Появление этого символа во входном потоке заставляет его и последующие символы интерпретироваться в ЭВМ, где функционирует процесс telnet, как команда

Interrupt

Специфицирует символ прерывания процесса. Ввод его приводит к остановке процесса пользователя, работающего на удаленной ЭВМ.

Quit

Специфицирует символ, который используется пользователем на его клавиатуре для выполнения команд brake или attention.

Flushoutput

Определяет символ, который служит для прерывания процедуры вывода на удаленной ЭВМ.

EOF

Специфицирует символ, который используется для обозначения конца файла на удаленной машине.

Последовательности символов, используемые совместно с командой send

Таблица 4.5.3.3. Последовательности символов, используемые совместно с командой send

Последовательность символов	Назначение
?	Отображает справочную информацию о команде send
escape	Посылает символ escape (без прерывания посылки символов для Telnet)
ip	Посылает протокольную последовательность telnet. Удаленная машина должна прервать процесс, запущенный для вас.
ec	Посылает протокольную EC-последовательность telnet. Удаленная ЭВМ должна стереть последний напечатанный вами символ
el	Посылает протокольную EL-последовательность TELNET. Удаленная ЭВМ должна стереть последнюю напечатанную вами строку.
ao	Посылает протокольную AO-последовательность TELNET. Удаленная ЭВМ должна направить весь вывод на ваш терминал.
brk	Посылает протокольную BRK-последовательность TELNET. Удаленная ЭВМ должна обеспечить отклик.
ayt	Посылает протокольную AYT-последовательность TELNET (Are You There). Удаленная ЭВМ должна обеспечить отклик.

В таблице 4.5.3.4 представлены наименования и коды команд Telnet, которые используются как клиентом, так и сервером в сочетании с префиксным байтом 0xff (IAC - "интерпретировать как команду"). Если нужно послать код данных, равный 255, посылается два байта с кодами 255.

Управляющие комбинации клавиш

Таблица 4.5.3.5. Управляющие комбинации клавиш

Комбинация клавиш	Достигаемый результат
Ctrl+E	Echo
Ctrl+]	Escape
Ctrl+?	Erase
Ctrl+O	flushoutput
Ctrl+C	Interrupt (прерывание исполнения программы)
Ctrl+U	Kill
Ctrl+\	Quit
Ctrl+D	EOF

Блок данных процедуры TELNET содержит три байта и называется командой. Формат этого блока показан на Рисунок 4.5.3.1.

Значения бит поля флаги

Таблица 4.4.3.1 Значения бит поля флаги

Обозначение битов (слева на право) поля флаги

Значение бита, если он равен 1

urg

Флаг важной информации, поле Указатель важной информации имеет смысл, если urg=1.

ack

Номер октета, который должен прийти следующим, правилен.

psh

Этот сегмент требует выполнения операции push. Получатель должен передать эти данные прикладной программе как можно быстрее.

rst

Прерывание связи.

syn

Флаг для синхронизации номеров сегментов, используется при установлении связи.

fin

Отправитель закончил посылку байтов.

Технические средства сетевой безопасности

6.1 Технические средства сетевой безопасности

Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли и спросить не с кого. Начинать надо с того, что в вашей власти, а это прежде всего правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех). Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (Uninterruptable Power Supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При снижении напряжения сети переменного тока ниже определенного уровня UPS (около 208v) отключает потребителя от сети и осуществляет питание ЭВМ от ~220v, получаемого от аккумулятора самого UPS. Учитывая нестабильность напряжения сети в России, можно считать полезным применение активных стабилизаторов на входе UPS.

При выборе UPS нужно учесть суммарную потребляемую мощность оборудования, подключаемого к источнику питания, и время, в течение которого UPS способен работать без напряжения в сети. При этом главная задача UPS - обеспечение завершения операций обмена с диском до того, как произойдет полное обесточивание сервера, или когда будет произведено переключение на резервный канал питания. Это осуществимо при использование специального интерфейса и соответствующего программного обеспечения, работающего согласно протокола SNMP(см. Рисунок 6.1.1).

Удаленный доступ (Telnet)

4.5.3 Удаленный доступ (Telnet)

TELNET позволяет пользователю установить TCP-соединение с сервером и затем передавать коды нажатия клавиш так, как если бы работа проводилась на консоли сервера. TELNET (RFC-854, в некоторых реализациях tn) служит для выполнения удаленного доступа к вычислительным ресурсам и базам данных (например, к базам ядерных данных в Вене, Брукхейвене или STN-international в Карлсруэ). Для входа в базу данных или ЭВМ обычно нужна аутентификация (ввод имени-идентификатора пользователя и его слова-пропуска). В некоторых реализациях допускается использование параметров, которые подключают необходимые эмуляторы терминалов.

TELNET предлагает три услуги: Определяет сетевой виртуальный терминал (NVT - network virtual terminal), который обеспечивает стандартный интерфейс к удаленной системе.

Включает механизм, который позволяет клиенту и серверу согласовать опции обмена

Обеспечивает симметрию соединения, допуская любой программе (например FTP) выступать в качестве клиента

Протокол TELNET позволяет обслуживающей машине рассматривать все удаленные терминалы как стандартные "сетевые виртуальные терминалы" строчного типа, работающие в кодах ASCII, а также обеспечивает возможность согласования более сложных функций (например, локальный или удаленный эхо-контроль, страничный режим, высота и ширина экрана и т. д.). На прикладном уровне над TELNET находится либо программа поддержки реального терминала, либо прикладной процесс в обслуживающей машине, к которому осуществляется доступ с терминала. Формат NTV достаточно прост. Для данных используются 7-битовые ASCII коды. 8-битовые же октеты зарезервированы для командных последовательностей.

Telnet взаимодействует с другой ЭВМ через протокол TELNET. Если команда TELNET вводится без аргументов ЭВМ переходит в командный режим, напечатав приглашение telnet>. В этом режиме она воспринимает и исполняет команды, описанные ниже.

При вводе TELNET с аргументами программа осуществит связь вашей ЭВМ с удаленным компьютером, имя или адрес которого вы ввели в качестве одного из аргументов.

После того как TELNET связь установлена, начинаются переговоры об используемых опциях (см. табл. 4.5.3.1). Каждая из договаривающихся сторон может послать другой один из четырех запросов will, do, wont и dont (см табл. 4.5.3.4).

Далее TELNET переходит в режим ввода. В этом режиме любой введенный текст пересылается удаленной ЭВМ. Ввод может производиться посимвольно или построчно. При посимвольном режиме каждый введенный символ пересылается немедленно, при построчном режиме отклик на каждое нажатие клавиши производится локально, а пересылка выполняется лишь при нажатии клавиши <Enter>. Некоторые опции требуют дополнительных данных, такая информация ожет быть получена с помощью субопций (RFC-1091). При этом клиент посылает трехбайтовую последовательность IAC WILL 24, где 24 - код-идентификатор терминала. Получатель может откликнуться последовательностью IAC DO 24, если все в порядке. Сервер в свою очередь посылает последовательность IAC SB 24 1 IAC SE, запрашивая тип терминала клиента. Здесь код 24 означает, что это субопция для опции типа терминала (см. табл. 4.5.3.1), а следующая 1 является командой "пришлите код вашего терминала". Клиент в свою очередь может откликнуться, послав последовательность - IAC SB 24 0 I B M P C IAC SE. Здесь байт 0 имеет значение "мой терминал имеет тип". Список кодов терминалов содержится в RFC-1700.

Transport Layer Security) является обеспечение

1. Введение

Первоначальной целью протокола TLS ( Transport Layer Security) является обеспечение конфиденциальности и целостности данных при коммуникации двух приложений. Протокол имеет два уровня: протокол записей TLS и протокол диалога TLS. На нижнем уровне, работающем поверх надежного транспортного протокола (напр., TCP [TCP]), размещается протокол записей TLS. Этот протокол обеспечивает безопасность соединений, которые имеют два основных свойства:
Соединение является конфиденциальным. Для шифрования данных используется симметричная криптография (напр., DES [DES], RC4 [RC4], и т.д.). Ключи для шифрования генерируются независимо для каждого соединения и базируются на секретном коде, получаемом с помощью другого протокола (такого как протокол диалога TLS). Протокол записей может использоваться и без шифрования.
Соединение является надежным. Процедура передачи сообщения включает в себя проверку целостности с помощью вычисления MAC. Для расчета >MAC используются хэш-функции (напр., SHA, MD5 и т.д.). Протокол записей может работать и без MAC, но в этом режиме он применяется только в случае, когда другой протокол использует протокол записей в качестве транспортного при выяснении параметров безопасности.
Протокол записей TLS используется для инкапсуляции различных протоколов высокого уровня. Один из таких инкапсулируемых объектов, протокол диалога TLS, позволяет серверу и клиенту аутентифицировать друг друга и согласовать алгоритм шифрования и крипто-ключи до того как приложение передаст или примет первый байт информации. Протокол диалога TLS обеспечивает безопасное соединение, которое имеет три базовых свойства:
Идентичность партнеров может быть выяснена с использованием асимметричной криптографии (напр., RSA [RSA], DSS [DSS] и т.д.). Эта аутентификация может быть сделана опционной, но она необходима, по крайней мере, для одного из партнеров.
Выявление общего секретного кода является безопасным: этот секретный код недоступен злоумышленнику, даже если он ухитрится подключиться к соединению.
Диалог надежен: атакующий не может модифицировать обсуждаемое соединение, без того чтобы быть обнаруженным партнерами обмена.
Одним из преимуществ TLS является то, что он не зависит от протокола приложения. Протоколы верхнего уровня могут размещаться поверх протокола TLS прозрачным образом. Стандарт TLS, однако, не специфицирует то, как протоколы увеличивают безопасность с помощью TLS; решение о том, как инициализировать TLS-диалог и как интерпретировать сертификаты аутентификации, оставляется на усмотрение разработчиков протоколов и программ, которые работают поверх TLS.

Зависимость максимальной скорости передачи данных от сопротивления петли передающей линии

Рисунок 2.1.7. Зависимость максимальной скорости передачи данных от сопротивления петли передающей линии

Различные методы модуляции приводят к разным уровням перекрестных наводок, и, как следствие, могут обеспечить разные скорости пропускания сигналов. Так применение линейной эквилизации при амплитудной модуляции дает улучшение пропускной способности примерно в 5 раз. Из рисунка 2.1.8 видно, что переход от линейного выравнивания к эквилизации с обратной связью позволяет добиться улучшения почти в 1,5 раза. Многоуровневый метод кодирования увеличивает скорость пропускания еще на 30%. Следует, правда, иметь в виду, что многоуровневый метод кодирования характеризуется большим уровнем импульсных помех и, следовательно, ошибок.

Зависимость ослабления сигнала в медной линии сечением м от частоты

Рисунок 2.1.1. Зависимость ослабления сигнала в медной линии сечением 0,5мм от частоты

От частоты зависит фаза (из расчета на километр) и волновое сопротивление скрученной пары (см. Рисунок 2.1.2), по этой причине искажения формы сигнала при заметной длине линии неизбежны.

Из формулы [2.1] видно, что расширять пропускную способность канала можно за счет широкополосности и высокого отношения сигнал-шум. Существует много источников шума, один из главных тепловые шумы (N = kTB, где T – температура в градусах Кельвина, B – полоса пропускания приемника, а k – постоянная Больцмана). На практике существенно большее влияние оказывают различного рода наводки. Увеличeние пропускной способности сети достигается путем сокращения длины кабеля (уменьшение расстояния между узлами сети), заменой типа кабеля, например, на провод с большим сечением, или применив оптоволоконный кабель. Определенный эффект может быть получен и с помощью усовершенствованной системы шумоподавления (новый, более эффективный модем).

Зависимость волнового импеданса скрученной пары и фазы (сечение м) от частоты

Рисунок 2.1.2. Зависимость волнового импеданса скрученной пары и фазы (сечение 0,5мм) от частоты

Сопротивление скрученной пары от коммутатора до терминального оборудования может лежать в пределах 800-20000 Ом. Следует учитывать, что при подаче питания на терминальное оборудование (телефон) по подводящему кабелю, большое его сопротивление, помимо прочего, приведет к падению питающего напряжения. В многожильных кабелях определенные проблемы создают перекрестные наводки и шумы. Обычно рассматриваются два случая перекрестных наводок:

Источник сигнала и приемник находятся по одну сторону кабеля (NEXT - near end crosstalk);

Приемник и источник находятся на разных концах кабеля (FRXT - far end crosstalk).

NEXT-наводки при большом числе пар проводов в кабеле подчиняются закону f1.5 , а их уровень составляет около 55 дБ при частоте 100 кГц. FEXT-наводки сильно зависят от схемы коммутации и разводки проводов и обычно менее опасны, чем NEXT. Еще одним источников наводок является импульсный шум внешних электромагнитных переходных процессов. Этот вид наводок обычно характеризуется процентом времени, в течении которого его уровень превышает порог чувствительности, и варьируется в зависимости от обстоятельств в очень широких пределах.

При передаче по линии сигналы модулируются, при этом важно обеспечить сохранение среднего уровня сигнала (постоянной составляющей). Определенные искажения сигнала вносит сам кабель. Заметное влияние на характер искажений оказывает межсимвольная интерференция (ISI - Intersymbol Interference). Эта интерференция возникает из-за расплывания импульсов в процессе их передачи по линии и наезжания их друг на друга. Проблема усложняется тем, что характеристики передающей линии могут меняться со временем (коммутаторы и маршрутизаторы). По этой причине очень важно обеспечить идентичность условий передачи различных частот при наличии таких вариаций. Для решения этой задачи используются линейные эквилайзеры (Рисунок 2.1.3 и 2.1.4), которые выполняют эту операцию во всем спектре частот, или после стробирования для реального спектра сигнала. Этот метод чувствителен к шумам в системе. Эквилайзеры с решающей обратной связью (DFE - Decision Feedback Equalizer) не чувствительны к шумам, они управляются принятой информацией. Но влияние ошибок при приеме информации в этом случае может быть усилено.