2013-01-05 16 views
7

Ho un'API REST scritta in Java in esecuzione in JBoss. Recentemente abbiamo aggiornato la nostra JVM dalla 1.6 alla 1.7. Questo ha iniziato a causare problemi solo con i nostri client Python che si stavano connettendo. A intermittenza, i client Python hanno problemi con l'handshake. Abbiamo scritto un test molto semplice che riproduce il problema:Intermittente "sslv3 alert handshake failure" in Python

import httplib2 

for i in range(1,500): 
    print i 
    response, content = httplib2.Http(disable_ssl_certificate_validation=True).request('https://server.com:8443',) 

Dare il seguente output:

. 
. 
. 
64 
65 
66 
67 
Traceback (most recent call last): 
    File "api_test/test.py", line 6, in <module> 
    response, content = httplib2.Http(disable_ssl_certificate_validation=True).request('https://server.com:8443/rest/solidtumor/2012/id/50d3216c092c8554b8b9f384?glossary=true&api_key=APIKEY',) 
    File "/home/hostovic/api_test/httplib2/__init__.py", line 1445, in request 
    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey) 
    File "/home/hostovic/api_test/httplib2/__init__.py", line 1197, in _request 
    (response, content) = self._conn_request(conn, request_uri, method, body, headers) 
    File "/home/hostovic/api_test/httplib2/__init__.py", line 1133, in _conn_request 
    conn.connect() 
    File "/home/hostovic/api_test/httplib2/__init__.py", line 914, in connect 
    raise SSLHandshakeError(e) 
httplib2.SSLHandshakeError: [Errno 1] _ssl.c:490: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure 

La chiamata 67 ° non è riuscita in questa corsa attraverso, ma non riesce in tempi diversi ogni volta che il test è correre.

Gli altri client (Java, Groovy e Ruby) funzionano senza problemi.

Se ritorna alla JVM 1.6, i guasti si interrompono.

ho fatto un controllo OpenSSL utilizzando:

openssl s_client -connect server.com:8443 

e restituito questo:

New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA 
Server public key is 2048 bit 
Secure Renegotiation IS supported 
Compression: NONE 
Expansion: NONE 
SSL-Session: 
    Protocol : TLSv1.2 
    Cipher : EDH-RSA-DES-CBC3-SHA 
    Session-ID: 50E748EA341BB433EEBC7386C606313C2B8B86360ED71DC8F3B0A14A1579D91B 
    Session-ID-ctx: 
    Master-Key: 1007AC489D60FE2D818F71A5A6873D5BBF5B1770BEC31CDBF29D0562DB0D30A33D9EBBA8AD211B8E24B23494B20A6223 
    Key-Arg : None 
    Krb5 Principal: None 
    PSK identity: None 
    PSK identity hint: None 
    Start Time: 1357334762 
    Timeout : 300 (sec) 
    Verify return code: 0 (ok) 

Il che sembra corretto, ma non sono sicuro. Se fallisse su ogni chiamata sarebbe una cosa, ma è davvero strano che fallisca solo un momento casuale. Qualcuno ha visto questo?

risposta

5

Sto riscontrando lo stesso errore intermittente durante la connessione a Tomcat 7 (Java 1.7) con Python 2.6.

Ho iniziato a riscontrare il problema quando ho aggiornato la mia JVM dalla 1.7u1 alla 1.7u6. Da questo articolo, sembra che l'ordine di preferenza cifra è cambiato in Java:

Java 7 and Could not generate DH keypair

Prima dell'aggiornamento JVM, SSL_RSA_WITH_3DES_EDE_CBC_SHA era la cifra preferito utilizzato per la comunicazione SSL. Dopo l'aggiornamento, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA ottiene la preferenza. Il 95% delle volte la comunicazione SSL va bene. Ma il 5% delle volte, fallisce come hai descritto.

Sembra che Python abbia problemi con i cifrari Diffie-Hellman. C'è una correzione in Python 3.3:

http://bugs.python.org/issue13626

mia soluzione attuale per rimuovere la cifra Diffie-Hellman dalle mie cifre abilitati in Tomcat. Non ho provato l'aggiornamento a Python 3.3.

+1

Hai rimosso tutti i codici DHE o solo quello che hai elencato? Avevo già ridotto il mio elenco di cifre a causa di scansioni di sicurezza che si lamentavano del supporto per i cifrari deboli.Ecco l'elenco Attualmente sto usando: SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA –

+0

Ho appena tolto le cifre DHE e gli errori di handshake se ne sono andati. Grazie mille. Non sono sicuro che l'avrei trovato! –

0

Sto avendo lo stesso problema dopo l'aggiornamento da Java 6 a Java 7.

ho il debug questo un po ', e si è rivelato si tratta di un bug nella realizzazione di DHE pacchetti di crittografia Java 7 di: circa il 0,5% del SSL le handshake per le suite di crittografia DHE falliscono. (Non è correlato a Python e il bug può essere riprodotto anche con lo strumento da riga di comando "openssl")

Ho segnalato il bug a Oracle, vedere http://mail.openjdk.java.net/pipermail/security-dev/2013-May/007435.html per i dettagli. Nel frattempo, l'unica soluzione è disabilitare i pacchetti di crittografia DHE (alle estremità).

Problemi correlati