5

問題の概要：同じクライアントサーバー構成、同じネットワークトポロジ、同じデバイス（太字9900）-OS 7.0では完全に機能しますが、OS 7.1では期待どおりに機能せず、セキュリティで保護されたTLS接続がサーバーによって非常に閉じられています短時間。

質問：OS7.0とOS7.1の間でセキュアなTLS接続の開始に違いがあると思われますか？RIMは7.1のtlsインフラストラクチャで何かを変更しましたか？7.1でSSL接続が早期に保護される原因となる可能性のあるものはありますか？

私のアプリケーションは、サーバーへのセキュリティで保護されたTLS接続を開きます。接続は、アプリケーション層のキープアライブメカニズムによって維持され、クライアントが接続を閉じるまで開いたままになります。添付されているのは、接続を開き、ソケットから読み取る実際のコードの簡略化されたバージョンです。コードはOS5.0-7.0で完全に機能しますが、OS7.1では期待どおりに機能しません。

OS 7.1で実行している場合、非常に短い時間（10〜45秒）後にブロッキングが-1read() （ストリームの終わりに達した）で戻ります。OS 5.0-7.0の場合、次のデータが到着し、サーバーによって接続が閉じられるまで、への呼び出しはブロックされたままになります。read()

Connection connection = Connector.open(connectionString);
connInputStream = connection.openInputStream();
while (true) {
    try {
        retVal = connInputStream.read();
        if (-1 == retVal) {
            break;   // end of stream has been reached
        }

    } catch (Exception e ) {
        // do error handling
    }

    // data read from stream is handled here
}

更新1：
どうやら、この問題は、OS 7.1でセキュリティで保護されたTLS接続（モバイルネットワークまたはWiFiのいずれかを使用）を使用している場合にのみ発生します。OS 7.1でセキュリティで保護されていない接続を開くと、すべてが期待どおりに機能します。

モバイルネットワークのTLSには、次の接続文字列を使用します。

connectionString = "tls://someipaddress:443;deviceside=false;ConnectionType=mds-**secret**;EndToEndDesired";

WifiのTLSには、次の接続文字列を使用します。

connectionString = "tls://someipaddress:443;interface=wifi;EndToEndRequired"

更新2：
接続がアイドル状態になることはありません。私は常にデータを送受信しています。この問題は、モバイル接続とWiFiの両方を使用している場合に発生します。この問題は、実際のOS7.1デバイスとシミュレータの両方で発生します。私はそれが接続文字列またはtlsハンドシェイクのいずれかに何らかの形で関連しているのではないかと疑い始めています。

更新3：
OS 7.1シミュレーターで作成したWiresharkのキャプチャによると、セキュリティで保護されたtls接続がサーバーによって閉じられています（クライアントはFINを受信します）。今のところ、サーバーの秘密鍵を持っていないため、tlsハンドシェイクをデバッグできませんが、根本的な原因はtlsハンドシェイクであるとこれまで以上に確信しています。

更新4：RSA 2048 AES256暗号スイートがOS7.1でのみネゴシエートされると
、セキュリティで保護されたtls接続ドロップが表示されます。同じ暗号スイートは、OS7.0で完全に機能します。一方、DHE / DSS 768 AES 128暗号スイートを使用する場合、すべてがOS 7.1で期待どおりに機能し、接続は安定したままです。RSA 2048 AES 256暗号スイート.ideasに何らかの形で関連している必要がありますか？

4

2 に答える 2

2

私はtls接続を使用していませんが、プレーンソケットの場合、アペンダーを介して接続URLでミリ秒単位の明示的なタイムアウトを指定できます： "; ConnectionTimeout = 60000"

また、ソケットに何らかのpingメカニズムを追加する必要がある可能性があります。そうしないと、キープアライブを使用している場合でも、中間ルーターが最終的に接続をシャットダウンする可能性があります。

于 2012-07-06T00:15:27.503 に答える
1

私はついにRIMの助けを借りてそれを理解しました（関連するチケットはここにあります）。すべてのクレジットはRIMに送られます。

OS 7.1では、TLS/SSL接続を作成する際の新しいセキュリティ対策。これがRIMの記事からの引用です。

最近、CBCチェーンモードが使用されている場合に、盗聴と選択平文攻撃の組み合わせを使用して、攻撃者がTLS1.0およびSSL3.0トラフィックを復号化できる新しい攻撃が発見されました。

これに対抗するために、SSL仕様に準拠し、Mozilla®Firefox®やGoogleChrome™などのほとんどのブラウザで広く採用されている変更を実装しました。TLSレコードを2つのレコードに分割する対策を実装しました。最初のレコードには1バイトのデータが含まれ、2番目のレコードには残りのデータが含まれます。これにより、攻撃者がこの脆弱性を悪用するのを防ぎます。

記事全文はこちらからアクセスできます。

簡単に言うと、サーバーとの非互換性の問題を減らすために、接続を開く前に、接続文字列に「 DisableCbcSecurity=true 」属性を追加する必要がありました。

この回避策は、バージョン7.1.0.288以降を実行しているデバイスで機能しますが、7.1.0.267を実行しているTorch9860でも正しく機能することに注意してください。

于 2012-12-13T10:06:01.583 に答える