BlackBerry OS 7.1 secured TLS connection is closed after very short time
- by MrVincenzo
To make a long story short: Same client-server configuration, same network topology, same device (Bold 9900) - works perfectly well on OS 7.0 but doesn't work as expected on OS 7.1 and the secured tls connection is being closed by the server after a very short time.
My application opens a secured tls connection to a server. The connection is kept alive by a application layer keep-alive mechanism and remains open until the client closes it. Attached is a simplified version of the actual code that opens connection and reads from the socket. The code works perfectly on OS 5.0-7.0 but doesn't work as expected on OS 7.1.
When running on OS 7.1, the blocking read() returns with -1 (end of the stream has been reached) after very short time (10-45 seconds). For OS 5.0-7.0 the call to read() remains blocking until next data arrives and the connection is never closed by the server.
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:
Apparently, the problem appears only when I use secured tls connection (either using mobile network or WiFi) on OS 7.1. Everything works as expected when opening a non secured connection on OS 7.1.
For tls on mobile networks I use the following connection string:
connectionString = "tls://someipaddress:443;deviceside=false;ConnectionType=mds-public;EndToEndDesired";
For tls on Wifi I use the following connection string:
connectionString = "tls://someipaddress:443;deviceside=true;interface=wifi;EndToEndRequired"
UPDATE 2:
The connection is never idle. I am constantly receiving and sending data on it. The issue appears both when using mobile connection and WiFi. The issue appears both on real OS 7.1 devices and simulators. I am starting to suspect that it is somehow related either to the connection string I am using or to the tls handshake.
UPDATE 3:
According to Wireshark's captures that I made with the OS 7.1 simulator, the secured tls connection is being closed by the server (client receives FIN). For the moment I don't have the server's private key therefore I unable to debug the tls handshake.