Home/ Questions/Q 8976519
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T19:09:46+00:00

Problem summary : Same client-server configuration, same network topology, same device (Bold 9900) –

  • 0

Problem summary: 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.

Question: Is there supposed to be any difference in secured tls connection opening between OS 7.0 and OS 7.1? Did RIM change anything in tls infrastructure in 7.1? Is there something that may cause premature secured tls connection closure in 7.1?

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-**secret**;EndToEndDesired";

For tls on Wifi I use the following connection string:

connectionString = "tls://someipaddress:443;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 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, but I am more sure than ever that the root cause is tls handshake.

UPDATE 4:
The secured tls connection drop appears when RSA 2048 AES 256 cipher suite is negotiated on OS 7.1 only. Same cipher suite works perfectly well on OS 7.0. On the other hand, when using DHE/DSS 768 AES 128 cipher suite, everything works as expected on OS 7.1 and the connection remains stable. It must be somehow related to RSA 2048 AES 256 cipher suite.ideas?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve finally figured it out with RIM’s help (you can find the relevant ticket here). All credit goes to RIM.

    In OS 7.1, a new security measure when creating TLS/SSL connection. Here is a quote from RIM’s article.

    A new attack was recently discovered that allows an adversary to decrypt TLS 1.0 and SSL 3.0 traffic using a combination of eavesdropping and chosen plaintext attack when CBC chaining mode is used.

    To combat this, we implemented a change that was compliant with SSL specifications and was widely adopted by most browsers such as Mozilla® Firefox® and Google Chrome™. We have implemented a counter measure where we split TLS records into two records: the first record containing a single byte of the data and the second records containing the rest of the data, which stops an attacker from exploiting this vulnerability.

    Full article can be accessed here.

    To make a long story short, in order to reduce incompatibility issues with my server I had to add “DisableCbcSecurity=true” attribute to the connection string before I opened the connection.

    Note that this workaround will work for devices running version 7.1.0.288 and higher though I also so it working properly on Torch 9860 running 7.1.0.267.

    • 0