Безопасная связь в Java - Сериализованные CipherText-Objects против Transport-Layer-Encryption против RMI по SSL

Question

Я хочу реализовать зашифрованное соединение между двумя серверами JAVA, оба находятся под моим контролем. Я имею в виду три архитектуры и хочу узнать ваши плюсы и минусы.

Архитектура 1: Всякий раз, когда я вызываю удаленный метод, я передаю параметры не как простой текст, а как сериализованный объект CipherText. Я буду использовать для этого ESAPI-библиотеку, но фактическая реализация не имеет значения. Важно то, что CipherText-Object содержит произвольные Данные, зашифрованные симметричным ключом, включая MAC для аутентификации. Симметричный ключ доступен как общий секретный ключ на обоих серверах.

Архитектура 2: Меня не волнует шифрование на уровне приложений, но я делегирую его на транспортный уровень. Это может быть VPN-туннель или какое-либо шифрование между серверами, которое поддерживается. У меня не так много информации о том, что сейчас доступно на современном сервере приложений. Вклад в это также приветствуется.

Архитектура 3: Использование javax.rmi.ssl для использования RMI поверх SSL.

Такое ощущение, что архитектура 1 сложна и трудна для реализации. Архитектура 2 оставляет шифрование на сервере приложений. Как разработчик приложений, я не имею никакого контроля над настройкой этих функций. Это плохо, потому что я хочу убедиться, что приложение не может быть использовано без надлежащего шифрования. Архитектура 3 кажется лучшим способом, но у меня нет опыта работы с этой технологией.

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

Answer 1

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

Во-вторых, решения для обеспечения безопасности обычно не являются исключительными.Вы можете реализовать все 3 решения одновременно (передача по VPN вызовов RMI-SSL с заданными параметрами).Вопрос будет стоить реализации и накладных расходов.

Теперь к вопросу под рукой:

1) Мне это не нравится, потому что:

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

2 и 3) более или менее эквивалентны.Однако с 2 вы должны убедиться, что ваши серверы принимают только соединения, поступающие через OpenVPN, а не от другого NI.Я не очень хорошо знаю RMI через SSL, но если у него нет скрытой уязвимости, все выглядит хорошо.

ИМХО, я бы выбрал 3 (стандартный, встроенный в сервер и более гибкий).2 - это тоже хороший вариант, его легче реализовать, но он требует лучшего контроля над сервером.Я заново изобретаю колесо там, где уже есть действительные опции, я бы отказался от него.

Answer 2

Архитектура 4: стандартный сокет ввода-вывода по SSL.