2012-07-05 29 views
5

Resumen del problema: configuración cliente-servidor en la misma, la misma topología de la red, mismo dispositivo (9900) - funciona perfectamente bien en OS 7.0 pero no funciona como se esperaba en OS 7.1 y la conexión segura tls está siendo cerrada por el servidor después de un tiempo muy corto.BlackBerry OS 7.1 conexión TLS asegurado se cierra después de 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, el read() bloqueo regresa con -1 (final de la secuencia se ha alcanzado) después de muy poco tiempo (10-45 segundos). Para OS 5.0-7.0, la llamada al read() permanece bloqueada hasta que llegan los datos siguientes 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 solamente cuando uso aseguré TLS conexión (ya sea utilizando la 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 que utilizo la siguiente cadena de conexión:

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

para TLS en WiFi que utilice la siguiente cadena de conexión:

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

ACTUALIZACIÓN 2:
La conexión nunca es inactivo. 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 de simulación como en el sistema operativo 7.1. 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:
Según capturas de Wireshark que he hecho con el simulador OS 7.1, la conexión TLS garantizado está siendo cerrada por el servidor (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 caída de conexión TLS garantizado aparece cuando RSA 2048 AES 256 conjunto de cifrado se negocia en OS 7.1 solamente. La misma suite de cifrado funciona perfectamente en OS 7.0.Por otro lado, al usar DHE/DSS 768 AES 128 conjunto de cifrado, todo funciona como se esperaba en OS 7.1 y la conexión se mantiene estable. Debe estar relacionado de alguna manera con RSA 2048 AES 256 suite de cifrado.ideas?

+0

No soy experto, ¿pero podría configurar el servidor especialmente para conexiones tls? –

+0

@EugenMartynov El servidor está configurado correctamente. El mismo servidor, el mismo cliente que ejecuta OS5/6/7 -> todo funciona perfectamente (tanto seguro como no seguro). – mrvincenzo

+0

Cuando devuelve -1 (final de la secuencia) ¿lo hace después de una cantidad constante de segundos? Usted mencionó "30-45". Si lo sincronizas con precisión, es una pista de que está alcanzando algún tipo de tiempo de espera. Un truco que he usado es configurar un tiempo de espera 'impar' como 35 segundos para ayudar a diagnosticar de dónde viene. ¿También ha intentado usar una cadena de conexión https? – seand

Respuesta

1

Finalmente lo he descubierto con la ayuda de RIM (puede encontrar el ticket correspondiente here). Todo el crédito va a RIM.

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

Un nuevo ataque fue descubierto recientemente que permite a un adversario para descifrar TLS 1.0 y SSL tráfico 3,0 usando una combinación de espionaje y ataque de texto 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 here.

Para resumir, 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 trabajará para dispositivos que ejecutan la versión 7.1.0.288 y superior aunque también por lo que funciona correctamente en 9860 corriendo 7.1.0.267.

2

no he trabajado con conexiones TLS, pero para enchufes normal Puede especificar un tiempo de espera en milisegundos explícita en la dirección URL de conexión, a través de un appender: "; ConnectionTimeout = 60000"

Además, es probable que necesite para 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.

+0

Lo comprobó - el mismo resultado. Ya vi el parámetro 'ConnectionTimeout' en varios lugares de la red, pero no se menciona en la documentación de la API de la clase' Connector'. ¿Funciona para ti para conexiones que no sean tuyas? – mrvincenzo

+0

@MrVincenzo los parámetros de URL están muy mal documentados, encontrará muchas publicaciones en foros de BB y códigos de código abierto que no aparecen en ninguna parte de la documentación oficial, así que no permita que esto lo desanime. Es probable que sea necesario un poco de prueba y error con lo que sea que pueda encontrar. – roryf

Cuestiones relacionadas