问题摘要:相同的客户端 - 服务器配置,相同的网络拓扑,相同的设备(Bold 9900) - 在操作系统 7.0 上运行良好,但无法正常工作在操作系统 7.1 上,服务器在很短的时间后关闭了安全的 tls 连接。
问题:OS 7.0和OS 7.1之间的安全tls连接打开是否应该有任何区别? RIM是否改变了7.1中的基础设施?在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
}
更新1 :
显然,只有在OS 7.1上使用安全的 tls 连接(使用移动网络或WiFi)时才会出现问题。在OS 7.1上打开非安全连接时,一切都按预期工作。
对于移动网络上的tls,我使用以下连接字符串:
connectionString = "tls://someipaddress:443;deviceside=false;ConnectionType=mds-**secret**;EndToEndDesired";
对于Wifi,请使用以下连接字符串:
connectionString = "tls://someipaddress:443;interface=wifi;EndToEndRequired"
更新2 :
连接永远不会空闲。我一直在接收和发送数据。使用移动连接和WiFi时都会出现此问题。问题出现在真正的OS 7.1设备和模拟器上。我开始怀疑它与连接字符串或tls握手有某种关系。
更新3 :
根据Wireshark对OS 7.1模拟器的捕获,服务器关闭了安全的tls连接(客户端收到 FIN )。目前我没有服务器的私钥,因此我无法调试tls握手,但我比以往任何时候都更确定根本原因是握手。
更新4 :
当仅在OS 7.1上协商 RSA 2048 AES 256 密码套件时,将显示受保护的tls连接丢弃。相同的密码套件在OS 7.0上运行良好。另一方面,当使用 DHE / DSS 768 AES 128 密码套件时,一切都按预期在OS 7.1上运行,并且连接保持稳定。它必须以某种方式与 RSA 2048 AES 256 密码suite.ideas相关?
答案 0 :(得分:2)
我没有使用tls连接,但对于普通套接字,您可以通过appender在连接URL中指定显式超时(以毫秒为单位):“; ConnectionTimeout = 60000”
此外,您可能需要在套接字上添加某种ping机制,否则中间路由器最终可能会关闭连接,即使是保持活动状态。
答案 1 :(得分: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 及更高版本的设备,但我也在运行7.1.0.267的Torch 9860上正常运行。