Сетевая безопасность - транспортный уровень

Сетевая безопасность подразумевает защиту данных от атак во время их передачи по сети. Для достижения этой цели было разработано множество протоколов безопасности в реальном времени. Существуют популярные стандарты для протоколов сетевой безопасности в реальном времени, такие как S / MIME, SSL / TLS, SSH и IPsec. Как упоминалось ранее, эти протоколы работают на разных уровнях сетевой модели.

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

Для сети на основе протокола TCP / IP физический уровень и уровень передачи данных обычно реализуются в пользовательском терминале и аппаратном обеспечении сетевой карты. Уровни TCP и IP реализованы в операционной системе. Все, что выше TCP / IP, реализовано как пользовательский процесс.

Потребность в безопасности транспортного уровня

Давайте обсудим типичную бизнес-транзакцию в Интернете.

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

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

• Если не используется мера целостности данных, злоумышленник может изменить заказ Боба с точки зрения типа или количества товаров.

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

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

Безопасность на этом уровне в основном используется для защиты веб-транзакций на основе HTTP в сети. Однако его может использовать любое приложение, работающее через TCP.

Философия дизайна TLS

Протоколы безопасности транспортного уровня (TLS) работают над уровнем TCP. В конструкции этих протоколов используются популярные прикладные программные интерфейсы (API) для TCP, называемые «сокетами» для взаимодействия с уровнем TCP.

Приложения теперь связаны с транспортным уровнем безопасности, а не напрямую с TCP. Transport Security Layer предоставляет простой API с сокетами, который похож и аналогичен API TCP.

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

TLS разработан для работы по TCP, надежному протоколу уровня 4 (не по протоколу UDP), чтобы упростить проектирование TLS, поскольку ему не нужно беспокоиться о «тайм-ауте» и «повторной передаче потерянных данных». Уровень TCP продолжает делать это как обычно, что служит потребностям TLS.

Почему TLS популярен?

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

Уровень защищенных сокетов (SSL)

В этом разделе мы обсудим семейство протоколов, разработанных для TLS. Семейство включает SSL версий 2 и 3 и протокол TLS. SSLv2 был заменен на SSLv3, поэтому мы сосредоточимся на SSL v3 и TLS.

Краткая история SSL

В 1995 году Netscape разработала SSLv2 и использовала его в Netscape Navigator 1.1. Версия SSL 1 никогда не публиковалась и не использовалась. Позже Microsoft улучшила SSLv2 и представила другой аналогичный протокол под названием Private Communications Technology (PCT).

Netscape существенно улучшил SSLv2 по различным вопросам безопасности и развернул SSLv3 в 1999 году. Впоследствии Internet Engineering Task Force (IETF) представила аналогичный протокол TLS (Transport Layer Security) в качестве открытого стандарта. Протокол TLS не совместим с SSLv3.

TLS изменил криптографические алгоритмы расширения ключа и аутентификации. Кроме того, TLS предложил использовать открытое шифрование Диффи-Хеллмана (DH) и Стандарт цифровой подписи (DSS) вместо запатентованного шифрования RSA, используемого в SSL. Но из-за истечения срока действия патента RSA в 2000 году у пользователей не было серьезных причин для перехода от широко применяемого SSLv3 к TLS.

Важные особенности SSL

Основные особенности протокола SSL следующие:

• SSL обеспечивает безопасность сетевого подключения через:

  • Confidentiality - Обмен информацией осуществляется в зашифрованном виде.

  • Authentication- Коммуникационные объекты идентифицируют друг друга с помощью цифровых сертификатов. Проверка подлинности веб-сервера является обязательной, тогда как проверка подлинности клиента остается необязательной.

  • Reliability - Поддерживает проверки целостности сообщений.

• SSL доступен для всех приложений TCP.

• Поддерживается практически всеми веб-браузерами.

• Обеспечивает простоту ведения бизнеса с новыми онлайн-организациями.

• Разработано в первую очередь для электронной коммерции в Интернете.

Архитектура SSL

SSL специфичен для TCP и не работает с UDP. SSL предоставляет приложениям интерфейс прикладного программирования (API). Библиотеки / классы SSL для C и Java легко доступны.

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

Сам по себе SSL не является одноуровневым протоколом, как показано на рисунке; фактически он состоит из двух подслоев.

• Нижний подуровень состоит из одного компонента протокола SSL, называемого протоколом записи SSL. Этот компонент предоставляет услуги целостности и конфиденциальности.

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

  • Протокол установления связи SSL
  • Изменить протокол спецификации шифра
  • Протокол оповещения.

• Эти три протокола управляют всеми обменами сообщениями SSL и обсуждаются далее в этом разделе.

Функции компонентов протокола SSL

Четыре подкомпонента протокола SSL обрабатывают различные задачи для безопасной связи между клиентским компьютером и сервером.

• Протокол записи

  • Уровень записи форматирует сообщения протокола верхнего уровня.

  • Он фрагментирует данные на управляемые блоки (максимальная длина 16 КБ). При желании он сжимает данные.

  • Шифрует данные.

  • Предоставляет заголовок для каждого сообщения и хэш (код аутентификации сообщения (MAC)) в конце.

  • Передает отформатированные блоки на уровень TCP для передачи.

• Протокол установления связи SSL

  • Это самая сложная часть SSL. Он вызывается перед передачей каких-либо данных приложения. Он создает сеансы SSL между клиентом и сервером.

  • Установление сеанса включает аутентификацию сервера, согласование ключей и алгоритмов, установление ключей и аутентификацию клиента (необязательно).

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

  • Несколько защищенных TCP-соединений между клиентом и сервером могут совместно использовать один и тот же сеанс.

  • Действия протокола рукопожатия через четыре фазы. Они обсуждаются в следующем разделе.

• Протокол ChangeCipherSpec

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

  • Когда каждый объект отправляет сообщение ChangeCipherSpec, он меняет свою сторону соединения в безопасное состояние по согласованию.

  • Состояние ожидания параметров шифра копируется в текущее состояние.

  • Обмен этим сообщением указывает на то, что все будущие обмены данными зашифрованы и целостность защищена.

• Протокол предупреждений SSL

  • Этот протокол используется для сообщения об ошибках, таких как неожиданное сообщение, неверный MAC-адрес записи, сбой согласования параметров безопасности и т. Д.

  • Он также используется для других целей - таких как уведомление о закрытии TCP-соединения, уведомление о получении неверного или неизвестного сертификата и т. Д.

Установление SSL-сеанса

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

Phase 1 - Установление возможностей безопасности.

• Этот этап состоит из обмена двумя сообщениями - Client_hello и Server_hello .

• Client_hello содержит список криптографических алгоритмов, поддерживаемых клиентом, в порядке убывания предпочтения.

• Server_hello содержит выбранную спецификацию шифра (CipherSpec) и новый session_id .

• CipherSpec содержит такие поля, как -

  • Алгоритм шифрования (DES, 3DES, RC2 и RC4)

  • MAC-алгоритм (на основе MD5, SHA-1)

  • Алгоритм открытого ключа (RSA)

  • Оба сообщения имеют «одноразовый номер» для предотвращения атаки повторного воспроизведения.

Phase 2 - Серверная аутентификация и обмен ключами.

• Сервер отправляет сертификат. Клиентское программное обеспечение поставляется с открытыми ключами различных «доверенных» организаций (ЦС) для проверки сертификата.

• Сервер отправляет выбранный набор шифров.

• Сервер может запросить сертификат клиента. Обычно этого не делают.

• Сервер указывает конец Server_hello .

Phase 3 - Аутентификация клиента и обмен ключами.

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

• Он также отправляет Pre-master Secret (PMS), зашифрованный с помощью открытого ключа сервера.

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

Phase 4 - Готово.

• Клиент и сервер отправляют друг другу сообщения Change_cipher_spec, чтобы отложенное состояние шифра было скопировано в текущее состояние.

• Отныне все данные зашифрованы и защищены.

• Сообщение «Готово» с каждого конца подтверждает, что процессы обмена ключами и аутентификации прошли успешно.

Все четыре фазы, описанные выше, происходят при установлении сеанса TCP. Установление сеанса SSL начинается после TCP SYN / SYNACK и заканчивается до TCP Fin.

Возобновление отключенного сеанса

• Можно возобновить отключенный сеанс (через сообщение Alert ), если клиент отправляет серверу hello_request с зашифрованной информацией session_id .

• Затем сервер определяет, действителен ли session_id . В случае проверки он обменивается сообщениями ChangeCipherSpec и finished с клиентом, и безопасная связь возобновляется.

• Это позволяет избежать перерасчета параметров сеансового шифра и экономит вычисления на сервере и на стороне клиента.

Ключи сеанса SSL

Мы видели, что во время фазы 3 установления сеанса SSL клиент отправляет на сервер предварительный секрет, зашифрованный с использованием открытого ключа сервера. Главный секрет и различные сеансовые ключи генерируются следующим образом:

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

  • Предварительный секрет.

  • Два одноразовых номера (RA и RB) обмениваются в сообщениях client_hello и server_hello.

• Шесть секретных значений затем выводятся из этого главного секрета как -

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

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

  • Секретный ключ и IV, используемые для шифрования (сервером)

  • Секретный ключ и IV, используемые для шифрования (клиентом)

Протокол TLS

Чтобы обеспечить открытый Интернет-стандарт SSL, IETF выпустила протокол безопасности транспортного уровня (TLS) в январе 1999 года. TLS определен как предлагаемый Интернет-стандарт в RFC 5246.

Характерные особенности

• Протокол TLS преследует те же цели, что и SSL.

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

• Протокол TLS находится над надежным транспортным уровнем TCP, ориентированным на соединение, в стеке сетевых уровней.

• Архитектура протокола TLS аналогична протоколу SSLv3. Он имеет два дополнительных протокола: протокол записи TLS и протокол установления связи TLS.

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

Сравнение протоколов TLS и SSL

Существует восемь основных различий между протоколами TLS и SSLv3. Это следующие -

• Protocol Version - Заголовок сегмента протокола TLS содержит номер версии 3.1, чтобы различать номер 3, переносимый заголовком сегмента протокола SSL.

• Message Authentication- TLS использует хэш-код аутентификации сообщения с ключом (H-MAC). Преимущество заключается в том, что H-MAC работает с любой хэш-функцией, а не только с MD5 или SHA, как явно указано в протоколе SSL.

• Session Key Generation - Есть два различия между протоколами TLS и SSL для генерации ключевого материала.

  • Методика вычисления pre-master и master секретов аналогична. Но в протоколе TLS для вычисления главного секрета используется стандартный вывод HMAC и вывод псевдослучайной функции (PRF) вместо специального MAC.

  • Алгоритм вычисления сеансовых ключей и значений инициации (IV) отличается в протоколе TLS от протокола SSL.

• Сообщение протокола оповещения -

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

  • Многие дополнительные сообщения Alert включены в протокол TLS для других условий ошибки, таких как record_overflow, decode_error и т. Д.

• Supported Cipher Suites- SSL поддерживает наборы шифров RSA, Diffie-Hellman и Fortezza. Протокол TLS поддерживает все костюмы, кроме Fortezza.

• Client Certificate Types- TLS определяет типы сертификатов, которые должны быть запрошены в сообщении certificate_request . SSLv3 поддерживает все это. Кроме того, SSL поддерживает некоторые другие типы сертификатов, такие как Fortezza.

• CertificateVerify и завершенные сообщения -

  • В SSL для сообщения certificate_verify используется сложная процедура сообщения. При использовании TLS проверенная информация содержится в самих сообщениях подтверждения, что позволяет избежать этой сложной процедуры.

  • Готовое сообщение вычисляется по-разному в TLS и SSLv3.

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

Вышеупомянутые различия между протоколами TLS и SSLv3 приведены в следующей таблице.

Безопасный просмотр - HTTPS

В этом разделе мы обсудим использование протокола SSL / TLS для безопасного просмотра веб-страниц.

HTTPS определен

Протокол передачи гипертекста (HTTP) используется для просмотра веб-страниц. Функция HTTPS аналогична HTTP. Единственная разница в том, что HTTPS обеспечивает «безопасный» просмотр веб-страниц. HTTPS означает HTTP через SSL. Этот протокол используется для обеспечения зашифрованного и аутентифицированного соединения между клиентским веб-браузером и сервером веб-сайта.

Безопасный просмотр через HTTPS гарантирует, что следующий контент будет зашифрован:

• URL запрошенной веб-страницы.
• Содержимое веб-страницы, предоставляемое сервером клиенту пользователя.
• Содержание форм, заполняемых пользователем.
• Файлы cookie устанавливаются в обоих направлениях.

Работа HTTPS

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

• Вы запрашиваете HTTPS-соединение с веб-страницей, вводя https: //, а затем URL-адрес в адресной строке браузера.

• Веб-браузер устанавливает соединение с веб-сервером. Использование https требует использования протокола SSL.

• Приложение, в данном случае браузер, использует системный порт 443 вместо порта 80 (используется в случае http).

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

• Сначала веб-сайт отправляет свой цифровой сертификат SSL в ваш браузер. При проверке сертификата выполняется подтверждение SSL для обмена общими секретами для сеанса.

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

• После установления этот сеанс состоит из множества защищенных соединений между веб-сервером и браузером.

Использование HTTPS

• Использование HTTPS обеспечивает конфиденциальность, аутентификацию сервера и целостность сообщений для пользователя. Это обеспечивает безопасное ведение электронной коммерции в Интернете.

• Предотвращает перехват данных и отрицает кражу личных данных, которая является распространенной атакой на HTTP.

Современные веб-браузеры и веб-серверы оснащены поддержкой HTTPS. Однако использование HTTPS поверх HTTP требует большей вычислительной мощности на стороне клиента и сервера для выполнения шифрования и установления связи SSL.

Протокол защищенной оболочки (SSH)

Основные особенности SSH следующие:

• SSH - это сетевой протокол, который работает поверх уровня TCP / IP. Он разработан для замены TELNET, который обеспечивал небезопасные средства удаленного входа в систему.

• SSH обеспечивает безопасную связь клиент / сервер и может использоваться для таких задач, как передача файлов и электронная почта.

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

SSH определен

SSH организован в виде трех подпротоколов.

• Transport Layer Protocol- Эта часть протокола SSH обеспечивает конфиденциальность данных, аутентификацию сервера (хоста) и целостность данных. Он также может дополнительно обеспечивать сжатие данных.

  • Server Authentication- Ключи хоста асимметричны, как открытые / закрытые ключи. Сервер использует открытый ключ, чтобы подтвердить свою личность клиенту. Клиент проверяет, что подключенный сервер является «известным» хостом из поддерживаемой им базы данных. После аутентификации сервера генерируются ключи сеанса.

  • Session Key Establishment- После аутентификации сервер и клиент соглашаются использовать шифр. Ключи сеанса генерируются как клиентом, так и сервером. Ключи сеанса генерируются до аутентификации пользователя, поэтому имена пользователей и пароли могут быть отправлены в зашифрованном виде. Эти ключи обычно заменяются через определенные промежутки времени (например, каждый час) во время сеанса и уничтожаются сразу после использования.

  • Data Integrity- SSH использует алгоритмы кода аутентификации сообщения (MAC) для проверки целостности данных. Это улучшение по сравнению с 32-битным CRC, используемым SSH1.

• User Authentication Protocol- Эта часть SSH аутентифицирует пользователя на сервере. Сервер проверяет, предоставляется ли доступ только предполагаемым пользователям. В настоящее время используются многие методы аутентификации, такие как вводимые пароли, Kerberos, аутентификация с открытым ключом и т. Д.

• Connection Protocol - Это обеспечивает несколько логических каналов через одно базовое соединение SSH.

Службы SSH

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

• Secure Command-Shell (Remote Logon)- Он позволяет пользователю редактировать файлы, просматривать содержимое каталогов и получать доступ к приложениям на подключенном устройстве. Системные администраторы могут удаленно запускать / просматривать / останавливать службы и процессы, создавать учетные записи пользователей, изменять права доступа к файлам / каталогам и т. Д. Все задачи, которые можно выполнить в командной строке машины, теперь можно безопасно выполнять с удаленной машины с помощью безопасного удаленного входа в систему.

• Secure File Transfer- Протокол передачи файлов SSH (SFTP) разработан как расширение SSH-2 для безопасной передачи файлов. По сути, это отдельный протокол, расположенный поверх протокола Secure Shell для обработки передачи файлов. SFTP шифрует как имя пользователя / пароль, так и передаваемые данные файла. Он использует тот же порт, что и сервер Secure Shell, то есть системный порт №22.

• Port Forwarding (Tunneling)- Это позволяет защитить данные из незащищенных приложений на основе TCP / IP. После настройки переадресации портов Secure Shell перенаправляет трафик из программы (обычно клиента) и отправляет его через зашифрованный туннель в программу на другой стороне (обычно сервер). Несколько приложений могут передавать данные по одному мультиплексированному безопасному каналу, что устраняет необходимость открывать множество портов на межсетевом экране или маршрутизаторе.

Преимущества и ограничения

Преимущества и ограничения использования безопасности связи на транспортном уровне следующие:

• Льготы

  • Безопасность транспортного уровня прозрачна для приложений.

  • Сервер аутентифицирован.

  • Заголовки прикладного уровня скрыты.

  • Он более детализирован, чем механизмы безопасности на уровне 3 (IPsec), поскольку работает на уровне транспортного соединения.

• Ограничения

  • Применимо только к приложениям на основе TCP (не UDP).

  • Заголовки TCP / IP чистые.

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

  • SSL не обеспечивает отказ от авторства, поскольку аутентификация клиента не является обязательной.

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

Резюме

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

Одним из способов смягчения потенциальной атаки во время сеанса пользователя является использование защищенного протокола связи. В этой главе обсуждаются два таких протокола связи, Secure Sockets Layer (SSL) и Transport Layer Security (TLS). Оба эти протокола работают на транспортном уровне.

Другой протокол транспортного уровня, Secure Shell (SSH), призванный заменить TELNET, обеспечивает безопасные средства удаленного входа в систему. Он может предоставлять различные услуги, такие как Secure Command Shell и SFTP.

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