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

2. HTTPS - расширение протокола HTTP

HTTPS — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP порт 443. Эта система была разработана компанией Netscape Communications Corporation, чтобы обеспечть аутентификацию и защищенное соединение. HTTPS широко используется в мире Веб для приложений, в которых важна безопасность соединения, например, в платежных системах.

В настоящее время HTTPS поддерживается наиболее популярными браузерами.

2.1. Механизм работы протокола HTTPS

Строго говоря, https не явлется отдельным протоколом. По сути это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Это обеспечивает защиту от атак, основанных на фальсификации либо прослушивании среднего уровня сетевого соединения - т.н. man-in-the-middle (например, от снифферских атак).

По умолчанию https: URL использует 443 TCP-порт (для незащищенного HTTP — 80). Чтобы подготовить веб-сервер для обработки https соединений, администратор должен создать публичный ключ сертификата для этого веб-сервера. Такие сертификаты могут быть созданы для серверов, работающих под Unix, с помощью таких утилит, как ssl-ca от OpenSSL или gensslcert от SuSE. Сертификат должен быть подписан уполномоченной стороной (Certificate authority), которая гарантирует, что держатель сертификата является тем, за кого себя выдает. Веб-браузеры обычно распространяются с подписями основных сертификационных организаций, поэтому они могут проверить сертификаты, выданные этими организациями.

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

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

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

В HTTPS используется длина ключа всего 40, 56, или 128 бит. По мнению большинства специалистов по информационной безопасности, сегодня надежной длиной ключа может быть длина, сравнимая с 1024 бит. Поэтому длина ключа даже в максимальные 128 бит HTTPS явно недостаточна. Кроме того, большинство браузеров использует длину ключа 40 бит(пример тому — IE). Это связано с экспортными ограничениями в США. И, следовательно, не следует считать, что HTTPS обеспечивает достойный уровень шифрования. Но такое шифрование значительно затрудняет злоумышленнику поиск паролей и другой личной информации.

2.2. Протокол SSL

Протокол SSL спроектирован для обеспечения конфиденциальности обмена между двумя прикладными процессами клиента и сервера. Он предоставляет возможность аутентификации сервера и, опционно, клиента. SSL требует применения надежного транспортного протокола (например, TCP).

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

Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства:

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

- Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская - аутентифицируется опционно.

- Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).

2.2.1. Спецификация протокола записей

2.2.1.1. Формат заголовка записи SSL

В SSL все данные пересылаются в виде рекордов (записей), объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель и полная длина заголовка равна 3 байтам. Передача всегда начинается с заголовка.

Заметим, что в случае длинного заголовка (3 байта), второй по старшинству бит первого байта имеет специальное значение. Когда он равен нулю, посылаемый рекорд является информационным. При равенстве 1, посылаемый рекорд является security escape (в настоящее время не определено ни одного значения security escapes; это зарезервировано для будущих версий протокола).

Код длины рекорда не включает в себя число байт заголовка (2 или 3). Для 2-байтового заголовка его длина вычисляется следующим образом (используется Си-подобная нотация):

RECORLENGTH = ((byte[0] & 0x7F << 8)) | byte[1];

Где byte[0] представляет собой первый полученный байт, а byte[1] - второй полученный байт. Когда используется 3-байтовый заголовок, длина рекорда вычисляется следующим образом:

RECORD-LENGTH = ((byte[0] & 0x3F) << 8)) | byte[1];

IS-ESCAPE = (byte[0] & 0x40) != 0;

PADDING = byte[2];

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

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

Получатель этого рекорда дешифрует все поле данных и получает исходную информацию. После этого производится вычисление истинного значения RECORD-LENGTH (с учетом наличия опционного PADDING), при этом заполнитель из поля данных удаляется.

2.2.1.2. Формат информационных записей SSL

Часть данных рекорда SSL состоит из трех компонентов (передаваемых и получаемых в приведенном ниже порядке):

MAC-DATA[MAC-SIZE]

ACTUAL-DATA[N]

PADDING-DATA[PADDING]

ACTUAL-DATA представляет собой реальные переданные данные (поле данных сообщения). PADDING-DATA - это данные заполнителя, посылаемые когда используется блочный код шифрования. MAC-DATA является кодом аутентификации сообщения (Message Authentication Code).

Когда рекорды SSL посылаются открытым текстом, никаких шифров не используется. Следовательно, длина PADDING-DATA будет равна нулю и объем MAC-DATA также будет нулевым. Когда используется шифрование, PADDING-DATA является функцией размера блока шифра. MAC-DATA зависит от CIPHER-CHOICE. MAC-DATA вычисляется следующим образом:

MAC-DATA = HASH[SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER]

Где SECRET передается хэш-функции первым, далее следует ACTUAL-DATA и PADDING-DATA, за которыми передается SEQUENCE-NUMBER. Порядковый номер (SEQUENCE-NUMBER) представляет собой 32-битовый код, который передается хэш-функции в виде 4 байт. Первым передается старший байт (т.е. используется сетевой порядок передачи - "big endian").

MAC-SIZE является функцией используемого алгоритма вычисления дайджеста. Для MD2 и MD5 MAC-SIZE равен 16 байтам (128 битам).

Значение SECRET зависит оттого, кто из партнеров посылает сообщение. Если сообщение посылается клиентом, тогда SECRET равен CLIENT-WRITE-KEY (сервер будет использовать SERVER-READ-KEY для верификации MAC). Если клиент получает сообщение, SECRET равен CLIENT-READ-KEY (сервер будет использовать SERVER-WRITE-KEY для генерации MAC).

SEQUENCE-NUMBER является счетчиком, который инкрементируется как сервером, так и получателем. Для каждого направления передачи, используется пара счетчиков (один для отправителя, другой для получателя). При отправлении сообщения счетчик инкрементируется. Порядковыми номерами являются 32-битовые целые числа без знака, которые при переполнении обнуляются.

Получатель сообщения использует ожидаемое значение порядкового номера для передачи хэш-функции MAC (тип хэш-функции определяется параметром CIPHER-CHOICE). Вычисленная MAC-DATA должна совпадать с переданной MAC-DATA. Если сравнение не прошло, рекорд считается поврежденным, такая ситуация рассматривается как случай "I/O Error" (т.e. как непоправимая ошибка, которая вызывает закрытие соединения).

Окончательная проверка соответствия выполняется, когда используется блочный шифр и соответствующий протокол шифрования. Объем данных в рекорде (RECORD-LENGTH) должен быть кратным размеру блока шифра. Если полученный рекорд не кратен размеру блока шифра, рекорд считается поврежденным, при этом считается, что имела место "I/O Error" (что вызовет разрыв соединения).

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

Для двухбайтового заголовка, максимальная длина рекорда равна 32767 байтов. Для трехбайтового заголовка, максимальная длина рекорда равна 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL (Record Protocol). Сообщения прикладного протокола могут занимать несколько рекордов SSL.

Прежде чем послать первый рекорд SSL все порядковые номера делаются равными нулю. При передаче сообщения порядковый номер инкрементируется, начиная с сообщений CLIENT-HELLO и SERVER-HELLO.

2.2.2. Спецификация протокола диалога SSL

2.2.2.1. Протокол диалога SSL

Протокол диалога SSL имеет две основные фазы. Первая фаза используется для установления конфиденциального канала коммуникаций. Вторая - служит для аутентификации клиента.

Фаза 1

Первая фаза является фазой инициализации соединения, когда оба партнера посылают сообщения "hello". Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер получает сообщение CLIENT-HELLO, обрабатывает его и откликается сообщением SERVER-HELLO.

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

Когда нужен новый мастерный ключ, сообщение SERVER-HELLO будет содержать достаточно данных, чтобы клиент мог сформировать такой ключ. Сюда входит подписанный сертификат сервера, список базовых шифров (см. ниже), и идентификатор соединения (последний представляет собой случайное число, сформированное сервером и используемое на протяжении сессии). Клиент генерирует мастерный ключ и посылает сообщение CLIENT-MASTER-KEY (или сообщение ERROR, если информация сервера указывает, что клиент и сервер не могут согласовать базовый шифр).

Здесь следует заметить, что каждая оконечная точка SSL использует пару шифров для каждого соединения (т.е. всего 4 шифра). На каждой конечной точке, один шифр используется для исходящих коммуникаций и один - для входящих. Когда клиент или сервер генерирует ключ сессии, они в действительности формируют два ключа, SERVER-READ-KEY (известный также как CLIENT-WRITE-KEY) и SERVER-WRITE-KEY (известный также как CLIENT-READ-KEY). Мастерный ключ используется клиентом и сервером для генерации различных ключей сессий.

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

Фаза 2

Вторая фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь осуществляется аутентификация клиента. При типичном сценарии, серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Эта спецификация протокола не определяет семантику сообщения ERROR, посылаемого в ответ на запрос сервера (например, конкретная реализация может игнорировать ошибку, закрыть соединение, и т.д. и, тем не менее, соответствовать данной спецификации). Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация терпит неудачу, сервер посылает сообщение ERROR.

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

2.2.2.2. Типовой протокол обмена сообщениями

В несколько упрощенном варианте диалог SSL представлен на рис. 6.5.1.

Рис. 1. Алгоритм работы SSL

Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. В этих примерах представлены два участника диалога: клиент (С) и сервер (S). Если что-то помещено в фигурные скобки, например, "{нечто}key", это означает, что "нечто" зашифровано с помощью ключа "key".

2.2.2.2.1. При отсутствии идентификатора сессии

Client-hello	C ® S:	challenge, cipher_specs
server-hello	S ® C:	connection-id, server_certificate, cipher_specs
client-master-key	C ® S:	{master_key}server_public_key
client-finish	C ® S:	{connection-id}client_write_key
server-verify	S ® C:	{challenge}server_write_key
server-finish	S ® C:	{new_session_id}server_write_key

2.2.2.2.2. Использован идентификатор сессии и аутентификация клиента

сlient-hello	C ® S:	challenge, session_id, cipher_specs
server-hello	S ® C:	connection-id, session_id_hit
client-finish	C ® S:	{connection-id}client_write_key
server-verify	S ® C:	{challenge}server_write_key
request-certificate	C ® S:	{auth_type,challenge'}server_write_key
client-certificate	S ® C:	{cert_type,client_cert, response_data}client_write_key
server-finish	S ® C:	{session_id}server_write_key

2.2.3. Ошибки

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

- NO-CIPHER-ERROR

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

- NO-CERTIFICATE-ERROR

Когда послано сообщение REQUEST-CERTIFICATE, эта ошибка может быть прислана, если клиент не имеет сертификата. Эта ошибка устранима.

- BAD-CERTIFICATE-ERROR

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

- UNSUPPORTED-CERTIFICATE-TYPE-ERROR

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

2.2.4. Протокольные сообщения клиента

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

CLIENT-HELLO (Фаза 1; посылается открыто)

char MSG-CLIENT-HELLO

char CLIENT-VERSION-MSB

char CLIENT-VERSION-LSB

char CIPHER-SPECS-LENGTH-MSB

char CIPHER-SPECS-LENGTH-LSB

char SESSION-ID-LENGTH-MSB

char SESSION-ID-LENGTH-LSB

char CHALLENGE-LENGTH-MSB

char CHALLENGE-LENGTH-LSB

char CIPHER-SPECS-DATA[(MSB<<8)|LSB]

char SESSION-ID-DATA[(MSB<<8)|LSB]

char CHALLENGE-DATA[(MSB<<8)|LSB]

Когда клиент впервые подключается к серверу, он должен послать сообщение CLIENT-HELLO. Сервер ожидает это сообщение от клиента первым. Любое другое сообщение от клиента в данных обстоятельствах рассматривается как ошибка.

Клиент посылает серверу свою версию SSL, спецификацию шифров, некоторые данные вызова (challenge data) и данные идентификатора сессии. Данные идентификатора сессии посылаются клиентом только в том случае, когда в его кэше имеется идентификатор сессии, а значение SESSION-ID-LENGTH не равно нулю. Когда идентификатора сессии нет, то значение SESSION-ID-LENGTH должно быть равно нулю. Данные вызова используются для аутентификации сервера. После того как клиент и сервер согласовали пару ключей сессии, сервер присылает сообщение SERVER-VERIFY с зашифрованной формой CHALLENGE-DATA.

Заметим также, что сервер не пошлет сообщения SERVER-HELLO пока не получит сообщения CLIENT-HELLO. Это делается так, чтобы сервер мог в первом сообщении клиенту определить состояние идентификатора сессии клиента (т.e. улучшить эффективность протокола и уменьшить объем обменов).

Сервер рассматривает сообщение CLIENT-HELLO и проверяет, поддерживает ли он версию программы клиента и хотя бы одну позицию в спецификации шифров клиента. Сервер может опционно отредактировать спецификацию шифров, удалив записи, которые он решил не поддерживать. Отредактированная версия будет прислана в сообщении SERVER-HELLO, если идентификатор сессии не находится в кэше сервера.

Значение CIPHER-SPECS-LENGTH должно быть больше нуля и кратно 3. Код SESSION-ID-LENGTH должен быть равен нулю или 16. Значение CHALLENGE-LENGTH должно быть больше чем і 16 и Ј 32.

Это сообщение должно быть первым, посланным клиентом серверу. После его посылки клиент ждет сообщения SERVER-HELLO. Любое другое сообщение, присланное сервером (кроме ERROR) не допустимо.

CLIENT-MASTER-KEY (Фаза 1; посылается вначале открыто)

char MSG-CLIENT-MASTER-KEY

char CIPHER-KIND[3]

char CLEAR-KEY-LENGTH-MSB

char CLEAR-KEY-LENGTH-LSB

char ENCRYPTED-KEY-LENGTH-MSB

char ENCRYPTED-KEY-LENGTH-LSB

char KEY-ARG-LENGTH-MSB

char KEY-ARG-LENGTH-LSB

char CLEAR-KEY-DATA[MSB<<8|LSB]

char ENCRYPTED-KEY-DATA[MSB<<8|LSB]

char KEY-ARG-DATA[MSB<<8|LSB]

Клиент посылает это сообщение, когда он определил мастерный ключ для работы с сервером. Заметим, что когда идентификатор сессии согласован, это сообщение не посылается.

Поле CIPHER-KIND указывает, какой шифр выбран из спецификации CIPHER-SPECS сервера.

Данные CLEAR-KEY-DATA содержат открытую часть MASTER-KEY. CLEAR-KEY-DATA комбинируются с SECRET-KEY-DATA, чтобы образовать MASTER-KEY, при этом SECRET-KEY-DATA составляет младшие байты MASTER-KEY. ENCRYPTED-KEY-DATA содержит секретные части MASTER-KEY, зашифрованные с использованием общедоступного ключа сервера. Информационная часть зашифрованного блока имеет следующий формат:

char SECRET-KEY-DATA[SECRET-LENGTH]

SECRET-LENGTH равно числу байт каждого из ключей сессии. SECRET-LENGTH плюс CLEAR-KEY-LENGTH равно числу байт в ключе шифра (как это определено CIPHER-KIND). Если после дешифрования SECRET-LENGTH окажется неравным ожидаемому значению, регистрируется ошибка. Ошибкой считается и ситуация, когда CLEAR-KEY-LENGTH не равно нулю и CIPHER-KIND является не экспортным шифром.

Если алгоритм ключа требует аргумента (например, вектора инициализации DES-CBC), тогда поле KEY-ARG-LENGTH будет ненулевым и KEY-ARG-DATA будет содержать соответствующую информацию. Для алгоритмов SSL_CK_RC2_128_CBC_WITH_MD5, SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5, SSL_CK_IDEA_128_CBC_WITH_MD5, SSL_CK_DES_64_CBC_WITH_MD5 и SSL_CK_DES_192_EDE3_CBC_WITH_MD5 должны присутствовать данные KEY-ARG с длиной 8 байт.

Вычисление ключей сессии клиента и сервера является функцией CIPHER-CHOICE:

SSL_CK_RC4_128_WITH_MD5

SSL_CK_RC4_128_EXPORT40_WITH_MD5

SSL_CK_RC2_128_CBC_WITH_MD5

SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5

SSL_CK_IDEA_128_CBC_WITH_MD5

KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]

KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]

CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]

Где KEY-MATERIAL-0[0-15] означает первые 16 байт данных KEY-MATERIAL-0, с KEY-MATERIAL-0[0], образующим старший байт CLIENT-READ-KEY.

Данные передаются хэш-функции MD5, начиная с MASTER-KEY, далее следует "0" или "1", затем вызов (CHALLENGE) и, наконец, CONNECTION-ID.

Заметим, что "0" означает ASCII символ нуль (0x30), а не значение нуль. "1" означает ASCII символ 1 (0x31). MD5 выдает 128 бит выходных данных, которые используются в качестве ключа алгоритма шифрования (старший байт хэша MD5 становится старшим байтом ключевого материала).

SSL_CK_DES_64_CBC_WITH_MD5

KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]

CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]

Для DES-CBC, 16-байтовый ключевой материал формируется с помощью MD5. Первые 8 байт дайджеста MD5 используются в качестве CLIENT-READ-KEY, в то время как оставшиеся 8 байт используются в качестве CLIENT-WRITE-KEY. Вектор инициализации берется из KEY-ARG-DATA.

SSL_CK_DES_192_EDE3_CBC_WITH_MD5

KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]

KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]

KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]

CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]

CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]

CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]

CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]

CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]

Данные передаются хэш-функции MD5 в указанном порядке, слева направо: первым поступает MASTER-KEY, затем "0", "1" или "2", далее CHALLENGE и, наконец, CONNECTION-ID (идентификатор сессии).

Заметим, что "0" означает ascii символ нуль (0x30), а не код нуль. "1" означает ascii символ 1 (0x31). "2" означает ascii символ 2 (0x32).

Всего генерируется 6 ключей, 3 ключа читающей стороны для шифра DES-EDE3 и 3 - для пишущей стороны для функции DES-EDE3. Вектор инициализации формируется в KEY-ARG-DATA.

Вспомним, что MASTER-KEY передан серверу в сообщении CLIENT-MASTER-KEY. CHALLENGE выдается серверу клиентом в сообщении CLIENT-HELLO. CONNECTION-ID передается клиенту от сервера в сообщении SERVER-HELLO. Это делает получаемые в результате ключи, зависящими от исходной и текущей сессии. Заметим, что мастерный ключ никогда не используется для шифрования данных, и следовательно не может быть легко раскрыт.

Сообщение CLIENT-MASTER-KEY должно быть послано после сообщения CLIENT-HELLO и до сообщения CLIENT-FINISHED. Сообщение CLIENT-MASTER-KEY должно быть послано, если сообщение SERVER-HELLO содержит значение SESSION-ID-HIT равное 0.

CLIENT-CERTIFICATE (Фаза 2; посылается шифрованным)

char MSG-CLIENT-CERTIFICATE

char CERTIFICATE-TYPE

char CERTIFICATE-LENGTH-MSB

char CERTIFICATE-LENGTH-LSB

char RESPONSE-LENGTH-MSB

char RESPONSE-LENGTH-LSB

char CERTIFICATE-DATA[MSB<<8|LSB]

char RESPONSE-DATA[MSB<<8|LSB]

Это сообщение посылается клиентом SSL в ответ на сообщение сервера REQUEST-CERTIFICATE. CERTIFICATE-DATA содержит данные, определенные значением CERTIFICATE-TYPE. Сообщение об ошибке ERROR посылается с кодом NO-CERTIFICATE-ERROR, если данный запрос не может быть обработан корректно (например, получатель сообщения не имеет зарегистрированного сертификата). CERTIFICATE-TYPE является одним из:

SSL_X509_CERTIFICATE

CERTIFICATE-DATA содержит подписанный сертификат X.509 (1988).

RESPONSE-DATA несет в себе аутентификационные данные отклика. Эти данные зависят от значения AUTHENTICATION-TYPE, посланного сервером.

Когда код AUTHENTICATION-TYPE равен SSL_AT_MD5_WITH_RSA_ENCRYPTION, тогда RESPONSE-DATA содержит цифровую подпись следующих компонентов (в указанном порядке):

- KEY-MATERIAL-0

- KEY-MATERIAL-1 (только если определено типом шифра)

- KEY-MATERIAL-2 (только если определено типом шифра)

- CERTIFICATE-CHALLENGE-DATA (из сообщения REQUEST-CERTIFICATE)

- Сертификат, подписанный сервером (из сообщения SERVER-HELLO).

Цифровая подпись формируется с привлечением MD5, полученный хэш шифруется с использованием общедоступного ключа клиента, формат подписи согласуется со стандартом PKCS#1. Сервер аутентифицирует клиента путем верификации его цифровой подписи. Допускается добавление нового типа AUTHENTICATION-TYPE или идентификатора алгоритма цифровой подписи.

Это сообщение должно быть послано клиентом только в ответ на сообщение REQUEST-CERTIFICATE сервера.

CLIENT-FINISHED (Фаза 2; посылается шифрованным)

char MSG-CLIENT-FINISHED

char CONNECTION-ID[N-1]

Клиент посылает это сообщение, после успешной обработки соответствующего сообщения сервера. Заметим, что клиент должен быть готов к приему сообщений от сервера, пока не получит сообщение SERVER-FINISHED. Данные CONNECTION-ID представляют собой исходный идентификатор соединения сервера, посланный в его сообщении SERVER-HELLO и зашифрованный посредством согласованного ключа сессии.

"N" равно числу байт в посланном сообщении, таким образом "N-1" равно числу байт в сообщении за вычетом одного байта заголовка.

Для версии протокола 2, клиент должен посылать это сообщение после получения сообщения SERVER-HELLO. Если в сообщении SERVER-HELLO флаг SESSION-ID-HIT не равен нулю, тогда сообщение CLIENT-FINISHED посылается немедленно, в противном случае сообщение CLIENT-FINISHED посылается после сообщения CLIENT-MASTER-KEY.

2.2.5. Протокольные сообщения сервера

Существует несколько сообщений, которые генерируются только серверами.

SERVER-HELLO (Фаза 1; посылается открыто)

char MSG-SERVER-HELLO

char SESSION-ID-HIT

char CERTIFICATE-TYPE

char SERVER-VERSION-MSB

char SERVER-VERSION-LSB

char CERTIFICATE-LENGTH-MSB

char CERTIFICATE-LENGTH-LSB

char CIPHER-SPECS-LENGTH-MSB

char CIPHER-SPECS-LENGTH-LSB

char CONNECTION-ID-LENGTH-MSB

char CONNECTION-ID-LENGTH-LSB

char CERTIFICATE-DATA[MSB<<8|LSB]

char CIPHER-SPECS-DATA[MSB<<8|LSB]

char CONNECTION-ID-DATA[MSB<<8|LSB]

Сервер посылает это сообщение после получения CLIENT-HELLO. Сервер возвращает флаг SESSION-ID-HIT, указывающий, известен ли серверу полученный идентификатор сессии (т.e. хранится ли он в кэше сервера). Флаг SESSION-ID-HIT будет не равен нулю, если клиент посылает серверу идентификатор сессии (в сообщении CLIENT-HELLO с SESSION-ID-LENGTH != 0), а сервер обнаружит этот идентификатор в своем кэше. Если флаг SESSION-ID-HIT не равен нулю, то поля CERTIFICATE-TYPE, CERTIFICATE-LENGTH и CIPHER-SPECS-LENGTH будут содержать код нуль.

Значение CERTIFICATE-TYPE, если оно не равно нулю, должно содержать одну из перечисленных выше величин (см. информацию о сообщении CLIENT-CERTIFICATE).

Когда флаг SESSION-ID-HIT равен нулю, сервер укладывает свой сертификат, спецификацию шифров и идентификатор соединения и посылает их клиенту. Используя эту информацию, клиент может сформировать ключ сессии и послать его серверу в сообщении CLIENT-MASTER-KEY.

Когда флаг SESSION-ID-HIT не равен нулю, как сервер так и клиент вычисляют новую пару ключей сессии, базируясь на мастерном ключе MASTER-KEY, который они получили при создании идентификатора SESSION-ID. SERVER-READ-KEY и SERVER-WRITE-KEY получаются из исходных ключей MASTER-KEY тем же способом, что CLIENT-READ-KEY и CLIENT-WRITE-KEY:

SERVER-READ-KEY = CLIENT-WRITE-KEY

SERVER-WRITE-KEY = CLIENT-READ-KEY

Заметим, что когда ключи получены и установлен флаг SESSION-ID-HIT, а сервер обнаружил идентификатор сессии клиента в своем кэше, тогда данные KEY-ARG-DATA используются с момента, когда определен идентификатор SESSION-ID. Это делается, потому что клиент не посылает новых данных KEY-ARG-DATA (напомним, что данные KEY-ARG-DATA посланы в сообщении CLIENT-MASTER-KEY).

CONNECTION-ID-DATA представляет собой строку случайных байт, используемых сервером и клиентом в разных местах протокола. Сообщение CLIENT-FINISHED содержит зашифрованную версию CONNECTION-ID-DATA. Длина CONNECTION-ID должна лежать между 16 и 32 байтами, включительно.

CIPHER-SPECS-DATA определяет тип шифра и длину ключа (в битах), которые поддерживает принимающая сторона. Каждая спецификация SESSION-CIPHER-SPEC имеет длину 3 байта и выглядит как:

char CIPHER-KIND-0

char CIPHER-KIND-1

char CIPHER-KIND-2

Где CIPHER-KIND равен одному из:

- SSL_CK_RC4_128_WITH_MD5

- SSL_CK_RC4_128_EXPORT40_WITH_MD5

- SSL_CK_RC2_128_CBC_WITH_MD5

- SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5

- SSL_CK_IDEA_128_CBC_WITH_MD5

- SSL_CK_DES_64_CBC_WITH_MD5

- SSL_CK_DES_192_EDE3_CBC_WITH_MD5

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

Шифр SSL_CK_RC4_128_EXPORT40_WITH_MD5 имеет тип RC4, где некоторые ключи сессии посылаются открыто, а остальные в зашифрованном виде. MD5 используется в качестве хэш-функции для получения MAC и ключей сессии. Этот тип шифра предлагается для поддержки "экспортных" версий (т.e. версий протокола, которые могут быть применены за пределами Соединенных Штатов) клиента или сервера.

Экспортные реализации протокола диалога SSL будут иметь длины секретных ключей не более 40 бит. Для не экспортных реализаций длины ключей могут быть больше (рекомендуется, по крайней мере, 128 бит). Клиенты и серверы могут иметь не перекрывающийся набор поточных шифров. Но это означает, что они не могут общаться.

Версия 2 протокола диалога SSL определяет, что SSL_CK_RC4_128_WITH_MD5 должен иметь длину ключа 128 бит. SSL_CK_RC4_128_EXPORT40_WITH_MD5 также имеет длину ключа 128 бит. Однако только 40 бит являются секретными (другие 88 пересылаются от клиента к серверу открыто).

Сообщение SERVER-HELLO посылается, после того как сервер получит сообщение CLIENT-HELLO, и до того как сервер пошлет SERVER-VERIFY.

SERVER-VERIFY (Фаза 1; посылается шифрованным)

char MSG-SERVER-VERIFY

char CHALLENGE-DATA[N-1]

Сервер посылает это сообщение после пары ключей сессии (SERVER-READ-KEY и SERVER-WRITE-KEY), согласованных посредством идентификатора сессии или явно через спецификацию сообщения CLIENT-MASTER-KEY. Сообщение содержит зашифрованную копию данных CHALLENGE-DATA, посланных клиентом в сообщении CLIENT-HELLO.

"N" равен числу байт в сообщении, которое было послано, таким образом, "N-1" соответствует числу байт в CHALLENGE-DATA за вычетом байта заголовка.

Это сообщение используется для верификации сервера следующим образом. Настоящий сервер имеет секретный ключ, который соответствует общедоступному ключу, содержащемуся в его сертификате, переданном в сообщении SERVER-HELLO. Таким образом, настоящий сервер сможет извлечь и реконструировать пару ключей сессии (SERVER-READ-KEY и SERVER-WRITE-KEY). Наконец, только сервер, который выполнил корректно извлечение и дешифрование может правильно зашифровать CHALLENGE-DATA. Это, по существу, "доказывает", что сервер имеет секретный ключ, который образует пару с открытым ключом из сертификата сервера.

Данные CHALLENGE-DATA должны иметь в точности ту же длину, что и в сообщении клиента CLIENT-HELLO. Их значение должно в точности согласовываться с посланным клиентом открыто в сообщении CLIENT-HELLO. Клиент должен дешифровать это сообщение и сравнить полученный результат с тем, что было послано, и только в случае успешного сравнения сервер считается достойным доверия. Если длины не совпадают или не согласуются значения, клиент соединение разрывает.

Это сообщение должно быть послано сервером клиенту либо после обнаружения идентификатора сессии (при этом посылается отклик SERVER-HELLO с флагом SESSION-ID-HIT не равным нулю) или когда сервер получает сообщение CLIENT-MASTER-KEY. Это сообщение должно быть послано до любого сообщения фазы 2 или до сообщения SEVER-FINISHED.

SERVER-FINISHED (Фаза 2; посылается зашифрованным)

char MSG-SERVER-FINISHED

char SESSION-ID-DATA[N-1]

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

Здесь "N" имеет то же значение, что и в определениях, представленных выше. Это сообщение должно посылаться после сообщения SERVER-VERIFY.

REQUEST-CERTIFICATE (Фаза 2; посылается шифрованным)

char MSG-REQUEST-CERTIFICATE

char AUTHENTICATION-TYPE

char CERTIFICATE-CHALLENGE-DATA[N-2]

Сервер может выдать этот запрос в любое время диалога второй фазы, требуя присылки сертификата клиента. Клиент немедленно откликается посылкой сообщения CLIENT-CERTIFICATE, если он имеет сертификат, в противном случае присылается уведомление об ошибке с кодом NO-CERTIFICATE-ERROR. CERTIFICATE-CHALLENGE-DATA представляет собой короткую строку байтов (с длиной і 16 байт и Ј 32 байтам), которую клиент использует для отклика на этот запрос.

Значение AUTHENTICATION-TYPE используется, чтобы выбрать конкретные средства для аутентификации клиента. Определены следующие типы:

SSL_AT_MD5_WITH_RSA_ENCRYPTION

Тип SSL_AT_MD5_WITH_RSA_ENCRYPTION требует, чтобы клиент сформировал MD5-дайджест сообщения, используя информацию, как это описано выше в разделе о сообщении CLIENT-CERTIFICATE. Раз дайджест сформирован, клиент шифрует его, используя свой секретный ключ. Сервер аутентифицирует клиента, когда получает сообщение CLIENT-CERTIFICATE.

Это сообщение может быть послано после сообщения SERVER-VERIFY и до сообщения SERVER-FINISHED.

2.2.6. Протокольные сообщения Клиент/Сервер

Эти сообщения генерируются как клиентом, так и сервером.

ERROR (посылается открыто или зашифровано)

char MSG-ERROR

char ERROR-CODE-MSB

char ERROR-CODE-LSB

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

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

2.3. Протокол TLS

Первоначальной целью протокола TLS (Transport Layer Security) является обеспечение конфиденциальности и целостности данных при коммуникации двух приложений. Протокол имеет два уровня: протокол записей TLS и протокол диалога TLS. На нижнем уровне, работающем поверх надежного транспортного протокола (напр., TCP [TCP]), размещается протокол записей TLS. Этот протокол обеспечивает безопасность соединений, которые имеют два основных свойства:

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

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

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

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

2.3.1. Алгоритм процедуры установления соединения

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

Последовательность действий при установлении TLS соединения:

- клиент подключается к TLS - поддерживаемому серверу и запрашивает защищенное соединение;

- клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;

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

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

- клиент может связаться с сервером доверенного центра сертификации и подтвердить аутентичность переданного сертификата до начала передачи данных;

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

Согласно протоколу TLS приложения обмениваются записями инкапсулирующими (хранящими внутри себя) информацию, которая должна быть передана. Каждая из записей может быть сжата, дополнена, зашифрована или идентифицирована MAC в зависимости от текущего состояния соединения (состояния протокола). Каждая запись в TSL содержит следующие поля: content type (определяет тип содержимого записи), поле указывающее длину пакета и поле указывающее версию протокола TLS.

Когда соединение только устанавливается, взаимодействие идет по протоколу TLS handshake content type которого 22.

Ниже описан простой пример установления соединения:

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

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

3. Сервер посылает Certificate сообщение, которое содержит цифровой сертификат сервера (в зависимости от алгоритма шифрования этот этап может быть пропущен)

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

5. Сервер отсылает ServerHelloDone сообщение, идентифицирующее окончание handshake.

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

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

8. Клиент посылает ChangeCipherSpec сообщение, которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе handshake алгоритмом, используя общий секретный ключ. Это сообщения уровня записей и поэтому имеет тип 20, а не 22.

9. Клиент посылает сообщение Finished, которое содержит хеш и MAC (код аутентификации сообщения) сгенерированных на основе предыдущих сообщений handshake.

10. Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удается, handshake считается неудавшимся и соединение должно быть оборвано.

11. Сервер посылает ChangeCipherSpec и зашифрованное Finished сообщение и в свою очередь клиент тоже выполняет расшифровку и проверку.

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

2.3.2. Алгоритмы использующиеся в TLS

В данной текущей версии протокола доступны следующие алгоритмы:

- Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр), Diffie-Hellman (безопасный обмен ключами), DSA (алгоритм цифровой подписи) и алгоритмы технологии Fortezza.

- Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES;

- Для хэш-функций: MD5 или SHA.

Алгоритмы могут дополняться в зависимости от версии протокола.

3. Выводы.

Таким образом, основой HTTPS являются сертификаты (своеобразный "паспорт") и криптозащита (шифрование). При инициализации обмена информацией, браузер и сервер обмениваются сертификатами, тем самым однозначно идентифицируя себя. Дальнейшее взаимодействие осуществляется по зашифрованному каналу. Базирующийся на стандартном протоколе HTTP, этот протокол очень удобен для использования в тех случаях, когда необходима безопасность и конфиденциальность передачи данных.

4. Список литературы

1. Википедия. Свободная энциклопедия.

http://ru.wikipedia.org

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

http://www.citforum.ru/nets/semenov/6/tls.shtml

3. Протокол SSL. Безопасный уровень соединителей

http://www.citforum.ru/nets/semenov/6/ssl_65.shtml

4. Как работает SSL-шифрация

http://www.freessl.ru/page-work.html