2012-07-05 6 views
5

問題の概要が閉じていますOS 7.1と保護されたtlsで接続が非常に短時間で終了しています。ブラックベリーOS 7.1を確保TLS接続が非常に短い時間後

質問:OS 7.0とOS 7.1の間のtls接続の保護に違いはありますか? RIMは7.1のインフラストラクチャを変更しましたか? 7.1で早期に安全なtls接続が終了する可能性のあるものはありますか?

私のアプリケーションは、サーバーへのセキュリティで保護されたtls接続を開きます。この接続は、アプリケーションレイヤのキープアライブメカニズムによって維持され、クライアントがそれを閉じるまで開いたままです。接続は、ソケットから接続と読み取りを開く実際のコードの簡略化されたバージョンです。このコードはOS 5.0-7.0で完全に動作しますが、OS 7.1では期待通りに動作しません。

OS 7.1で実行している場合、ブロックread()は、非常に短い時間(10-45秒)後に-1(ストリームの終わりに達しています)を返します。 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 
} 

UPDATE 1
どうやら、問題は、私は確保TLS OS 7.1上接続を(いずれかのモバイルネットワークやWiFiを使用して)使用する場合にのみ表示されます。 OS 7.1でセキュリティで保護されていない接続を開くと、すべてが正常に動作します。私は次の接続文字列を使用無線LAN上のTLSの

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

:私は次の接続文字列を使用してモバイルネットワーク上のTLSの

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

をUPDATE 2
接続決してアイドルです。私は常にそれを受け取り、データを送信しています。この問題は、モバイル接続とWiFiの両方を使用している場合に表示されます。この問題は、実際のOS 7.1デバイスとシミュレータの両方に表示されます。私はそれが何らかの形で接続文字列かtlsハンドシェイクのいずれかに関係していると思われ始めています。

UPDATE 3
私はOS 7.1シミュレータで作られたのWiresharkのキャプチャによると、セキュアなTLS接続は、(クライアントがFINを受信)サーバーによって閉じられています。私はサーバの秘密鍵を持っていないので、tlsハンドシェイクをデバッグすることはできませんでしたが、根本的な原因がtlsハンドシェイクであることはこれまで以上に確信しています。

UPDATE 4RSA 2048 AES 256暗号スイートは、OS 7.1のみに交渉されたとき
セキュアなTLS接続ドロップが表示されます。同じ暗号スイートは、OS 7.0でもうまく機能します。一方、DHE/DSS 768 AES 128暗号スイートを使用すると、OS 7.1ですべて正常に動作し、接続は安定したままです。それは何らかの形で関連している必要がありますRSA 2048 AES 256 cipher suite.ideas?

+0

私はエキスパートではありませんが、tls接続用に特別に設定されたサーバーになる可能性がありますか? –

+0

@EugenMartynovサーバーが正しく構成されています。同じサーバー、OS5/6/7を実行している同じクライアント - >すべてが完全に動作します(セキュアと非セキュアの両方)。 – mrvincenzo

+0

-1(ストリームの終わり)を返すと、一定の秒数後に終了しますか?あなたは "30-45"と言いました。時間を正確に計ると、何らかのタイムアウトが発生するというヒントになります。私が使用したトリックは、どこから来ているのかを診断するのに役立つ35秒などの「奇妙な」タイムアウトを設定することです。また、https接続文字列を使用してみましたか? – seand

答えて

1

私はRIMの助けを借りてそれを理解しました(関連チケットhereを見つけることができます)。すべてのクレジットはRIMに送られます。

OS 7.1では、TLS/SSL接続を作成する際の新しいセキュリティ手段です。ここにRIMの記事の引用があります。

CBC連鎖モードが使用されている場合、盗聴と選択された平文攻撃の組み合わせを使用して、敵対者がTLS 1.0およびSSL 3.0トラフィックを復号することを可能にする新しい攻撃が最近発見されました。

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

全記事hereにアクセスできます。

私のサーバーとの非互換性の問題を減らすために、接続を開く前に、接続文字列に "DisableCbcSecurity = true"属性を追加する必要がありました。この回避策は、私もそれが7.1.0.267を実行しているトーチ9860上で正常に動作しても、バージョン7.1.0.288 以降を実行しているデバイスのために動作することを

は注意してください。

2

私はTLS接続で働いていませんが、プレーンなソケットのためにあなたがアペンダを経由して、接続URLにミリ秒単位で明示的にタイムアウトを指定することができます。「;のConnectionTimeout = 60000」

また、あなたはおそらく必要があります。ソケットにある種のpingメカニズムを追加する必要があります。それ以外の場合は、キープアライブであっても中間ルータが接続をシャットダウンする可能性があります。

+0

それをチェックしました - 同じ結果です。私は既にネットワーク上のいくつかの場所で 'ConnectionTimeout'パラメータを見ましたが、' Connector'クラスのAPIドキュメントにそれについて言及していません。それは非tls接続のためにあなたのために働くか? – mrvincenzo

+0

@MrVincenzo URLのパラメータが非常に詳しく記述されていないので、公式文書のどこにも載っていないBBフォーラムの投稿やオープンソースコードの多くを見つけることができます。試行錯誤の少しあなたが見つけることができる可能性が高い可能性があります。 – roryf