ventajas - La conexión TLS segura de BlackBerry OS 7.1 se cierra después de muy poco tiempo

blackberry z10

Question

Resumen del problema : la misma configuración cliente-servidor, la misma topología de red, el mismo dispositivo (Bold 9900) funciona perfectamente en OS 7.0 pero no funciona como se esperaba en OS 7.1 y la conexión protegida tls está siendo cerrada por el servidor después de un muy poco tiempo.

Pregunta : ¿Se supone que hay alguna diferencia en la apertura segura de la conexión tls entre OS 7.0 y OS 7.1? ¿Cambió RIM algo en su infraestructura en 7.1? ¿Hay algo que pueda causar el cierre prematuro de la conexión segura en 7.1?

Mi aplicación abre una conexión segura de tls a un servidor. La conexión se mantiene activa mediante un mecanismo de mantenimiento de la capa de aplicación y permanece abierta hasta que el cliente la cierra. Se adjunta una versión simplificada del código real que abre la conexión y lee desde el socket. El código funciona perfectamente en OS 5.0-7.0 pero no funciona como se esperaba en OS 7.1.

Cuando se ejecuta en OS 7.1, la read() bloqueo read() vuelve con -1 (se ha alcanzado el final de la transmisión) después de muy poco tiempo (10-45 segundos). Para OS 5.0-7.0, la llamada a read() permanece bloqueada hasta que llegan los siguientes datos y el servidor nunca cierra la conexión.

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
}

ACTUALIZACIÓN 1 :
Aparentemente, el problema aparece solo cuando uso una conexión de tls segura (ya sea usando una red móvil o WiFi) en OS 7.1. Todo funciona como se espera al abrir una conexión no segura en OS 7.1.

Para tls en redes móviles, uso la siguiente cadena de conexión:

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

Para tls en Wifi utilizo la siguiente cadena de conexión:

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

ACTUALIZACIÓN 2 :
La conexión nunca está inactiva . Estoy recibiendo y enviando datos constantemente sobre él. El problema aparece tanto al usar la conexión móvil como WiFi. El problema aparece tanto en los dispositivos reales del sistema operativo 7.1 como en los simuladores. Estoy empezando a sospechar que de alguna manera está relacionado con la cadena de conexión o con el handshake de tls.

ACTUALIZACIÓN 3 :
De acuerdo con las capturas de Wireshark que realicé con el simulador OS 7.1, el servidor cierra la conexión protegida tls (el cliente recibe FIN ). Por el momento, no tengo la clave privada del servidor, por lo tanto, no puedo depurar el saludo de tls, pero estoy más seguro que nunca de que la causa principal es el apretón de manos.

ACTUALIZACIÓN 4 :
La conexión segura de conexión de tls aparece cuando el paquete de cifrado RSA 2048 AES 256 se negocia solo en OS 7.1. La misma suite de cifrado funciona perfectamente en OS 7.0. Por otro lado, cuando se usa el conjunto de cifrado DHE / DSS 768 AES 128 , todo funciona como se espera en OS 7.1 y la conexión permanece estable. Debe estar relacionado de alguna manera con el conjunto de aplicaciones de cifrado RSA 2048 AES 256.ideas?

Answer 1

No he trabajado con conexiones tls, pero para conectores simples puede especificar un tiempo de espera explicito en milisegundos en la URL de conexión, a través de un appender: "; ConnectionTimeout = 60000"

Además, es probable que necesite agregar algún tipo de mecanismo de ping en el socket, de lo contrario los enrutadores intermedios probablemente cerrarán la conexión eventualmente, incluso con keep-alive.

Answer 2

Finalmente lo descubrí con la ayuda de RIM (aquí puede encontrar el boleto relevante). Todo el crédito va a RIM.

En OS 7.1, una nueva medida de seguridad cuando se crea una conexión TLS / SSL. Aquí hay una cita del artículo de RIM.

Recientemente se descubrió un nuevo ataque que permite a un adversario descifrar el tráfico de TLS 1.0 y SSL 3.0 utilizando una combinación de escuchas ilegales y el ataque de texto plano elegido cuando se utiliza el modo de encadenamiento de CBC.

Para combatir esto, implementamos un cambio que cumplía con las especificaciones SSL y fue ampliamente adoptado por la mayoría de los navegadores como Mozilla® Firefox® y Google Chrome ™. Hemos implementado una contramedida en la que dividimos los registros TLS en dos registros: el primer registro contiene un solo byte de los datos y el segundo contiene el resto de los datos, lo que impide que un atacante aproveche esta vulnerabilidad.

Se puede acceder al artículo completo aquí .

Para abreviar, para reducir los problemas de incompatibilidad con mi servidor, tuve que agregar el atributo " DisableCbcSecurity = true " a la cadena de conexión antes de abrir la conexión.

Tenga en cuenta que esta solución alternativa funcionará para dispositivos que ejecutan la versión 7.1.0.288 y superior, aunque también lo hago para que funcione correctamente en Torch 9860 con 7.1.0.267.