Курс лекций «Проблемы безопасности в информационных технологиях»


Глава 5. Безопасные сетевые протоколы, работающие на различных уровнях модели OSI



бет23/44
Дата13.09.2017
өлшемі4.51 Mb.
#839
түріКурс лекций
1   ...   19   20   21   22   23   24   25   26   ...   44

Глава 5. Безопасные сетевые протоколы, работающие на различных уровнях модели OSI


Для обеспечения безопасных коммуникаций разработано и используется большое количество протоколов, работающих на разных уровнях эталонной модели OSI. На сегодня и в локальных сетях и, конечно же, в Интернете, абсолютно доминирует стек протоколов TCP/IP, со своей моделью уровней:

Рис.55 Сравнение модели OSI и стека TCP/IP

Протокол SSL


SSL (Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

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




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

  • Совместимость: независимые разработчики могут создавать приложения, которые будут взаимодействовать по протоколу SSL, что позволит устанавливать безопасные соединения.

  • Расширяемость: SSL формирует общий каркас, в который могут быть встроены новые алгоритмы открытого ключа и симметричного шифрования.

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

На рисунке ниже представлено местоположение протокола SSL в стеке протоколов TCP:





Рис.56 Протокол SSL
Протокол SSL состоит из двух подпротоколов: протокол SSL записи (record) и рукопожатия (handshake). Протокол SSL записи определяет формат, используемый для передачи данных. Протокол SSL включает рукопожатие с использованием протокола SSL записи для обмена сериями сообщений между сервером и клиентом во время установления первого соединения. Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат.

SSL создаёт канал, имеющий 3 основных свойства:




  • Аутентификация. Сервер всегда аутентифицируется, в то время как клиент аутентифицируется в зависимости от алгоритма.

  • Целостность. Обмен сообщениями включает в себя проверку целостности.

  • Конфиденциальность канала. Шифрование используется после установления соединения и используется для всех последующих сообщений.

В протоколе SSL определены четыре криптографические операции: цифровая подпись, поточное шифрование, блочное шифрование и шифрование с открытым ключом. В операции цифровой подписи входом в алгоритм подписи является результат применения односторонней хеш-функции к подписываемым данным. Длина входа определяется алгоритмом подписи. При использовании алгоритма RSA подписывается 36-байтная структура, состоящая из конкатенации 20 байтов хеш-кода SHA-1 и 16 байтов хеш-кода MD5. При использовании DSS 20 байтов хеш-кода SHA-1 подаются на вход алгоритму DSA без дополнительного хеширования.

В протоколе SSL все данные передаются в виде записей-объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причём, если старший бит в первом байте кода равен единице, то запись не имеет заполнителя и полная длина заголовка равна двум байтам, иначе запись содержит заполнитель и полная длина заголовка равна трём байтам. Код длины записи не включает в себя число байт заголовка. Длина записи 2-байтового заголовка:
RecLength = ((byte[0] & 0x7F) << 8) | byte[1];

Здесь byte[0] и byte[1] — первый и второй полученные байты.


Длина записи 3-байтового заголовка:
RecLength = ((byte[0] & 0x3F) << 8) | byte[1];

Escape = (byte[0] & 0x40) != 0;

Padding = byte[2];
Padding определяет число байтов, добавленных отправителем к исходному тексту, для того, чтобы сделать длину записи кратной размеру блока шифра, при использовании блочного шифра.

Отправитель «заполненной» записи добавляет заполнитель после имеющихся данных и шифрует всё это вместе. Причем, содержимое заполнителя никакой роли не играет. Из-за того, что известен объём передаваемых данных, заголовок может быть сформирован с учетом Padding. В свою очередь получатель записи дешифрует все поля данных и получает полную исходную информацию. Затем производится вычисление значения RecLength по известному Padding, и заполнитель из поля данных удаляется. Данные записи SSL состоят из 3 компонент:


MAC_Data[Mac_Size] — (Message Authentication Code) — код аутентификации сообщения

Padding_Data[Padding] — данные заполнителя

Actual_Data[N] — реальные данные
Если записи посылаются открытым текстом, очевидно, что никакие шифры не используются. Тогда длина Padding_Data и MAC_Data равны нулю. При использовании шифрования Padding_Data зависит от размера блока шифра, а MAC_Data зависит от выбора шифра. Пример вычисления MAC_Data:
MacData = Hash(Secret, Actual_Data, Padding_Data, Sequence_Number);
Значение Secret зависит от того, кто (клиент или сервер) посылает сообщение. Sequence_Number — счётчик, который инкрементируется как сервером, так и клиентом. Sequence_Number представляет собой 32-битовый код, передаваемый хеш-функции в виде 4 байт, причём, первым передаётся старший байт. Для MD2, MD5 MAC_Size равен 16 байтам (128 битам). Для 2-байтового заголовка максимальная длина записи равна 32767 байтов, а для 3-байтного заголовка — 16383 байтов.

Версия протокола SSL 1.0 публично не выпускалась. Версия 2.0 была выпущена в феврале 1995 года, но «содержала много недостатков в части безопасности, которые, в конечном счёте, привели к созданию версии 3.0», которая была выпущена в 1996 году. Версия SSL 3.0 послужила основой для создания протокола TLS 1.0, стандарт протокола Internet Engineering Task Force (IETF) впервые был определен в RFC2246 в январе 1999 года.

Развитие протокола SSL привело к формированию протокола HTTPS, поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, обеспечивая защиту этих данных. Для web-приложений, в которых важна безопасность соединения, протокол HTTPS является стандартом де-факто. HTTPS поддерживается всеми браузерами. Для работы по HTTPS по умолчанию используется TCP-порт 443.

Существуют реализации виртуальных частных сетей (VPN) на основе SSL. Также SSL получил широкое применение в электронной почте (POP3S, IMAPS).

SSL поддерживает 3 типа аутентификации:


  • взаимная аутентификация обеих сторон (клиент — сервер);

  • аутентификация сервера с неаутентифицированным клиентом;

  • полная анонимность.

Всякий раз, когда сервер аутентифицируется, канал в этот момент безопасен и устойчив против попытки перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истёк и не был отменён. Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет (главный секретный код) необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Посылкой верного сообщения «finished» стороны докажут что они знают верный секрет (pre_master_secret).




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

При использовании RSA обмен ключами и аутентификация сервера могут быть скомбинированы. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура включает текущее значение сообщения Client_Hello.random, таким образом старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.

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

При использовании обмена ключами по алгоритму Diffie-Hellman’а сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хешируются с сообщением hello.random перед подписанием, для того чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру, для уверенности, что параметры принадлежат серверу.

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

На каждом уровне протокола записи сообщения включают поля длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, сжимает данные, применяет MAC (message authentication code), шифрует и передаёт результат. Полученные данные он, соответственно, расшифровывает, проверяет, распаковывает, собирает и доставляет к верхним уровням клиента.

Существует четыре протокола записи: протокол рукопожатия (handshake protocol), протокол тревоги (alert protocol), протокол изменения шифра (the change cipher spec protocol), протокол приложения (application data protocol). Если SSL реализация получает тип записи, который ей неизвестен, то эта запись просто игнорируется. Поля типа и длины записи не защищены шифрованием.

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

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

Сервер отсылает это решение в виде цифрового сертификата (x509 v3). Сертификат содержит имя сервера, доверенный CA (Центр Сертификации) и открытый ключ шифрования сервера. Клиент может связаться с сервером, который выдал сертификат (CA) и убедиться, что сертификат является подлинным, прежде чем продолжить обмен.

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

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

Протокол изменения параметров шифрования (The Change Cipher Spec Protocol) существует для сигнализации перехода в режим шифрования. Протокол содержит единственное сообщение, которое зашифровано и сжато, как определено в текущем (не ожидаемом) установленном соединении. Сообщение состоит только из одного бита со значением 1.
struct {enum {change_cipher_spec(1), (255)} type;} ChangeCipherSpec;
Сообщение изменения шифра посылается и клиентом и сервером для извещения принимающей стороны, что последующие записи будут защищены в соответствии с новым согласованным CipherSpec и ключами. Сразу после отправки этого сообщения отправитель должен информировать уровень записи о немедленном копировании ожидаемого состояния записи в текущее состояние записи. Принятие этого сообщения заставляет получателя информировать уровень записи о незамедлительном копировании ожидаемого состояния чтения в состояние текущего чтения. Сообщение изменения шифра посылается во время рукопожатия, после того, как параметры защиты были переданы, но перед тем как будет послано сообщение «finished».

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

Протокол приложения (Application Data Protocol) работает на уровне записи. Он фрагментируется, сжимается и шифруется на основе текущего состояния соединения. Сообщения считаются прозрачными для уровня записи.

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

Против протокола SSL существует некоторое количество атак. Например, против SSL возможно реализовать атаку «человек посередине» (MitM (Man-in-the-Middle)). Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данном случае предполагается, что злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана, данная атака может быть эффективной, так как целостность принимаемой информации и её источник с использованием алгоритма DH проверить невозможно. Однако такая атака невозможна при полноценном использовании протокола SSL, так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации. Но атака может быть успешной, если:


  • Сервер не имеет подписанного сертификата.

  • Клиент не проверяет сертификат сервера.

  • Пользователь игнорирует сообщение об отсутствии подписи сертификата центром сертификации или о несовпадении сертификата с закешированным.

Данный вид атаки реализован в межсетевом экране Forefront TMG компании Microsoft. Технология носит название HTTPS Inspection. В данном случае "злоумышленник" (firewall) находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря возможности указать в качестве доверенного корневого центра сертификации сам Forefront TMG. Обычно подобная процедура внедрения проходит прозрачно для пользователя за счёт работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищённого соединения HTTPS.

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

Технологию HTTPS Inspection в свои продукты внедрила также компания CheckPoint, известный игрок на рынке продуктов информационной безопасности. Эта технология используется для доступа к «чистым данным» (clear text) в таких компонентах, как Data Loss Prevention (DLP), AntiVirus, Application Control, фильтрация URL и в системе предотвращения вторжений (IPS). Следует отметить, что CheckPoint, в отличие от решения Microsoft, не пытается подменить сертификат в системах пользователей.

Идея атаки отклика (reply) достаточно проста. Злоумышленник записывает коммуникационную сессию между клиентом и сервером. Позднее, он устанавливает соединение с сервером и воспроизводит записанные сообщения клиента. SSL может противостоять этой атаке с помощью специального кода “nonce” (идентификатор соединения), который является уникальным. Теоретически злоумышленник не может предугадать этот код заранее, так как он основывается на наборе случайных событий. Но злоумышленник со значительными ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать «правильную» сессию, основываясь на коде nonce, посылаемом сервером в сообщении Server_Hello. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 264 кодов nonce, чтобы при этом получить вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными.

Криптографические алгоритмы, использующиеся в SSL:




  • Для обмена ключами и проверки их подлинности применяются: RSA, Diffie-Hellman, ECDH, SRP, PSK.

  • Для аутентификации: RSA, DSA, ECDSA.

  • Для симметричного шифрования: RC2, RC4, IDEA, DES, 3DES или AES, Camellia.

  • Для хеш-функций: SHA, MD5, MD4 и MD2.



Достарыңызбен бөлісу:
1   ...   19   20   21   22   23   24   25   26   ...   44




©kzref.org 2022
әкімшілігінің қараңыз

    Басты бет