Протоколы SSL/TLS

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

Взаимная аутентификация обеих сторон в SSL выполняется путем обмена цифровыми сертификатами открытых ключей пользователей (клиента и сервера), заверенными цифровой подписью специальных сертификационных центров. Протокол SSL поддерживает сертификаты, соответствующие общепринятому стандарту Х.509, а также стандарты инфраструктуры открытых ключей PKI (Public Key Infrastructure), с помощью которой организуется выдача и проверка подлинности сертификатов.

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

В качестве алгоритмов асимметричного шифрования используются алгоритм RSA, а также алгоритм Диффи — Хеллмана. Допустимыми алгоритмами симметричного шифрования являются RC2, RC4, DES, 3DES и AES. Для вычисления хэш-функций могут применяться стандарты MD5 и SHA-1. В протоколе SSL версии 3.0 набор криптографических алгоритмов является расширяемым.

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

Рис. 11.6. Криптозащищенные туннели, сформированные на основе протокола SSL

Протокол SSL предусматривает следующие этапы взаимодействия клиента и сервера при формировании и поддержке защищаемого соединения:

• установление SSL-сессии;

• защищенное взаимодействие.

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

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

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

Протокол SSL 3.0 поддерживает три режима аутентификации:
• взаимную аутентификацию сторон;
• одностороннюю аутентификацию сервера без аутентификации клиента;
• полную анонимность.

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

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

Соответствие между открытыми ключами и их владельцами устанавливается с помощью цифровых сертификатов, выдаваемых специальными центрами сертификации.

Протокол SSL прошел проверку временем, работая в популярных браузерах Netscape Navigator и Internet Explorer, а также Web-серверах ведущих производителей. В январе 1999 г. на смену версии SSL 3.0 пришел протокол TLS (Transport Layer Security), который базируется на протоколе SSL и в настоящее время является стандартом Интернета. Различия между протоколами SSL 3.0 и TLS 1.0 не слишком существенны. Протокол SSL стал промышленным протоколом, развиваемым и продвигаемым вне технических координирующих институтов Internet.

Протокол SSL поддерживается ПО серверов и клиентов, выпускаемых ведущими западными компаниями. Существенным недостатком протокола SSLявляется то, что практически все продукты, поддерживающие SSL, из-за экспортных ограничений доступны за пределами США лишь в усеченном варианте (с длиной сеансового ключа 40 бит для алгоритмов симметричного шифрования и 512 бит для алгоритма RSA, используемого на этапе установления SSL-сессии).

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

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

Протокол SOCKS

Протокол SOCKS организует процедуру взаимодействия клиент-серверных приложений на сеансовом уровне модели OSI через сервер-посредник, илиproxy-сервер.

В общем случае программы-посредники, которые традиционно используются в МЭ, могут выполнять следующие функции:
• идентификацию и аутентификацию пользователей;
• криптозащиту передаваемых данных;
• разграничение доступа к ресурсам внутренней сети;
• разграничение доступа к ресурсам внешней сети;
• фильтрацию и преобразование потока сообщений, например поиск вирусов и прозрачное шифрование информации;
• трансляцию внутренних сетевых адресов для исходящих потоков сообщений.

Первоначально протокол SOCKS разрабатывался только для перенаправления запросов к серверам со стороны клиентских приложений, а также возврата этим приложениям полученных ответов. Перенаправление запросов и ответов между клиент-серверными приложениями уже позволяет реализовать функцию трансляции сетевых IP-адресов NAT (Network Address Translation). Замена у исходящих пакетов внутренних IP-адресов отправителей одним IP-адресом шлюза позволяет скрыть топологию внутренней сети от внешних пользователей и тем самым усложнить задачу НСД.

На основе протокола SOCKS могут быть реализованы и другие функции посредничества по защите сетевого взаимодействия. Например, протокол SOCKSможет применяться для контроля над направлениями информационных потоков и разграничения доступа в зависимости от атрибутов пользователей и информации. Эффективность использования протокола SOCKS для выполнения функций посредничества обеспечивается его ориентацией на сеансовый уровень модели OSI. По сравнению с посредниками прикладного уровня на сеансовом уровне достигается более высокое быстродействие и независимость от высокоуровневых протоколов (HTTP, FTP, РОРЗ, SMTP и др.). Кроме того, протокол SOCKS не привязан к протоколу IP и не зависит от ОС. Например, для обмена информацией между клиентскими приложениями и посредником может использоваться протокол IPX.

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

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

Протокол SOCKS v5 одобрен организацией IETF (Internet Engineering Task Force) в качестве стандарта Internet и включен в RFC 1928.

Общая схема установления соединения по протоколу SOCKS v5 может быть описана следующим образом:
• запрос прикладного клиента, желающего установить соединение с каким-либо прикладным сервером в сети, перехватывает установленный на этом же компьютере SOCKS-клиент;
• соединившись с SOCKS-сервером, SOCKS-клиент сообщает ему идентификаторы всех методов аутентификации, которые он поддерживает;
• SOCKS-сервер решает, каким методом аутентификации воспользоваться (если SOCKS-сервер не поддерживает ни один из методов аутентификации, предложенных SOCKS-клиентом, соединение разрывается);
• при поддержке каких-либо предложенных методов аутентификации SOCKS-сервер в соответствии с выбранным методом аутентифицирует пользователя, от имени которого выступает SOCKS-клиент; в случае безуспешной аутентификации SOCKS-сервер разрывает соединение;
• после успешной аутентификации SOCKS-клиент передает SOCKS-серверу DNS-имя или IP-адрес запрашиваемого прикладного сервера в сети и далееSOCKS-сервер на основе имеющихся правил разграничения доступа принимает решение об установлении соединения с этим прикладным сервером;
• в случае установления соединения прикладной клиент и прикладной сервер взаимодействуют друг с другом по цепочке соединений, в которой SOCKS-сервер ретранслирует данные, а также может выполнять функции посредничества по защите сетевого взаимодействия; например, если в ходе аутентификации SOCKS-клиент и SOCKS-сервер обменялись сеансовым ключом, то весь трафик между ними может шифроваться.

Аутентификация пользователя, выполняемая SOCKS-сервером, может основываться на цифровых сертификатах в формате Х.509 или паролях. Для шифрования трафика между SOCKS-клиентом и SOCKS-сервером могут быть использованы протоколы, ориентированные на сеансовый или более низкие уровни модели OSI. Кроме аутентификации пользователей, трансляции IP-адресов и криптозащиты трафика, SOCKS-сервер может выполнять также такие функции, как:
• разграничение доступа к ресурсам внутренней сети;
• разграничение доступа к ресурсам внешней сети;
• фильтрация потока сообщений, например, динамический поиск вирусов;
• регистрация событий и реагирование на задаваемые события;
• кэширование данных, запрашиваемых из внешней сети.

Протокол SOCKS осуществляет встроенную поддержку популярных Web-навигаторов Netscape Navigator и Netscape Communicator компании Netscape, а также Internet Explorer компании Microsoft.

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

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

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

Помимо защиты локальной сети от НСД, на SOCKS-сервер может возлагаться контроль доступа пользователей этой локальной сети к открытым ресурсам Интернета (Telnet, WWW, SMTP, POP и др.). Доступ является полностью авторизованным, так как идентифицируются и аутентифицируются конкретные пользователи, а не компьютеры, с которых они входят в сеть. Правила доступа могут запрещать или разрешать соединения с конкретными ресурсами Интернета в зависимости от полномочий конкретного сотрудника. Действие правил доступа может зависеть и от других параметров, например от метода аутентификации или времени суток.

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