【发布时间】：2012-07-05 17:09:48
【问题描述】：
问题总结：相同的客户端-服务器配置、相同的网络拓扑、相同的设备（粗体 9900）- 在操作系统 7.0 上运行良好，但无法按预期运行在操作系统 7.1 上，并且安全的 tls 连接在很短的时间后被服务器关闭。
问题：OS 7.0 和 OS 7.1 之间的安全 tls 连接打开是否应该有任何区别？ RIM 在 7.1 中是否更改了 tls 基础设施中的任何内容？ 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
}
更新 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 时都会出现此问题。该问题出现在真正的 OS 7.1 设备和模拟器上。我开始怀疑它与连接字符串或 tls 握手有某种关系。
更新 3：
根据我使用 OS 7.1 模拟器进行的 Wireshark 捕获，服务器正在关闭受保护的 tls 连接（客户端收到 FIN）。目前我没有服务器的私钥，因此我无法调试 tls 握手，但我比以往任何时候都更加确定根本原因是 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 cipher suite.ideas 有关吗？
【问题讨论】：
-
我不是专家，但可以为 tls 连接专门配置服务器吗？
-
@EugenMartynov 服务器配置正确。同一台服务器，同一台运行 OS5/6/7 的客户端 -> 一切正常（安全和非安全）。
-
当它返回 -1（流结束）时，它是否会在一致的秒数后这样做？你提到了“30-45”。如果您精确计时，则暗示它正在达到某种超时。我使用的一个技巧是配置一个“奇数”超时，例如 35 秒，以帮助诊断它的来源。您是否也尝试过使用 https 连接字符串？
-
@seand 不幸的是，没有。在我之前的尝试中，它发生在大约 30 秒后。在我最后一次尝试中，它发生在 10-15 秒后。这里没有一致性。值得注意的是，连接不是“空闲”的，我不断地在上面接收和发送数据。
-
祝你好运；我以前处理过很多关于 BB 连接地狱的问题（会神秘地“打开最大连接数”的旧设备）或其他奇怪问题