Готовый SSL в Java-апплете - PullRequest
0 голосов
/ 08 мая 2009

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

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

Итак, можно ли в качестве запасного варианта автоматически генерировать ключ на стороне клиента и использовать «доверенный» диспетчер доверия для создания совместимых контекстов SSL без какой-либо конфигурации?

Ответы [ 2 ]

2 голосов
/ 08 мая 2009

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

SSL действительно предназначен для решения проблемы общения с «неизвестным» сервером, отсюда и сложности сертификатов и согласования протоколов. Если проблема, которую вы пытаетесь решить, это просто отправить зашифрованные данные на известный сервер, тогда вы всегда можете сгенерировать пару ключей RSA, вставить открытый ключ в файл в банке и использовать скучный старый криптографический API для отправки и интерпретации ваших данных. Просто мысль ...!

Обновление: Я должен был упомянуть, что, во-первых, я предполагаю, что у вас есть надежные средства установки программного обеспечения на ваших клиентах. Комментатор справедливо указал, что, если это не так, то распространение открытого ключа таким способом подвергается атаке «человек посередине» (в результате MITM дает вам сглаженную банку с открытым ключом для ИХ eavesedropping сервер). Я предполагал, что это не та модель потока, от которой вы пытаетесь защитить, и что клиенты получают банку из надежного источника (например, инженер из компании устанавливает программу в своей системе). Если они загружают банку через Интернет, отправляют ее по электронной почте и т. Д., Вы все равно захотите подписать банку с сертификатом, выданным ЦС, даже если в вашем действительном коде, вы можете использовать открытый ключ, который вы распределили в банке для подключения.

1 голос
/ 12 мая 2009

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

Анонимный (и устаревший) набор шифров, такой как "TLS_DH_anon_WITH_AES_128_CBC_SHA", обеспечивает конфиденциальность. Однако эта конфигурация уязвима для атак "человек посередине" . В некоторых внутренних сетях он может быть безопасным, но в целом для аутентификации необходим некоторый сложный протокол блокировки на прикладном уровне.


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

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