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

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

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

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

Необходимость безопасности на транспортном уровне

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

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

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

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

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

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

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

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

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

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

Философия TLS Design

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

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

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

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

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

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

Secure Socket Layer (SSL)

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

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

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

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

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

Существенные особенности SSL

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

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

  • Конфиденциальность — информация передается в зашифрованном виде.

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

  • Надежность — поддерживает проверки целостности сообщений.

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

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

• Обеспечивает легкость в ведении бизнеса с новыми онлайн-объектами.

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

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

Конфиденциальность — информация передается в зашифрованном виде.

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

Надежность — поддерживает проверки целостности сообщений.

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

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

Обеспечивает легкость в ведении бизнеса с новыми онлайн-объектами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• SSL протокол рукопожатия

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

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

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

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

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

• Протокол ChangeCipherSpec

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

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

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

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

• Протокол оповещения SSL

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

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

SSL протокол рукопожатия

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

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

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

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

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

Протокол ChangeCipherSpec

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

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

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

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

Протокол оповещения SSL

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

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

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

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

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

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

Эта фаза состоит из обмена двумя сообщениями — Client_hello и Server_hello .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап 2 — Проверка подлинности сервера и обмен ключами.

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

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

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

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

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

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

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

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

Этап 3 — аутентификация клиента и обмен ключами.

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

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

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

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

Он также отправляет секретный секретный файл (PMS), зашифрованный открытым ключом сервера.

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

Этап 4 — Готово.

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

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

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

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

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

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

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

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

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

• Затем сервер определяет, является ли идентификатор_ сеанса действительным. В случае подтверждения он обменивается ChangeCipherSpec и завершенными сообщениями с клиентом и возобновляет безопасную связь.

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

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

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

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

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

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

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

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

  • В сообщениях client_hello и server_hello произошел обмен двумя одноразовыми номерами (RA и RB).

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

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

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

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

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

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

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

В сообщениях client_hello и server_hello произошел обмен двумя одноразовыми номерами (RA и RB).

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

Секретный ключ, используемый с 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 находится над надежным транспортным уровнем TCP, ориентированным на установление соединения, в стеке сетевых уровней.

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

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

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

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

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

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

• Генерация ключа сеанса. Существует два различия между протоколом TLS и SSL для генерации материала ключа.

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

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

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

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

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

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

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

• CertificateVerify и готовые сообщения —

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

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

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

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

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

Генерация ключа сеанса. Существует два различия между протоколом TLS и SSL для генерации материала ключа.

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

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

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

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

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

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

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

CertificateVerify и готовые сообщения —

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

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

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

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

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

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

HTTPS определен

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

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

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

Работа HTTPS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Предотвращает подслушивание данных и запрещает кражу личных данных, которые являются обычными атаками на HTTP.

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

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

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

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

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

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

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

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

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

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

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

Определен SSH

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

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

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

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

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

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

• Протокол соединения — обеспечивает несколько логических каналов через одно базовое соединение SSH.

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

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

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

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

Протокол аутентификации пользователя — эта часть SSH аутентифицирует пользователя на сервере. Сервер проверяет, что доступ предоставляется только предполагаемым пользователям. В настоящее время используются многие методы аутентификации, такие как введенные пароли, Kerberos, аутентификация с открытым ключом и т. Д.

Протокол соединения — обеспечивает несколько логических каналов через одно базовое соединение SSH.

Услуги SSH

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

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

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

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

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

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

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

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

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

• Выгоды

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

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

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

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

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

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

  • Заголовки TCP / IP в открытом виде.

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

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

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

Выгоды

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

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

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

Он более детализирован, чем механизмы безопасности на уровне 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.