2012-07-05 7 views
5

Problema sintesi: configurazione client-server stesso, stessa topologia di rete, stesso dispositivo (Bold 9900) - funziona perfettamente su OS 7.0 ma non funziona come previsto su OS 7.1 e il tls protetto la connessione viene chiusa dal server dopo un tempo molto breve.BlackBerry OS 7.1 connessione TLS protetta è chiuso dopo pochissimo tempo

Domanda: Si suppone che ci sia qualche differenza nell'apertura di connessione tls protetta tra OS 7.0 e OS 7.1? RIM ha cambiato qualcosa nell'infrastruttura tls in 7.1? C'è qualcosa che potrebbe causare la chiusura anticipata delle connessioni tls in 7.1?

La mia applicazione apre una connessione tls protetta a un server. La connessione viene mantenuta attiva da un meccanismo keep-alive del livello applicazione e rimane aperta finché il client non la chiude. In allegato è una versione semplificata del codice effettivo che apre la connessione e legge dal socket. Il codice funziona perfettamente su OS 5.0-7.0 ma non funziona come previsto su OS 7.1.

Quando si esegue su OS 7.1, il blocco read() ritorna con -1 (fine del flusso è stato raggiunto) dopo tempi molto brevi (10-45 secondi). Per OS 5.0-7.0 la chiamata a read() rimane bloccata fino all'arrivo dei dati successivi e la connessione non viene mai chiusa dal 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:
A quanto pare, il problema appare solo quando utilizzo l'assicurai TLS connessione (sia tramite rete mobile o Wi-Fi) su OS 7.1. Tutto funziona come previsto quando si apre una connessione non protetta su OS 7.1.

per TLS su reti mobili che uso la seguente stringa di connessione:

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

per TLS sul sito Wifi utilizzare la seguente stringa di connessione:

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

UPDATE 2:
Il collegamento non è mai inattivo. Ricevo e inviamo costantemente dati su di esso. Il problema appare sia quando si utilizza la connessione mobile e WiFi. Il problema si verifica sia su dispositivi e simulatori OS 7.1 reali. Sto iniziando a sospettare che sia in qualche modo collegato alla stringa di connessione o alla stretta di mano di Tls.

UPDATE 3:
Secondo la cattura di Wireshark che ho fatto con il simulatore OS 7.1, la connessione TLS protetta che viene chiusa dal server (client riceve FIN ). Per il momento non ho la chiave privata del server, quindi non riesco a eseguire il debug dell'handshake tls, ma sono più sicuro che mai che la causa principale è tls handshake.

AGGIORNAMENTO 4:
L'assicurato goccia connessione TLS appare quando RSA a 2048 AES a 256 suite di cifratura viene negoziato su OS 7.1 solo. La stessa suite di crittografia funziona perfettamente su OS 7.0.D'altra parte, quando si utilizza DHE/DSS 768 AES a 128 suite di cifratura, tutto funziona come previsto su OS 7.1 e il collegamento rimane stabile. Essa deve essere in qualche modo legato alla RSA a 2048 AES 256 suite.ideas cifratura?

+0

io non sono esperto, ma potrebbero essere di server configurato appositamente per le connessioni TLS? –

+0

@EugenMartynov Il server è configurato correttamente. Stesso server, stesso client che esegue OS5/6/7 -> tutto funziona perfettamente (sia sicuro che non protetto). – mrvincenzo

+0

Quando restituisce -1 (fine flusso) lo fa dopo un numero consistente di secondi? Hai citato "30-45". Se lo fai con precisione, è un suggerimento che stia colpendo una specie di timeout. Un trucco che ho usato è configurare un timeout "dispari" come 35 secondi per diagnosticare da dove proviene. Hai anche provato a utilizzare una stringa di connessione https? – seand

risposta

1

ho finalmente capito con l'aiuto di RIM (potete trovare il biglietto relativo here). Tutto il merito va a RIM.

In OS 7.1, una nuova misura di sicurezza durante la creazione di connessione TLS/SSL. Ecco una citazione dall'articolo di RIM.

Un nuovo attacco è scoperto recentemente che permette un avversario per decifrare TLS 1.0 e SSL 3.0 il traffico utilizzando una combinazione di intercettazioni e attacco con testo in chiaro scelto quando si utilizza la modalità di concatenamento CBC.

Per combattere questo, abbiamo implementato un cambiamento che era conforme alle specifiche SSL ed è stato ampiamente adottato dalla maggior parte dei browser come Mozilla Firefox e Google Chrome ™. Abbiamo implementato una contromisura in cui abbiamo suddiviso i record TLS in due record: il primo record contenente un singolo byte dei dati e il secondo record contenente il resto dei dati, che impedisce a un utente malintenzionato di sfruttare questa vulnerabilità.

L'articolo completo è accessibile here.

Per farla breve, al fine di ridurre i problemi di incompatibilità con il mio server ho dovuto aggiungere "DisableCbcSecurity = true" attributo alla stringa di connessione prima di aprire il collegamento.

Si noti che questa soluzione funzionerà per i dispositivi che eseguono la versione 7.1.0.288 e più alto anche se ho anche in modo che funziona correttamente su Torch 9860 in esecuzione 7.1.0.267.

2

Non ho lavorato con le connessioni TLS, ma per prese semplici è possibile specificare un timeout esplicito in millisecondi nella URL di connessione, tramite un appender: "; ConnectionTimeout = 60000"

Inoltre, si avrà probabilmente bisogno per aggiungere una specie di meccanismo di ping sul socket, altrimenti i router intermedi probabilmente chiuderanno la connessione alla fine, anche con keep-alive.

+0

Controllato - stesso risultato. Ho già visto il parametro 'ConnectionTimeout' su diversi punti della rete, ma non ci sono menzioni nella documentazione dell'API della classe' Connector'. Funziona per te per le connessioni non non Tls? – mrvincenzo

+0

@MrVincenzo i parametri dell'URL sono molto mal documentati, troverai molti post nei forum BB e codice open source che non appaiono in nessuna documentazione ufficiale, quindi non lasciare che ti scoraggi. Un po 'di tentativi ed errori con qualsiasi cosa tu possa trovare sarà probabilmente necessario. – roryf

Problemi correlati