サーバーとAndroidクライアント間の通信にapache minaを使用しています。安全でない接続を介して接続していたときはすべて問題ありませんでしたが、数日前にsslを使用して接続を保護することにしました. Apache mina には、タスクを実行するために設計された SslFilter と呼ばれるフィルターがあります。これは、安全な接続を確立するためにキーストアとトラストストアを提供する SSL コンテキストを使用します。PC用に書かれたクライアントでminaでsslfilterを使用している場合、すべてが魅力のように機能しますが、Androidで使用しようとしている場合、これはそれほど単純ではありません。最初に、サーバーの SUN 形式の keystore から抽出した証明書をインポートし、それを変換して、弾力性のあるキャッスル プロバイダーに一致させる必要があります。これは、keytool と適切なコマンドを使用して簡単に実現できます。その後私は'
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 - セッション サーバー 3 : 最初のハンドシェイクの開始 260646 [NioProcessor-1] DEBUG SslHandler - セッション サーバー 3 が NEED_UNWRAP 状態を処理中 260703 [NioProcessor-1] DEBUG SslFilter - セッション サーバー 3: メッセージ受信 : HeapBuffer[ =0 lim=78 cap=2048: 16 03 01 00 49 01 00 00 45 03 01 C4 C4 C4 C4 80...
260710 [NioProcessor-1] DEBUG SslHandler - NEED_WRAP 状態を処理するセッション Server3
260711 [NioProcessor-1] DEBUG SslFilter - セッション サーバー 3: メッセージの書き込み: 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 - セッション サーバー 3 が NEED_UNWRAP 状態を処理しています 260712 [NioProcessor-1] DEBUG SslFilter - セッション サーバー 3: SSL データを処理しています 260867 [NioProcessor-1] DEBUG SslFilter - セッション サーバー 3: 受信したメッセージ: 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 - NEED_UNWRAP 状態を処理するセッション Server3 260869 [NioProcessor-1] DEBUG SslHandler - NEED_TASK 状態を処理するセッション Server3
260876 [NioProcessor-1] DEBUG SslHandler - セッション サーバー 3 が NEED_UNWRAP 状態を処理中 260877 [NioProcessor-1] DEBUG SslFilter - セッション サーバー 3: SSL データを処理中=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 - NEED_UNWRAP 状態を処理するセッション Server3 261154 [NioProcessor-1] DEBUG SslHandler - NEED_WRAP 状態を処理するセッション Server3
261157 [NioProcessor-1] DEBUG SslFilter - セッション サーバー 3: メッセージの書き込み: WriteRequest : HeapBuffer[pos=0 lim=6 cap=8: 14 03 01 00 01 01] 261158 [NioProcessor-1] DEBUG SslHandler - NEED_WRAP を処理するセッション サーバー 3州
261159 [NioProcessor-1] DEBUG SslFilter - セッション サーバー 3: メッセージの書き込み: 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 - セッション サーバー 3 が FINISHED 状態を処理しています 261160 [NioProcessor-1] DEBUG SslHandler - セッション サーバー 3 が保護されました 261160 [NioProcessor-1] DEBUG SslHandler - セッション サーバー 3 が FINISHED 状態を処理しています 261161 [NioProcessor-1] DEBUG SslHandler - セッション サーバー 3 は現在保護されています 261161 [NioProcessor-1] DEBUG SslFilter - セッション サーバー 3: SSL データの処理
ご覧のとおり、すべて問題ありません。
261160 [NioProcessor-1] DEBUG SslHandler - セッション サーバー 3 が保護されました 261160 [NioProcessor-1] DEBUG SslHandler - セッション サーバー 3 が FINISHED 状態を処理しています
上記のリストは、接続が保護されたことを示しています。成功 ！！やばい!! SSL の「ダンス」が成功した後、Android クライアントは PC クライアントと同じようにメッセージを送信しようとしますが、何も起こりません。何もありません..SslFiterエンコーディングメソッドの呼び出しのどこかでアプリケーションがハングします..サーバーはメッセージを受信しません。Android の ssl にはいくつか問題があると聞きましたが、その可能性はありますか?
重要な注意事項が 1 つあります。サーバーのプロバイダーも変更しようとしました。BouncyCastle セキュリティ プロバイダーを Java 拡張プロバイダーにインポートして、Android で使用されているプロバイダーと一致させ、それを java.security に登録しました。PC クライアントでも結果は同じです。まだSUNプロバイダーを使用しているサーバーは、BouncyCastleプロバイダーを使用してサーバーと正常に通信できます-そうではないことを確認しました。
上記、注記は無効です。プロバイダーをサーバー上のBCに変更したことは確かでしたが、そうではないことがわかりました。実際、apache mina は SSLContext の作成に関する詳細を隠しており、コンテキストはデフォルトのプロバイダーである Sun プロバイダーを使用して作成されています (BKS 形式のストアが SUN プロバイダーによってどのように正しくロードされるのか、少し混乱しています)。**実際、私の PC では TSL と BouncyCastle プロバイダーを使用する SSLContext を作成できません。
SSLContext cdt = SSLContext.getInstance("TLS", new BouncyCastleProvider());
また
SSLContext cdt = SSLContext.getInstance("TLS", "BC");
「 java.security.NoSuchAlgorithmException: no such algorithm: TLS for provider BC 」という例外が発生します。これは、BC が JCE プロバイダーであり、SSLContext が JSSE に属しているためと思われます。そのため、データ交換時の暗号化中にプロバイダー固有のアルゴリズムがいくつか異なるため、Android「bcプロバイダー」-サーバー「sunプロバイダー」通信に問題があるという私の仮定を証明しませんでした.**
mina、android、sslで同様の問題に直面したことがある人がいれば、アドバイスをいただければ幸いです...