» Главная
eXcode.ru » Статьи » Защита информации » Протоколы безопасного сетевого взаимодействия
» Новости
» Опросы
» Файлы
» Журнал



Пользователей: 0
Гостей: 15





Безопасное сетевое взаимодействие (часть 2)




Протокол TLS/SSL

Введение

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

Протокол TLS (Transport Layer Security) разрабатывался на основе спецификации протокола SSL 3.0 (Secure Socket Layer), опубликованного корпорацией Netscape. Различия между данным протоколом и SSL 3.0 несущественны, но важно заметить, что TLS 1.0 и SSL 3.0 несовместимы, хотя в TLS 1.0 предусмотрен механизм, который позволяет реализациям TLS иметь обратную совместимость с SSL 3.0.

Перечислим задачи протокола TLS в порядке их приоритета:

  1. Криптографическая безопасность: TLS должен использоваться для установления безопасного соединения между двумя участниками.
  2. Интероперабельность: независимые разработчики могут создавать приложения, которые будут взаимодействовать по протоколу TLS, что позволит устанавливать безопасные соединения.
  3. Расширяемость: TLS формирует общий каркас, в который могут быть встроены новые алгоритмы открытого ключа и симметричного шифрования. Это также избавляет от необходимости создавать новый протокол, что сопряжено с опасностью появления новых слабых мест, и предотвращает необходимость полностью реализовывать новую библиотеку безопасности.
  4. Относительная эффективность: криптографические операции интенсивно используют ЦП, особенно операции с открытым ключом. Для этого вводится понятие сессии, для которой определяются алгоритмы и их параметры. В рамках одной сессии может быть создано несколько соединений (например, ТСР). TLS позволяет кэшировать сессии для уменьшения количества выполняемых действий при установлении соединения. Это снижает нагрузку как на ЦП, так и на трафик.

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

  1. Конфиденциальность соединения. Для защиты данных используется один из алгоритмов симметричного шифрования. Ключ для этого алгоритма создается для каждой сессии и основан на секрете, о котором договариваются в протоколе Рукопожатия. Протокол Записи также может использоваться без шифрования.
  2. Целостность соединения. Обеспечивается проверка целостности сообщения с помощью МАС с ключом. Для вычисления МАС используются безопасные хэш-функции SHA-1 и MD5. Протокол Записи может выполняться без вычисления МАС, но обычно функционирует в этом режиме.

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

Протокол Рукопожатия обеспечивает безопасность соединения, которая основана на следующих свойствах:

  1. Участники аутентифицированы с использованием криптографии с открытым ключом (т.е. с использованием алгоритмов RSA, DSS и т.д.). Эта аутентификация может быть необязательной, но обычно требуется по крайней мере для сервера.
  2. Переговоры о разделяемом секрете безопасны, т.е. этот общий секрет невозможно подсмотреть.
  3. Переговоры о разделяемом секрете надежны, если выполнена аутентификация хотя бы одной из сторон. В таком случае атакующий, расположенный в середине соединения, не может модифицировать передаваемый секрет незаметно для участников соединения.

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

Элементы протокола

Криптографические операции

Определены четыре криптографические операции: цифровая подпись, поточное шифрование, блочное шифрование и шифрование с открытым ключом.

В операции цифровой подписи входом в алгоритм подписи является результат применения односторонней хэш-функции к подписываемым данным. Длина входа определяется алгоритмом подписи.

При использовании алгоритма RSA подписывается 36-байтная структура, состоящая из конкатенации 20 байтов хэш-кода SHA-1 и 16 байтов хэш-кода MD5.

При использовании DSS 20 байтов хэш-кода SHA-1 подаются на вход алгоритму DSA без дополнительного хэширования. При этом создается два значения: r и s.

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

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

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

НМАС и псевдослучайная функция

Для получения МАС используется НМАС, поэтому если не знать секрета МАС, подделать МАС невозможно.

НМАС может использоваться с различными хэш-алгоритмами. TLS задействует при Рукопожатии два алгоритма, MD5 и SHA-1, обозначаемых как HMAC_MD5 (secret, data) и HMAC_SHA (secret, data). Могут быть определены дополнительные хэш-алгоритмы, но в настоящей версии используются только MD5 и SHA-1.

В алгоритме определена функция, которая расширяет секрет до нужной длины для создания всех необходимых ключей. Такая псевдослучайная функция, PRF, получает в качестве входа секрет, «зерно» (seed – значение, которое с одной стороны является случайным, а с другой стороны не является секретным, т.е. может стать известно оппоненту) и идентификационную метку, и создает выход требуемой длины.

Для того чтобы сделать 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) + ...

Где

+ – обозначает конкатенацию.

А () – определяется следующим образом:

А (0) = seed

A (i) = HMAC_hash (secret, A (i – 1))

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

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

PRF определяется как результат сложения по модулю 2 этих двух псевдослучайных значений.

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

Label является фиксированной текстовой строкой.

Заметим, что поскольку MD5 создает 16-байтные значения, а SHA-1 создает 20-байтные значения, то границы внутренних итераций не будут совпадать. Например, для создания 80-байтного значения необходимо выполнить 5 итераций P_MD5 и 4 итерации P_SHA-1.

Протокол Записи

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

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

Состояния соединения

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

Параметры безопасности для состояний чтения и записи устанавливаются с помощью следующих значений (см. таб. 21.1).

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

client write MAC secret

server write MAC secret

client write key

server write key

client write IV – только для блочных алгоритмов

server write IV – только для блочных алгоритмов

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

Таблица 21.1. Параметры состояния соединения
Конец соединенияКаждый участник является либо «клиентом», либо «сервером»
Алгоритм симметричного шифрованияАлгоритм, используемый для симметричного шифрования. Данное описание включает размер ключа алгоритма, тип алгоритма (блочный или поточный), размер блока алгоритма и информацию о том, является ли он «экспортируемым»
МАС алгоритмАлгоритм, используемый для проверки целостности сообщения. Это описание включает размер хэша, который возвращается МАС-алгоритмом
Алгоритм сжатияАлгоритм, используемый для сжатия данных. Данное описание включает всю информацию, необходимую алгоритму сжатия
Мастер-секрет48-байтный секрет, разделяемый обоими участниками соединения
Случайное число клиента32-байтное значение, создаваемое клиентом
Случайное число сервера32-байтное значение, создаваемое сервером
Алгоритм МАСМАС-секрет
Последовательный номерКаждое состояние соединения содержит последовательный номер, который вычисляется независимо для состояний чтения и записи. Последовательный номер должен устанавливаться в ноль всякий раз, когда состояние соединения становится активным, т.е. текущим или ожидаемым. Последовательные номера не могут быть больше 264 - 1. Последовательный номер возрастает после каждой записи
Уровень Записи

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

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

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

Компрессия и декомпрессия

Все записи сжимаются с использованием алгоритма сжатия, определенного в текущем состоянии сессии. Первоначально он определяется как CompressionMethod.null. Алгоритм сжатия преобразует TLSPlaintext-структуру в TLSCompressed-структуру.

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

struct {
    ContentType type; 
    /* same as TLSPlaintext.type */
    
    ProtocolVersion version;
    /* same as TLSPlaintext.version */
    
    uint16 length;
    opaque fragment[TLSCompressed.length];
} TLSCompressed;

length – длина (в байтах) следующего TLSCompressed.fragment.

fragment – сжатая форма TLSPlaintext.fragment.

Защита полезной информации записи

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

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

МАС выполняется перед шифрованием. Потоковый шифратор шифрует весь блок, включая МАС. Если CipherSuite есть TLS_NULL_WITH_NULL_NULL, то шифрование состоит из тождественной операции, т.е. данные не шифруются и МАС не используется. TLSCiphertext.length есть сумма TLSCompressed.length и CipherSpec.hash_size.

Для блочных алгоритмов функции шифрования и МАС преобразуют TLSCompressed.fragment-структуру из блоков TLSCiphertext.fragment-структур.

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

Рассмотрим пример: если длина содержимого (TLSCompressed.length) равна 62 байтам и длина МАС равна 20 байтам, то длина перед добавлением равна 82 байтам. Таким образом, если длина блока равна 8 байтам, то длина добавления должна быть равна 6, чтобы общая длина была кратна 8. Длина добавления может быть 6, 14, 22 и т.д. до 254. Если добавление было сделано минимально необходимым, то добавляется 6 байтов, каждый из которых содержит значение 6.

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

Вычисление ключей

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

Из мастер-секрета с использованием хэш-функций создается последовательность байтов, которая представляет собой МАС-секреты, ключи и инициализационные вектора: client write MAC secret, server write MAC secret, client write key, server write key, client write IV и server write 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 сбрасывается.

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

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_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 не влияет.

Протокол Рукопожатия TLS

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

В результате выполнения протокола Рукопожатия будут созданы элементы сессии показанные в таблице 21.3.

Протокол изменения шифрования

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

Таблица 21.3. Создаваемые элементы сессии
Идентификатор сессииПроизвольная последовательность байтов, выбираемая сервером для идентификации активного или возобновляемого состояния сессии
Сертификат участникаХ.509 v3 сертификат участника. Этот элемент может быть нулевым
Метод сжатияАлгоритм, используемый для сжатия данных перед шифрованием
Набор алгоритмовАлгоритм симметричного шифрования данных (такой как null, DES и т.д.), МАС-алгоритм (такой как MD5 или SHA) и различные криптографические атрибуты, такие как hash_size
Мастер-секрет48-байтный секрет, разделямый клиентом и сервером
ВозобновляемоФлаг, определяющий, может ли данная сессия использоваться для создания нового соединения

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

Alert протокол

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

Сообщения закрытия

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

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

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

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

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

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

Alerts ошибок

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

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

Таблица 21.4. Типы Alert ошибок
Unexpected_message Получено неожидаемое сообщение. Этот Alert всегда фатальный и никогда не должен возникать во взаимодействии корректных реализаций
Bad_record_mac Данный Alert возвращается, если полученная запись имеет некорректный МАС. Данное сообщение всегда фатально
Decryption_failed TLSCiphertext дешифрован недопустимым способом: некратная длина блока или недопустимые добавленные значения. Данное сообщение всегда фатально
Record_overflow Полученная TLSCiphertext запись имеет длину больше 214 + 2048 байт, или дешифрованная TLSCompressed запись имеет длину больше 214 + 1024 байт. Данное сообщение всегда фатально
Decompression_failure Функция декомпрессии получила неправильные входные данные. Данное сообщение всегда фатально
Handshake_failure Получение сообщения handshake_failure Alert говорит о том, что отправитель не смог договориться о приемлемом наборе параметров безопасности. Данное сообщение всегда фатально
Bad_certificate Сертификат испорчен, например содержит некорректную подпись
Unsupported_certificate Сертификат неподдерживаемого типа
Certificate_revoked Сертификат отменен тем, кто его подписал
Certificate_expird Срок действия сертификата истек и в настоящее время он недействителен
Certificate_unknown Другой результат (неопределенный), полученный в результате обработки сертификата, сертификат не принимается
Illegal_parameter Некоторое поле находится вне диапазона или не согласуется с другими полями. Данное сообщение всегда фатально
Unknown_ca Получена цепочка законных сертификатов или некоторая часть цепочки, но сертификат не принимается, потому что сертификат СА не соответствует известному СА, с которым установлены доверительные отношения. Данное сообщение всегда фатально
Access_denied Получен законный сертификат, но при применении контроля доступа отправитель решил не продолжать переговоры. Данное сообщение всегда фатально
Decode_error Сообщение не может быть декодировано, потому что некоторое поле находится вне специфицированного диапазона или некорректна длина сообщения. Данное сообщение всегда фатально
Decrypt_error Не выполнена криптогафическая операция Рукопожатия, которая включает проверку подписи, дешифрование обмена ключа и проверку правильности завершающего сообщения
Export_restriction Переговоры не выполнены из-за экспортных ограничений; например, попытка передать 1024-битный ключ RSA для метода Рукопожатия RSA_EXPORT. Данное сообщение всегда фатально
Protocol_version Версия протокола, с которой клиент пытается вести переговоры, распознана, но не поддерживается. Например, старая версия протокола не должна использоваться по причинам безопасности. Данное сообщение всегда фатально
Insufficient_security Возвращается вместо handshake_failure, когда переговоры прекращаются из-за того, что сервер требует более безопасных алгоритмов, чем предложены клиентом. Данное сообщение всегда фатально
Internal_error Внутренняя ошибка, не относящаяся к участникам, но делающая невозможным дальнейшее ведение переговоров (например, невозможность распределения памяти). Данное сообщение всегда фатально
User_canceled Данное Рукопожатие прервано по некоторой причине, не относящейся к падению протокола. Если пользователь прервал операцию после завершения Рукопожатия, то для закрытия соединения больше подходит сообщение close_notify. Данное сообщение обычно является предупреждающим
No_renegotiation Посылается клиентом в ответ на запрос Hello или сервером в ответ на Hello клиента после начала Рукопожатия. Это приводит к невозможности вести новые переговоры; в этой точке тот, кто осуществил первоначальный запрос, может решить продолжать ли использовать данное соеди нение. Одним из случаев, который может соответствовать данной ситуации, может быть порождение сервером нового процесса для удовлетворения запроса; процесс должен при старте получить параметры безопасности (длину ключа, аутентификацию и т.д.), и возможности внести изменения в параметры после этой точки быть не должно. Данное сообщение всегда является предупреждающим
Обзор протокола Рукопожатия

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

Протокол Рукопожатия включает следующие шаги:

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

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

Данные цели достигаются протоколом Рукопожатия, который можно просуммировать следующим образом. Клиент посылает сообщение Client Hello, на которое сервер должен ответить сообщением Server Hello или фатальной ошибкой и прерыванием соединения. Client Hello и Server Hello используются для определения максимального уровня безопасности между клиентом и сервером. Client Hello и Server Hello устанавливают следующие атрибуты: Protocol Version, Session ID, Cipher Suite и Compression Method. Дополнительно создаются и передаются два случайных значения: ClientHello.random и ServerHello.random.

Аутентификация и обмен общим секретом осуществляются в четырех сообщениях: сертификат сервера, обмен ключа сервера, сертификат клиента и обмен ключа клиента. Общий секрет должен быть достаточно большим; текущие методы распределения ключа обмениваются секретами, длина которых находится в диапазоне от 48 до 126 байт.

После сообщений Hello сервер посылает сертификат для аутентификации. Дополнительно может быть послано сообщение обмена ключа сервера, если сервер не имеет сертификата или его сертификат служит только для подписи. Если сервер аутентифицирован, он может запросить сертификат клиента, если того требует установленная политика безопасности. Теперь сервер посылает сообщение Server Hello Done, указывающее на то, что фаза Hello-сообщений Рукопожатия завершена. Затем сервер ждет ответа клиента. Если сервер послал сообщение запроса сертификата, клиент должен послать сообщение Certificate. После этого посылается сообщение обмена ключа клиента, содержимое этого сообщения зависит от выбранного алгоритма открытого ключа в сообщениях Client Hello и Server Hello. Если клиент имеет сертификат для подписывания, то посылается сообщение цифровой подписи для явной проверки всех сообщений Рукопожатия.

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

Замечание: для того чтобы избежать остановок, ChangeCipherSpec реализован как независимый тип протокола и частью протокола Рукопожатия фактически не является.

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

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

Поток сообщений при сокращенном Рукопожатии

Рассмотрим в деталях каждое сообщение протокола Рукопожатия.

Последовательность сообщений при полном Рукопожатии

Клиент Сервер
ClientHello
ServerHello
Certificate *
ServerKeyExchange *
CertificateRequest *
ServerHelloDone
Certificate *
ClientKeyExchange
CertificateVerify *
[ ChangeCipherSpec ]
Finished
[ChangeCipherSpec ]
Finished
Прикладные данныеПрикладные данные
* указывает на необязательные или зависящие от ситуации сообщения, которые посылаются не всегда.

Протокол Рукопожатия

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

Сообщения протокола Рукопожатия представлены ниже в том порядке, в котором они должны посылаться. При нарушении данного порядка возникает фатальная ошибка. Тем не менее необязательные сообщения Рукопожатия можно опустить. Из этого правила существует одно исключение: сообщение Cеrtificate используется дважды при Рукопожатии (от сервера к клиенту, затем от клиента к серверу), но описано оно только один раз. Единственным сообщением, которое не связано данными правилами упорядоченности, является сообщение Hello Request. Оно может быть послано в любое время, но должно игнорироваться клиентом, если поступает в середине Рукопожатия.

Клиент Сервер
ClientHello
ServerHello
[ ChangeCipherSpec ]
Finished
[ ChangeCipherSpec ]
Finished
Прикладные данныеПрикладные данные
Сообщения Hello

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

Hello Request

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

Hello Request является просто уведомлением о том, что клиент должен начать процесс переговоров заново посылкой сообщения Hello. Данное сообщение будет игнорироваться клиентом, если он находится в состоянии переговоров. Данное сообщение может игнорироваться клиентом, если он не хочет вести новые переговоры, при этом клиент может ответить no_renegotiation Alert. Если сервер посылает Hello Request, но не получает в ответ Client Hello, он может закрыть соединение с фатальным Alert.

После посылки Hello Request сервер не должен повторять запрос до тех пор, пока последующие переговоры Рукопожатия не будут завершены.

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

Client Hello

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

Сообщение Client Hello содержит случайные числа, которые используются при создании мастер-секрета.

Сообщение Client Hello может включать идентификатор сессии. Его значение определяет сессию между теми же клиентом и сервером, чьи параметры безопасности клиент хочет использовать. Идентификатор сессии может быть получен из ранее установленного соединения или другого текущего активного соединения. Это дает возможность установить несколько независимых безопасных соединений без повторения полного протокола Рукопожатия. Эти независимые соединения могут существовать как последовательно, так и одновременно. SessionID может использоваться после того, как протокол Рукопожатия завершится обменом Finished-сообщениями и сохраняется до тех пор, пока не будет удален или не произойдет фатальная ошибка в соединении, связанном с данной сессией.

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

Список CipherSuite, передаваемый от клиента серверу в сообщении Client Hello, содержит комбинации криптографических алгоритмов, поддерживаемых клиентом, упорядоченные согласно предпочтениям клиента. Каждый CipherSuite определяет алгоритм обмена ключа, алгоритм основного шифрования (включая длину секретного ключа) и алгоритм МАС. Сервер будет выбирать набор шифрования или, если приемлемый выбор невозможен, возвратит Alert падения Рукопожатия и закроет соединение.

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

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

Замечание о совместимости: в интересах совместимости с последующими реализациями допускается в сообщение Client Hello включать внешние данные после методов сжатия. Эти данные должны быть включены в вычисление хэшей Рукопожатия, но в других отношениях они должны игнорироваться. Это возможно только для сообщения Рукопожатия; для всех других сообщений количество данных в сообщении должно точно соответствовать описанию сообщения.

Server Hello

Сервер посылает данное сообщение в ответ на сообщение Client Hello, для того чтобы выбрать конкретный набор алгоритмов. Если он не может сделать такой выбор, он отвечает handshake failure Alert.

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

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

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

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

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

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

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

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

Данное сообщение посылается непосредственно после сообщения Server Certificate (или сообщения Server Hello, если переговоры анонимные).

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

  • RSA_EXPORT (если открытый ключ в сертификате сервера длиннее 512 бит)
  • DH_DSS
  • DH_RSA
  • DH_anon

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

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

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

Неанонимный сервер может дополнительно запросить сертификат клиента, если это соответствует политике безопасности сервера. Это сообщение, если оно послано, должно следовать сразу же за сообщением Server Key Exchange, если оно послано; в противном случае – за сообщением Server Certificate.

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

Server Hello Done

Сообщение Server Hello Done посылается сервером для обозначения окончания фазы Server Hello и связанных с ней сообщений. После посылки данного сообщения сервер ждет ответа клиента.

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

Таблица 21.5. Возможные алгоритмы обмена ключа и типа сертификата
Алгоритм обмена ключаТип ключа сертификата
RSAОткрытый ключ RSA; сертификат должен позволять задействовать ключ для шифрования
RSA_EXPORTУчтены экспортные ограничения, т.е. открытый ключ RSA длиной больше 512 бит может использоваться для подписывания, ключ 512 бит и короче может использоваться как для подписи, так и для шифрования. В первом случае следущим сообщением должно быть ServerKeyExchange, в котором этим ключом будут подписаны открытые ключи Диффи-Хеллмана или другой открытый ключ RSA
DH_DSSОткрытый ключ DSS. Обмен ключа осуществляется по алгоритму Диффи-Хеллмана
DH_RSAОткрытый ключ RSA, который может использоваться для подписывания. Обмен ключа осуществляется по алгоритму Диффи-Хеллмана

При получении сообщения Server Hello Done клиент должен убедиться, что сервер предоставил законный сертификат и что Hello параметры сервера приемлемы для клиента.

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

Это первое сообщение, которое клиент посылает после получения сообщения Server Hello Done. Оно посылается только в том случае, если сервер требует сертификат. Если подходящий сертификат недоступен, клиент должен послать сообщение Certificate, не содержащее сертификатов. Если сервер требует аутентификации клиента для продолжения Рукопожатия, он может ответить фатальным handshake failure Alert. Структура сертификатов клиента такая же, как и сервера.

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

Сообщение Client Key Exchange

Данное сообщение посылается клиентом всегда. Оно следует сразу за сообщением Client Certificate, если таковое посылается. В противном случае это первое сообщение, посланное клиентом после получения сообщения Server Hello Done.

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

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

Если для согласования общего секрета и аутентификации используется RSA, клиент создает 48-байтный премастер-секрет, шифрует его с использованием открытого ключа из сертификата сервера или временного ключа RSA, полученного в сообщении Server Key Exchange.

Проверка целостности с помощью сертификата клиента

Данное сообщение используется для обеспечения явной проверки целостности сообщений Рукопожатия с помощью сертификата клиента. Оно посылается только в том случае, если сертификат клиента имеет возможность подписывания (т.е. все сертификаты, за исключением тех, которые используют алгоритм Диффи-Хеллмана). Если оно посылается, то должно следовать непосредственно за сообщением Client Key Exchange.

Здесь handshake_messages означает все сообщения Рукопожатия, посланные или полученные во время Рукопожатия, начиная с Client Hello, но не включая данное сообщение. ВклК началу статьи





Добавил: MadvEXДата публикации: 2006-02-19 00:23:28
Рейтинг статьи:3.00 [Голосов 5]Кол-во просмотров: 8791

Комментарии читателей

Всего комментариев: 20

2018-04-07 00:53:48
KennethSoymn
ВСЕГО ОДНА КАПСУЛА В ДЕНЬ
и ты будешь заниматься сексом ежедневно по 2-3 часа!
В любом возрасте и без побочных эффектов

ОСТАЛОСЬ: 14 УПАКОВОК

Гарантирует мощную, устойчивую эрекцию в любом возрасте
Продлевает половой акт до 2-х часов
В 3 раза увеличивает количество спермы при эякуляции
Продлевает твой оргазм на 15-20 секунд

Сайт: https://eroctive2.blogspot.ru/

2018-03-16 07:44:54
KennethSoymn
Pozitiv - это негормональный препарат, который помогает вашему организму выработать серотонин и мелатонин, которых так не хватает для радости!
Сайт: http://doctorslivedigest.com/I4jQy/

2018-03-15 05:19:47
KennethSoymn
Pozitiv - это негормональный препарат, который помогает вашему организму выработать серотонин и мелатонин, которых так не хватает для радости!
Сайт: http://doctorslivedigest.com/I4jQy/

2018-03-14 02:45:28
KennethSoymn
Pozitiv - это негормональный препарат, который помогает вашему организму выработать серотонин и мелатонин, которых так не хватает для радости!
Сайт: http://doctorslivedigest.com/I4jQy/

2018-03-13 03:59:32
KennethSoymn
Pozitiv - это негормональный препарат, который помогает вашему организму выработать серотонин и мелатонин, которых так не хватает для радости!
Сайт: http://doctorslivedigest.com/I4jQy/

2018-03-12 04:26:41
CraigWrard
Приобрести можно на веб-сайте http://mang.bestseller-super.ru

Рады предложить нашим клиентам чудодейственное средство для снижения веса Mangoosteen. С его помощью реально избавиться от 10 килограмм за недели. Растение гарциния растет на Шри-Ланке. Плоды этого растения имеют замечательные особенности. В баночке имеется около 20 плодов данного удивительного растения. Плоды с растения мангостан помогают убрать лишнюю липидную ткань. И также отлично влияют на организм в комплексе. Технология изготовления препарата, и уникальная упаковка помогают сберечь все полезные свойства плодов. Основным действующим веществом сиропа Мангустина являются плоды с дерева гарциния, в них содержится большое число питательных элементов. Благодаря компоненту ксантону, которое в громадных дозах имеется в плоде, сильно замедляются процессы окисления в организме. Ксантон считается одним из наиболее мощных антиокислителей. В плоде растения мангостан также имеются различные группы витаминов и микроэлементы. Купить сироп Мансустина можно на интернет-сайте http://corta.co/cDb

2018-03-11 21:35:42
KennethSoymn
Pozitiv - это негормональный препарат, который помогает вашему организму выработать серотонин и мелатонин, которых так не хватает для радости!
Сайт: http://doctorslivedigest.com/I4jQy/

2018-01-05 15:07:51
Rosariocex
заказать поисковое продвижение сайта логин в скайпе SEO PRO1

2018-01-05 11:33:06
Glenntaush
заказать продвижение сайта по лидам логин в скайпе SEO PRO1

2017-01-20 15:21:12
Herbertreone
Доброго времени суток!

Только для Вас у нас <b>VIP аккаунты:</b>

<a href=https://goo.gl/nCbstX>WARFACE ДО 45 РАНГИ</a>

<a href=https://goo.gl/LX22aF>MINECRAFT PREMIUM (ДОСТУП В КЛИЕНТ) ЛИЦЕНЗИЯ</a>

<a href=https://goo.gl/YHb1d9>WOT ДО 2000 БОЁВ | БЕЗ ПРИВЯЗКИ</a>

<a href=https://goo.gl/UIMytQ>BATTLEFIELD 4 ORIGIN</a>

<a href=https://goo.gl/p254Im>STEAM СТИМ 5 ИГР ЗА 99 РУБЛЕЙ. УСПЕЙ КУПИТЬ</a>

<a href=https://goo.gl/3Ku7wv>BATTLEFIELD 1 ORIGIN и ПОДАРОК</a>

<a href=https://goo.gl/FLnRhQ>WARFACE RANDOM ОТ 11 ДО 80 РАНГА </a>

<a href=https://goo.gl/0TPpmI>STAR WARS BATTLEFRONT ORIGIN и СЕКРЕТКА</a>

<a href=https://goo.gl/1WtPA2>АККАУНТ WAR THUNDER ОТ 20 ДО 50 УРОВНЯ</a>

<a href=https://goo.gl/eg3jGd>WOT СЛУЧАЙНЫЙ АККАУНТ ОТ 250 ДО 1000 БОЕВ</a>

<a href=https://goo.gl/uZjgNv>THE SIMS 3 ORIGIN и ПОДАРОК</a>

<a href=https://goo.gl/z2nb3J>WARFACE VIP ОТ 21 ДО ЛЬВА</a>

<a href=https://goo.gl/zMtniX>BATTLEFIELD 3 ORIGIN</a>

<a href=https://goo.gl/yQGt6F>ЗОЛОТОЙ КЛЮЧ STEAM 150</a>

<a href=https://goo.gl/GMHuQ7>WARFACE 1-30 РАНГИ АЛЬФА</a>

<a href=https://goo.gl/XIfKdz>FIFA 16 ORIGIN</a>

<a href=https://goo.gl/ePt2mV>BATTLEFIELD 4 ИГРОВОЙ АККАУНТ</a>

<a href=https://goo.gl/VYsjpX>WORLD OF TANKS WOT ОТ 3000 БОЁВ 8 ЛВЛ</a>

<a href=https://goo.gl/fYjf0B>POKEMON GO АККАУНТ ОТ 5 ДО 40 УРОВНЯ</a>

<a href=https://goo.gl/wfdVfM>DEAD SPACE 3 ПОДАРОК БОНУС СКИДКА</a>

<a href=https://goo.gl/mcLQnw>NFS NEED FOR SPEED HOT PURSUIT 2010 ORIGIN</a>

<a href=https://goo.gl/7FUQCf>PLANTS VS. ZOMBIES GARDEN WARFARE ORIGIN и ПОДАРОК</a>

<a href=https://goo.gl/ZYQIqf>FIFA 17 ORIGIN и ПОДАРОК</a>

<a href=https://goo.gl/UNgBlW>MEDAL OF HONOR: WARFIGHTER ORIGIN АККАУНТ и ПОДАРОК</a>

<a href=https://goo.gl/yKQEZ7>FIFA 16 ORIGIN и СЕКРЕТКА</a>

<a href=https://goo.gl/Yv8poi>MASS EFFECT 3 N7 DIGITAL DELUXE EDITION</a>

<a href=https://goo.gl/P0nQFB>STAR WARS BATTLEFRONT DELUXE ORIGIN и ПОДАРОК</a>

<a href=https://goo.gl/FGJqXH>CS 1.6 | COUNTER-STRIKE 1.6 STEAM и ПОДАРОК</a>

<a href=https://goo.gl/L2y9Xx>DOTA 2 ОТ 10 ДО 100 ИГРОВЫХ ЧАСОВ ПОДАРОК БОНУС</a>

<a href=https://goo.gl/vHo3Qk>WARFACE ОТ СПЕЦИАЛИСТА ДО ГЕНЕРАЛА ПОЧТА ПОДАРОК</a>

<b>Все сделки защищены площадкой плати точка ру, гарантия качества, гарантия возврата, если что-то не устроит, автоматическое, моментальное получение аккаунтов</b>
Ваше имя: *
Текст записи: *
Имя:

Пароль:



Регистрация

Как вы относитесь к AJAX?
Считаю это ЗЛОМ
11% (12)
Бесполезная технология
2% (2)
Мне параллельно
9% (10)
Неплохая технология
20% (23)
Рулез, как я без нее жил!
7% (8)
Я разработчик AJAX-приложений
5% (6)
А что? Хороший футбольный клуб!
12% (14)
Я в танке!!!
34% (38)

Проголосовало: 113
- Миколо, ты що свою домашню строныцю на домен "ru" засувов?
- А шо?
- Так то ж "Раша"!
- От, гады! А я думав, Ридно Украина!
Рейтинг: 7/10 (3)
Посмотреть все анекдоты