BlackBerry OS 7.1 zabezpieczone połączenia TLS jest zamknięty po bardzo krótkim czasie

Question

Problem podsumowanie: samej konfiguracji klient-serwer, sama topologia sieci, samo urządzenie (Bold 9900) - działa doskonale na OS 7,0 ale nie działa jak oczekiwano na OS 7,1 i zabezpieczonych TLS połączenie jest zamknięte przez serwer po bardzo krótkim czasie.

Pytanie: Czy nie powinno być żadnej różnicy w zabezpieczonej otwarcia połączenia TLS między OS 7.0 i OS 7.1? Czy RIM zmienił coś w infrastrukturze TLC w wersji 7.1? Czy jest coś, co może spowodować przedwczesne i bezpieczne zamknięcie połączenia TLC w 7.1?

Moja aplikacja otwiera bezpiecznego połączenia TLS z serwerem. Połączenie jest utrzymywane przy życiu przez mechanizm utrzymywania aktywności warstwy aplikacji i pozostaje otwarte do momentu zamknięcia przez klienta. Załączona jest uproszczona wersja rzeczywistego kodu, który otwiera połączenie i czyta z gniazda. Kod działa doskonale w systemie OS 5.0-7.0, ale nie działa zgodnie z oczekiwaniami na OS 7.1.

Podczas pracy w OS 7.1 blokujących read() powraca z -1 (koniec strumienia został osiągnięty) Po bardzo krótkim czasie (10-45 sek). W systemie OS 5.0-7.0 wywołanie read() pozostaje blokowane, dopóki nie pojawią się następne dane, a połączenie nie zostanie nigdy zamknięte przez serwer.

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:
Najwyraźniej, problem pojawia się tylko gdy używam zabezpieczone TLS połączenie (przy użyciu sieci komórkowej lub WiFi) na OS 7.1. Wszystko działa zgodnie z oczekiwaniami podczas otwierania niezabezpieczonego połączenia w systemie OS 7.1.

Dla TLS w sieciach mobilnych używam następujący ciąg połączenia:

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

Dla TLS Wifi używam następujący ciąg połączenia:

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

UPDATE 2:
Połączenie nigdy nie jest bezczynny. Cały czas otrzymuję i przesyłam dane na jego temat. Problem pojawia się zarówno podczas korzystania z połączenia mobilnego, jak i WiFi. Problem pojawia się zarówno na prawdziwych urządzeniach z systemem operacyjnym 7.1, jak i na symulatorach. Zaczynam podejrzewać, że jest on w jakiś sposób powiązany z łańcuchem połączenia lub z uzgadnianiem tls.

UPDATE 3:
Według przechwytuje Wireshark, że zrobiłem z symulatorem OS 7.1 zabezpieczone połączenia TLS jest zamknięte przez serwer (klient otrzymuje FIN). Na razie nie mam prywatnego klucza serwera, dlatego nie mogę debugować uścisku dłoni tls, ale jestem bardziej niż kiedykolwiek przekonany, że podstawową przyczyną jest uścisk dłoni tls.

UPDATE 4:
Zamocowana spadek połączenia TLS pojawia się, gdy RSA 2048 szyfr AES 256 apartament jest negocjowana na OS 7.1 tylko. Ten sam zestaw szyfrów działa doskonale na OS 7.0.Z drugiej strony przy korzystaniu z zestawu algorytmów szyfrowania DHE/DSS 768 AES 128 wszystko działa zgodnie z oczekiwaniami na OS 7.1, a połączenie pozostaje stabilne. To musi być jakoś związane z RSA 2048 AES 256 cipher suite.ideas?

Answer 1

W końcu dowiedziałem się o tym z pomocą RIM (można znaleźć odpowiedni bilet here). Cały kredyt trafia do RIM.

W systemie operacyjnym 7.1, nowy środek bezpieczeństwa podczas tworzenia połączenia TLS/SSL. Oto cytat z artykułu RIM.

Nowy atak został niedawno odkryto, że pozwala przeciwnikiem odszyfrować TLS 1.0 i SSL 3.0 ruch za pomocą kombinacji podsłuchiwania i atak z wybranym tekstem jawnym, gdy używany jest tryb łączenia CBC.

Aby temu zaradzić, wprowadziliśmy zmianę, która była zgodna ze specyfikacjami SSL i została powszechnie przyjęta przez większość przeglądarek, takich jak Mozilla® Firefox® i Google Chrome ™. Wdrożyliśmy środek zaradczy, w którym podzieliliśmy rekordy TLS na dwa rekordy: pierwszy rekord zawierający jeden bajt danych i drugi rekord zawierający resztę danych, co uniemożliwia osobie atakującej wykorzystanie tej luki.

Pełny artykuł jest dostępny pod numerem here.

W skrócie, aby zmniejszyć problemy z niezgodnością z moim serwerem, musiałem dodać atrybut "DisableCbcSecurity = true" do ciągu połączenia, zanim otworzyłem połączenie.

Zauważ, że ten obejście będzie działać na urządzeniach z systemem w wersji 7.1.0.288 i wyższy chociaż ja też tak to działa poprawnie na Torch 9860 działa 7.1.0.267.

Answer 2

ja nie pracowałem z połączeń TLS, ale dla zwykłych gniazd można określić wyraźnego limitu czasu w milisekundach w adresie URL połączenia, za pośrednictwem appender: „; ConnectionTimeout = 60000”

Również będzie prawdopodobnie potrzebować aby dodać jakiś mechanizm pingowania na gnieździe, w przeciwnym razie pośrednie routery najprawdopodobniej zamkną połączenie, nawet przy utrzymaniu aktywności.