BlackBerry OS 7.1 connexion sécurisée TLS est fermée après très peu de temps

Question

Résumé du problème: Même configuration client-serveur, même topologie réseau, même appareil (Bold 9900) - fonctionne parfaitement bien sur OS 7.0 mais ne fonctionne pas comme prévu sur OS 7.1 et la connexion sécurisée tls est fermée par le serveur après un très court laps de temps.

Question: Est-ce qu'il est censé y avoir une différence dans l'ouverture de la connexion tls sécurisée entre OS 7.0 et OS 7.1? Est-ce que RIM a changé quelque chose dans l'infrastructure tls en 7.1? Y a-t-il quelque chose qui pourrait provoquer une fermeture prématurée de la connexion tls sécurisée en 7.1?

Mon application ouvre une connexion tls sécurisée vers un serveur. La connexion est maintenue active par un mécanisme de keep-alive de la couche d'application et reste ouverte jusqu'à ce que le client la ferme. Ci-joint une version simplifiée du code réel qui ouvre la connexion et lit depuis le socket. Le code fonctionne parfaitement sur OS 5.0-7.0 mais ne fonctionne pas comme prévu sur OS 7.1.

Lorsqu'il est exécuté sur OS 7.1, le blocage de read() retourne avec -1 (fin du flux a été atteinte) après un très court laps de temps (10-45 secondes). Pour OS 5.0-7.0, l'appel à read() reste bloquant jusqu'à ce que les prochaines données arrivent et la connexion n'est jamais fermée par le serveur.

Connection connection = Connector.open(connectionString);
connInputStream = connection.openInputStream();
while (true) {
    try {
        retVal = connInputStream.read();
        if (-1 == retVal) {
            break;   // fin du flux a été atteinte
        }

    } catch (Exception e ) {
        // gestion des erreurs
    }

    // les données lues depuis le flux sont traitées ici
}

UPDATE 1:
Apparemment, le problème n'apparaît que lorsque j'utilise une connexion tls sécurisée (soit en utilisant le réseau mobile, soit le WiFi) sur OS 7.1. Tout fonctionne comme prévu lors de l'ouverture d'une connexion non sécurisée sur OS 7.1.

Pour tls sur les réseaux mobiles, j'utilise la chaîne de connexion suivante :

connectionString = "tls://someipaddress:443;deviceside=false;ConnectionType=mds-**secret**;EndToEndDesired";

Pour tls sur le Wifi, j'utilise la chaîne de connexion suivante :

connectionString = "tls://someipaddress:443;interface=wifi;EndToEndRequired"

UPDATE 2:
La connexion n'est jamais idle. Je reçois et envoie constamment des données dessus. Le problème apparaît aussi bien en utilisant la connexion mobile qu'en utilisant le WiFi. Le problème apparaît à la fois sur de vrais appareils OS 7.1 et sur les simulateurs. Je commence à soupçonner que cela est en quelque sorte lié soit à la chaîne de connexion soit à la poignée de main tls.

UPDATE 3:
Selon les captures de Wireshark que j'ai faites avec le simulateur OS 7.1, la connexion tls sécurisée est fermée par le serveur (le client reçoit FIN). Pour le moment, je n'ai pas la clé privée du serveur donc je ne peux pas déboguer la poignée de main tls, mais je suis plus sûr que jamais que la cause principale est la poignée de main tls.

UPDATE 4:
La chute de la connexion tls sécurisée se produit lorsque la suite de chiffrement RSA 2048 AES 256 est négociée uniquement sur OS 7.1. La même suite de chiffrement fonctionne parfaitement sur OS 7.0. En revanche, lors de l'utilisation de la suite de chiffrement DHE/DSS 768 AES 128, tout fonctionne comme prévu sur OS 7.1 et la connexion reste stable. Cela doit être en quelque sorte lié à la suite de chiffrement RSA 2048 AES 256. Des idées?

Answer 1

Je n'ai pas travaillé avec des connexions tls, mais pour les sockets normaux, vous pouvez spécifier un délai d'attente explicite en millisecondes dans l'URL de connexion, via un appender : ";ConnectionTimeout=60000"

De plus, vous devrez probablement ajouter un mécanisme de ping sur le socket, sinon les routeurs intermédiaires finiront probablement par fermer la connexion, même avec keep-alive.

Answer 2

J'ai enfin trouvé la solution avec l'aide de RIM (vous pouvez trouver le ticket correspondant ici). Tout le mérite revient à RIM.

Dans OS 7.1, une nouvelle mesure de sécurité lors de la création d'une connexion TLS/SSL. Voici une citation de l'article de RIM.

Une nouvelle attaque a récemment été découverte qui permet à un adversaire de décrypter le trafic TLS 1.0 et SSL 3.0 en utilisant une combinaison d'écoute et d'attaque par texte choisi lorsque le mode de chaînage CBC est utilisé.

Pour contrer cela, nous avons mis en place un changement conforme aux spécifications SSL et largement adopté par la plupart des navigateurs tels que Mozilla® Firefox® et Google Chrome™. Nous avons mis en place une contre-mesure où nous divisons les enregistrements TLS en deux enregistrements : le premier contenant un unique octet de données et le deuxième contenant le reste des données, ce qui empêche un attaquant d'exploiter cette vulnérabilité.

L'article complet est accessible ici.

Pour faire court, afin de réduire les problèmes d'incompatibilité avec mon serveur, j'ai dû ajouter l'attribut "DisableCbcSecurity=true" à la chaîne de connexion avant d'ouvrir la connexion.

Notez que cette astuce fonctionnera pour les appareils exécutant la version 7.1.0.288 et ultérieures, bien que je l'ai également vue fonctionner correctement sur le Torch 9860 exécutant le 7.1.0.267.