BlackBerry OS 7.1 secured TLS connection is closed after very short time

Question

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?

I'm not expert but could be server configured specially for tls connections? — Eugen Martynov, Jul 05 '12 at 21:42
@EugenMartynov The server is configured properly. Same server, same client running OS5/6/7 -> everything works perfectly (both secured and non secured). — tonymontana, Jul 06 '12 at 04:07
When it returns -1 (end of stream) does it do so after a consistent number of seconds? You mentioned "30-45". If you time it precisely it's a hint that it's hitting some sort of timeout. A trick I've used is to configure an 'odd' timeout such as 35 sec to help diagnose where it's coming from. Also have you tried using an https connection string? — seand, Jul 06 '12 at 06:01
@seand Unfortunately, no. In my earlier tries it happened after about 30 seconds. In my last tries it happened after 10-15 seconds. No consistency here. It is worth noting that the connection is not "idle" and I constantly receive and send data on it. — tonymontana, Jul 06 '12 at 06:10
@MrVincenzo strange; so you actually get a working connection and it'll just shut itself down mid-stream for no apparent reason? Do you have control over the server it connects to? Do you see anything interesting on that side? We'll if push somes to shove you could build in a 'higher level protocol' that reconnects to resume where it left off. — seand, Jul 06 '12 at 06:15
@seand No apparent reason. Strange indeed. What's even more strange is that same device (Bold 9900) running OS 7.0 works perfectly well. It will take several days to ramp debugging process on the server side, but I hope I will find a solution before that. — tonymontana, Jul 06 '12 at 06:29
Good luck; I've dealt a lot with BB connectivity hell before (older devices that would mysteriously "max connections opened") or other strangeness — seand, Jul 06 '12 at 06:33

score 2 · Answer 1 · answered Jul 06 '12 at 00:15

2

I haven't worked with tls connections, but for plain sockets you can specify an explicit timeout in milliseconds in the connection URL, via an appender: ";ConnectionTimeout=60000"

Also, you will likely need to add some sort of ping mechanism on the socket, otherwise intermediate routers will likely shut down the connection eventually, even with keep-alive.

answered Jul 06 '12 at 00:15

Michael Donohue

11,606
5
29
44

Checked it - same result. I already saw the `ConnectionTimeout` parameter on several places on the network but there is no mention of it in the `Connector` class API documentation. Does it work for you for non non tls connections? – tonymontana Jul 06 '12 at 05:52
@MrVincenzo the URL parameters are very badly documented, you will find many in BB forum posts and open source code that don't appear anywhere in any official documentation, so don't let that put you off. A bit of trial and error with whatever you can find will likely be necessary. – roryf Jul 12 '12 at 21:58

score 1 · Accepted Answer · answered Dec 13 '12 at 10:06

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.

BlackBerry OS 7.1 secured TLS connection is closed after very short time

2 Answers2