Транспортный уровень против безопасности на уровне сообщений
Я читаю книгу о WCF, и автор спорит о плюсах использования безопасности на уровне сообщений по сравнению с безопасностью на транспортном уровне. В любом случае, я не могу найти никакой логики в аргументах автора
Одним из ограничений транспортной безопасности является то, что она зависит от каждого "шага" и участника сетевого пути, которые постоянно настраивают безопасность. Другими словами, если сообщение должно пройти через посредника до того, как оно достигнет пункта назначения, нет способа гарантировать, что транспортная безопасность была включена для шага после посредника (если этот посредник не полностью контролируется исходным поставщиком услуг), Если эта безопасность не воспроизводится достоверно, данные могут быть скомпрометированы в последующем.
Безопасность сообщений направлена на обеспечение целостности и конфиденциальности отдельных сообщений без учета сети. Посредством таких механизмов, как шифрование и подписывание с помощью открытых и закрытых ключей, сообщение будет защищено, даже если оно отправлено через незащищенный транспорт (например, простой HTTP).
а)
Если эта безопасность не воспроизводится достоверно, данные могут быть скомпрометированы в последующем.
Да, но если предположить, что две системы, использующие связь, используют SSL и, следовательно, сертификаты, то данные, которыми они обмениваются, не могут быть расшифрованы посредником, но вместо этого их можно только изменить, что получатель заметит и, таким образом, отклонит пакет?!
б) В любом случае, насколько я понимаю, приведенная выше цитата подразумевает, что если две системы устанавливают соединение SSL, а если - промежуточную систему S SSL включен, и если S также принадлежит хакеру, то S (он же хакер) не сможет перехватить трафик SSL, проходящий через него? Но если S если SSL не включен, то хакер сможет перехватить трафик SSL? Это не имеет смысла!
с)
Безопасность сообщений направлена на обеспечение целостности и конфиденциальности отдельных сообщений без учета сети. Посредством таких механизмов, как шифрование и подписывание с помощью открытых и закрытых ключей, сообщение будет защищено, даже если оно отправлено через незащищенный транспорт (например, простой HTTP).
Это не имеет смысла, так как безопасность транспортного уровня также может использовать шифрование и сертификаты, так почему использование закрытых / открытых ключей на уровне сообщений будет более безопасным, чем их использование на транспортном уровне? А именно, если посредник может перехватывать трафик SSL, почему он также не может перехватывать сообщения, защищенные с помощью закрытых / открытых ключей на уровне сообщений?
благодарю вас
2 ответа
Я думаю, я вижу, к чему он клонит. Скажи так:
Веб-клиент ---> Веб-сервер презентации ---> вызов веб-службы в базе данных
В этом случае вы зависите от промежуточного сервера, который снова шифрует данные, прежде чем они попадут в базу данных. Если вместо этого сообщение было зашифровано, только бэкэнд будет знать, как его прочитать, поэтому середина не имеет значения.
Рассмотрим случай перехвата SSL.
Как правило, если у вас есть зашифрованное SSL-соединение с сервером, вы можете верить, что вы "действительно * подключены к этому серверу" и что владельцы сервера однозначно идентифицировали себя с взаимно доверяемой третьей стороной, такой как Verisign, Entrust или Thawte. (путем предоставления учетных данных, идентифицирующих их имя, адрес, контактную информацию, возможность ведения бизнеса и т. д. и получения сертификата, подписанного сторонней подписью). Используя SSL, этот сертификат является гарантией конечному пользователю, что трафик между пользователем Браузер (клиент) и конечная точка SSL сервера (которая может быть не самим сервером, а некоторым коммутатором, маршрутизатором или балансировщиком нагрузки, на котором установлен сертификат SSL) безопасны. Любой, кто перехватывает этот трафик, получает gobbledygook, и, если они вмешиваются в него в любом случае, тогда трафик отклоняется сервером.
Но перехват SSL становится обычным явлением во многих компаниях. При перехвате SSL вы "запрашиваете" HTTPS-соединение с (например) www.google.com, а коммутатор / маршрутизатор / прокси-сервер компании передает вам действующий сертификат с именем www.google.com в качестве конечной точки (так что ваш браузер не ' не жаловаться на несоответствие имени), но вместо того, чтобы быть подписанным взаимно доверенной третьей стороной, оно подписывается их собственным центром сертификации (работающим где-то в компании), которому также доверяет ваш браузер (так как он находится в вашем список доверенных корневых ЦС, который контролируется компанией).
Затем прокси-сервер компании устанавливает отдельное зашифрованное SSL-соединение с целевым сайтом (в данном примере www.google.com), но прокси / коммутатор / маршрутизатор в середине теперь может регистрировать весь ваш трафик.
Вы по-прежнему видите значок блокировки в своем браузере, поскольку трафик шифруется до внутренней конечной точки SSL вашей компании с использованием их собственного сертификата, а трафик повторно шифруется с этой конечной точки до конечного пункта назначения с использованием SSL-сертификата назначения, но человек в середине (прокси / маршрутизатор / коммутатор) теперь можно регистрировать, перенаправлять или даже подделывать весь ваш трафик.
Шифрование на уровне сообщений гарантировало бы, что сообщение остается зашифрованным даже во время этих промежуточных "скачков", когда сам трафик расшифровывается.
Балансировка нагрузки является еще одним хорошим примером, поскольку сертификат SSL обычно устанавливается на балансировщик нагрузки, который представляет конечную точку SSL. Затем балансировщик нагрузки отвечает за решение, на какую физическую машину отправлять для обработки теперь расшифрованный трафик. Ваши сообщения могут проходить через несколько таких "прыжков", прежде чем они, наконец, достигнут конечной точки службы, которая сможет понять и обработать сообщение.