2012-07-05 53 views
5

問題摘要:同一個客戶端 - 服務器的配置,相同的網絡拓撲結構,相同的設備(粗體9900) - 完美的作品以及對OS 7.0但不工作如預期在操作系統7.1和安全tls連接正在由服務器關閉很短的時間後。黑莓OS 7.1安全TLS連接是很短的時間後關閉

問題:是否應該在OS 7.0和OS 7.1之間的安全連接打開方面有任何不同? RIM在7.1中修改了tls基礎設施中的任何內容嗎?在7.1中是否有可能導致過早的安全連接關閉?

我的應用程序打開一個安全的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
顯然,該問題當我使用上OS 7.1固定TLS連接(使用移動網絡或WiFi)纔會出現。在OS 7.1上打開一個非安全連接時,一切都按預期工作。

有關I使用下面的連接字符串移動網絡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
據的Wireshark捕獲我與OS 7.1模擬器,有擔保TLS連接正被關閉服務器(客戶端接收FIN)。目前我沒有服務器的私鑰,因此我無法調試tls握手,但我比以往更確定根本原因是握手。

UPDATE 4
有擔保TLS連接時下降RSA 2048 AES 256密碼套件僅OS 7.1協商出現。相同的密碼套件在OS 7.0上完美運行。另一方面,當使用DHE/DSS 768 AES 128密碼套件時,在OS 7.1上一切都按預期工作,並且連接保持穩定。它必須以某種方式與相關RSA 2048 AES 256 cipher suite.ideas?

+0

我不是專家,但可以專門爲tls連接配置服務器嗎? – 2012-07-05 21:42:52

+0

@EugenMartynov服務器配置正確。相同的服務器,運行OS5/6/7的相同客戶端 - >一切正常(安全和非安全)。 – mrvincenzo 2012-07-06 04:07:39

+0

當它返回-1(流結束)時,它是否在一致的秒數之後這樣做?你提到過「30-45」。如果你確切地說是時間的話,這暗示它正在發生某種超時。我使用的一個技巧是配置一個'奇怪'的超時,比如35秒,以幫助診斷它來自哪裏。你有沒有嘗試過使用https連接字符串? – seand 2012-07-06 06:01:39

回答

1

我終於弄清楚了RIM的幫助(你可以找到相關的票here)。所有的功勞歸功於RIM。

在OS 7.1中,創建TLS/SSL連接時的一項新安全措施。這是來自RIM文章的引用。

最近發現了一種新的攻擊,當使用CBC鏈接模式時,攻擊者可以使用竊聽和選擇明文攻擊的組合來解密TLS 1.0和SSL 3.0流量。

爲了解決這個問題,我們實施了一項符合SSL規範的更改,並被大多數瀏覽器(如Mozilla®Firefox®和Google Chrome™)廣泛採用。我們實施了一項反制措施,將TLS記錄分成兩條記錄:第一條記錄包含單個字節的數據,第二條記錄包含其餘數據,這樣可以阻止攻擊者利用此漏洞。

整篇文章可以訪問here。爲了減少與我的服務器的不兼容問題,我必須在打開連接之前將「DisableCbcSecurity = true」屬性添加到連接字符串中。

注意,這解決辦法將運行版本7.1.0.288和較高的,雖然我也因此在正常火炬9860工作運行7.1.0.267的設備。

2

我還沒有和TLS連接的工作,但對於普通插座,您可以指定在連接URL毫秒明確的超時,通過一個appender:「ConnectionTimeout = 60000」

此外,您可能會需要在套接字上添加某種ping機制,否則中間路由器最終可能會關閉連接,即使保持活動狀態。

+0

檢查它 - 相同的結果。我已經在網絡上的幾個地方看到了'ConnectionTimeout'參數,但''Connector'類API文檔中沒有提及它。它是否適用於非非tls連接? – mrvincenzo 2012-07-06 05:52:18

+0

@MrVincenzo網址參數記錄非常糟糕,您會在BB論壇帖子和開源代碼中發現很多不出現在任何官方文檔中的任何地方,所以不要讓您失望。無論你能找到什麼,試驗和錯誤都可能是必要的。 – roryf 2012-07-12 21:58:20