Транспортный уровень против безопасности на уровне сообщений - PullRequest
10 голосов
/ 24 ноября 2010

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

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

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

a)

Если эта безопасность не воспроизводится достоверно, данные могут быть скомпрометированы в нисходящем направлении.

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

b) В любом случае, насколько я понимаю, приведенная выше цитата подразумевает, что если две системы устанавливаютSSL-соединение, и если в промежуточной системе S включен SSL и если S также принадлежит хакеру, то S (он же хакер) не сможет перехватывать трафик SSL, проходящий через него?Но если в S SSL не включен, то хакер сможет перехватить SSL-трафик?Это не имеет смысла!

c)

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

Это не имеет смысла, так как транспортУровень безопасности также может использовать шифрование и сертификаты, так почему использование закрытых / открытых ключей на уровне сообщений будет более безопасным, чем их использование на транспортном уровне?А именно, если посредник может перехватывать трафик SSL, почему он также не может перехватывать сообщения, защищенные с помощью закрытых / открытых ключей на уровне сообщений?

спасибо

Ответы [ 2 ]

8 голосов
/ 02 сентября 2013

Рассмотрим случай перехвата SSL.

Как правило, если у вас есть зашифрованное соединение SSL с сервером, вы можете верить, что вы "действительно * подключены к этому серверу, и что владельцы сервера определилисами по себе однозначно доверенному стороннему лицу, такому как Verisign, Entrust или Thawte (предоставив учетные данные, идентифицирующие их имя, адрес, контактную информацию, возможность ведения бизнеса и т. д., и получив сертификат, подписанный сторонней подписью).SSL, этот сертификат является гарантией для конечного пользователя, что трафик между браузером пользователя (клиентом) и конечной точкой SSL сервера (который может быть не самим сервером, а некоторым коммутатором, маршрутизатором или балансировщиком нагрузки, где установлен сертификат SSL) является безопасным. Любой, кто перехватывает этот трафик, попадает в тупик, и если они каким-либо образом вмешиваются в него, то сервер отклоняет трафик.

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

Затем прокси-сервер компании устанавливает отдельное SSL-зашифрованное соединение с целевым сайтом (в этом примере www.google.com), нопрокси / коммутатор / маршрутизатор в середине теперь может регистрировать весь ваш трафик.

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

Шифрование на уровне сообщений гарантирует, что сообщение останетсязашифрован, даже во время этих промежуточных «прыжков», где дешифруется сам трафик.

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

6 голосов
/ 24 ноября 2010

Мне кажется, я вижу, к чему он клонит.Скажем так:

Веб-клиент ---> Веб-сервер презентации ---> Вызов веб-службы в базу данных

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...