Я использую apache mina для связи между моим сервером и клиентом Android. Все было нормально, когда я подключался через незащищенное соединение, но несколько дней назад я решил защитить соединение с помощью ssl. У Apache mina есть фильтр под названием SslFilter, предназначенный для выполнения этой задачи — он использует контекст ssl, где мы предоставляем хранилище ключей и хранилище доверенных сертификатов для установления безопасного соединения. Все работает как шарм, если я использую sslfilter с миной на клиенте, написанном для ПК, но когда я пытаюсь использовать его на андроиде - это не так просто. Сначала мы должны импортировать сертификат, извлеченный из хранилища ключей в формате SUN сервера, и преобразовать его в соответствие с провайдером надувного замка, потому что кажется, что это единственный провайдер безопасности на Android. Хорошо, я могу легко добиться этого, используя keytool и правильную команду. Затем я загружаю хранилище доверенных сертификатов в контекст в Android, как и на ПК, и после подключения к серверу (обратите внимание, что поставщиком безопасности клиента Android является BouncyCastle, а поставщиком безопасности сервера является SUN) я получаю такие журналы на сервере:
86992 [NioProcessor-3] DEBUG AuthenticationManager — сеанс закрыт: 2 260628 [NioProcessor-1] DEBUG SslFilter — добавление SSL-фильтра sslFilter в цепочку 260629 [NioProcessor-1] DEBUG SslHandler — сервер сеансов [3] (без sslEngine) Инициализация обработчик SSL 260642 [NioProcessor-1] DEBUG SslHandler — сервер сеансов [3] (без sslEngine) Инициализация обработчика SSL выполнена. 260644 [NioProcessor-1] DEBUG SslFilter — Session Server3: запуск первого рукопожатия 260646 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает состояние NEED_UNWRAP =0 lim=78 cap=2048: 16 03 01 00 49 01 00 00 45 03 01 C4 C4 C4 C4 80...] 260704 [NioProcessor-1] DEBUG SslHandler - Session Server3 Обработка полученного сообщения 260709 [NioProcessor-1 ] DEBUG SslHandler — Session Server3 обрабатывает состояние NEED_UNWRAP 260709 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает состояние NEED_TASK
260710 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает состояние NEED_WRAP
260711 [NioProcessor-1] DEBUG SslFilter — Session Server3: Сообщение о записи: WriteRequest: HeapBuffer[pos=0 lim=678 cap=1057: 16 03 01 02 A1 02 00 00 46 03 01 50 5C 17 25 F6...] 260711 [NioProcessor-1] DEBUG SslHandler — Session Server3, обрабатывающий состояние NEED_UNWRAP 260712 [NioProcessor-1] DEBUG SslFilter — Session Server3: обработка данных SSL 260867 [NioProcessor-1] DEBUG SslFilter — Session Server3: получено сообщение: HeapBuffer [pos= 0 lim=139 cap=2048: 16 03 01 00 86 10 00 00 82 00 80 10 B7 5D AC B3...] 260868 [NioProcessor-1] DEBUG SslHandler - Session Server3 Обработка полученного сообщения 260868 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает состояние NEED_UNWRAP 260869 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает состояние NEED_TASK
260876 [NioProcessor-1] DEBUG SslHandler — Session Server3, обрабатывающий состояние NEED_UNWRAP 260877 [NioProcessor-1] DEBUG SslFilter — Session Server3: обработка данных SSL 261133 [NioProcessor-1] DEBUG SslFilter — Session Server3: получено сообщение: HeapBuffer[pos =0 lim=43 cap=1024: 14 03 01 00 01 01 16 03 01 00 20 65 07 FB 0F 1B...] 261134 [NioProcessor-1] DEBUG SslHandler - Session Server3 Обработка полученного сообщения 261135 [NioProcessor-1 ] DEBUG SslHandler — Session Server3 обрабатывает состояние NEED_UNWRAP 261154 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает состояние NEED_WRAP
261157 [NioProcessor-1] DEBUG SslFilter — Session Server3: запись сообщения: WriteRequest: HeapBuffer [pos=0 lim=6 cap=8: 14 03 01 00 01 01] 261158 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает NEED_WRAP государство
261159 [NioProcessor-1] DEBUG SslFilter — Session Server3: Сообщение записи: WriteRequest: HeapBuffer[pos=0 lim=37 cap=66: 16 03 01 00 20 83 D9 81 59 21 9E 03 32 A3 49 17...] 261159 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает состояние FINISHED 261160 [NioProcessor-1] DEBUG SslHandler — Session Server3 теперь защищен 261160 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает состояние FINISHED 261161 [NioProcessor-1] DEBUG SslHandler — Session Server3 теперь защищен 261161 [NioProcessor-1] DEBUG SslFilter — Session Server3: обработка данных SSL
Как видите - все в порядке.
261160 [NioProcessor-1] DEBUG SslHandler — Session Server3 теперь защищен 261160 [NioProcessor-1] DEBUG SslHandler — Session Server3 обрабатывает состояние FINISHED 261161 [NioProcessor-1] DEBUG SslHandler — Session Server3 теперь защищен
Приведенный выше листинг показывает, что соединение теперь защищено. УСПЕХ !! УРА!! но вовсе нет, потому что после успешного SSL «танца» клиент Android пытается отправить сообщение точно так же, как клиент ПК ... и тогда ничего не происходит. Просто ничего ... приложение зависает где-то при вызове метода кодирования SslFiter ... сервер не получает никаких сообщений. Я слышал, что есть некоторые проблемы с ssl на Android. Вы думаете, что это может быть так?
Одно важное замечание. Я также попытался изменить провайдера на сервере, я импортировал провайдера безопасности BouncyCastle в провайдеров расширений java, чтобы он соответствовал провайдеру, используемому на Android, затем я зарегистрировал его в java.security. Результат тот же, даже клиент для ПК который все еще использует провайдера SUN, может успешно взаимодействовать с сервером с провайдером BouncyCastle, поэтому я убедился, что это не так.
Вышеупомянутое примечание недействительно. Я был уверен, что поменял провайдера на БК на сервере, но понял, что это неправда. На самом деле, apache mina скрывает некоторые подробности о создании SSLContext, и контекст был создан с использованием провайдера по умолчанию, который является провайдером Sun (теперь я немного запутался, как хранилище в формате BKS могло быть правильно загружено провайдером SUN тогда). ** На самом деле я не могу создать SSLContext, который использует провайдера TSL и BouncyCastle на моем компьютере.
SSLContext cdt = SSLContext.getInstance("TLS", new BouncyCastleProvider());
or
SSLContext cdt = SSLContext.getInstance("TLS", "BC");
Я получаю следующее исключение "java.security.NoSuchAlgorithmException: нет такого алгоритма: TLS для провайдера BC" - кажется, потому что BC является провайдером JCE, а SSLContext принадлежит JSSE. Таким образом, я не доказал себе свое предположение о том, что у меня есть проблемы в связи android "bc provider" и сервера "sun provider" из-за некоторых различий в алгоритмах, специфичных для провайдера, во время шифрования при обмене данными. **
Если есть кто-нибудь, кто сталкивался с подобной проблемой с mina, android и ssl, буду благодарен за любой совет...
