(Disclaimer: io sono in alcun sforzo di immaginazione un esperto di sicurezza, né un esperto di Windows per questo)TLSv1 mancata stretta di mano
Setup:
- server sul nostro fine: java 1.6 (già aggiunto BouncyCastle al file di sicurezza) in Windows Server 2003 client
- terzi: Windows Server 2008 con BizTalk
- tutte le proprietà di sistema rinegoziazione introdotte a causa dell'attacco di rinegoziazione sono "abilitati" sul lato server (non è sicuro lo so)
Idealmente vogliamo risolvere questo problema alla nostra estremità, ma è possibile proporre una soluzione al cliente se necessario.
server diIl cliente deve collegarsi al nostro server tramite una connessione HTTPS ma fallisce sempre, Wireshark mostra la seguente conversazione:
> TLSv1: Client Hello
< TLSv1: Alert (21): Unexpected Message
Come per la RFC (http://www.ietf.org/ rfc/rfc2246.txt) l'avviso (21) si riferisce a una decifrazione fallita e da quello che posso vedere in wireshark, nessuno dei codici proposti dal client è effettivamente supportato da JRE 1.6 (come da http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuites) Nel tentativo di riprodurre l'errore per poterlo esaminare più da vicino, ho provato con qualche altro software:
- wfetch su windows xp con "https" selezionato eseguirà l'handshake iniziale del client in SSLv2, il server passerà a TLSv1 per rispondere, questo funziona
- wfetch su windows xp con configurato per utilizzare "TLSv1" per l'iniziale stretta di mano sarà non riuscire nello stesso modo del server BizTalk
- WFetch su Windows 2008 con "https" configurati utilizzerà "TLSv1" per la stretta di mano iniziale e non riuscire nello stesso modo del server BizTalk
- IE (su Windows XP) sarà inizialmente provo un handshake TLSv1 con lo stesso risultato fallito, ma proverò di nuovo usando SSLv3 che funziona con (a questo punto immagino che tutti i software Microsoft usino una configurazione centrale disponibile su HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentCo ntrolSet \ Control \ SecurityProviders \ Schannel)
- Firefox utilizza SSLv3 per l'intera conversazione, quindi nessun problema
- OpenSSL esegue un handshake iniziale in SSLv2, e il server passa a TLSv1 quando risponde, nessun problema
- OpenSSL può essere costretto a fare l'handshake iniziale in TLSv1 pure, offre una lista di 27 cifre (in contrasto con le 11 cifre proposte da un software basato su Windows) e in grado di connettersi senza problemi
con mia non addestrato eye this rafforza l'idea che una proposizione di cifratura incompatibile è la causa principale in cui Windows supporta solo le suite di cifratura non sono supportati da JVM (per TLSv1). Ho installato bouncy castle come provider aggiuntivo nel file java.security senza alcun risultato. Ho cercato in alto e in basso e ho trovato solo un riferimento che forse websphere supporta i codici di Windows per TLSv1 ma non c'è modo di scaricare un provider standalone per testarlo. JRE 1.7 non è supportato dal software che eseguiamo sulla nostra JVM, quindi l'aggiornamento non è un'opzione (forse il provider di sicurezza può essere declassato in sicurezza?Non ho ancora trovato un download per questo però) Non ho trovato alcun modo di aggiungere un cifrario a Windows senza scrivere codice C++ (ho giocato con le impostazioni di registro sopra menzionate senza effetto).
Quindi, in conclusione mi chiedo se una delle seguenti cose avrebbero risolto il problema e come devono essere realizzati:
- aggiungere un provider per la JVM che può lavorare con le cifre per TLSv1 che vengono proposti da finestre
- qualche modo costringere il cliente a fare l'handshake iniziale in SSLv3 (preferibilmente non SSLv2) o almeno riprovare se la stretta di mano non riesce TLSv1
- in qualche modo aggiungere un cifrario JVM supportato per TLSv1 alle finestre client
Anche altre soluzioni sono ovviamente apprezzate.
EDIT
La versione Java è Java version (64 bit): 1.6.0_19-b04.
L'elenco delle cifre proposte è:
- TLS_RSA_WITH_RC4_128_MD5
- TLS_RSA_WITH_RC4_128_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_DES_CBC_SHA
- TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
- TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
- TLS_RSA_EXPORT_WITH_RC4_40_MD5
- TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- TLS_DHE_DSS_WITH_DES_CBC_SHA
- TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
sono installati i file dei criteri di crittografia forza illimitata. Ho provato a impostare javax.net.debug=all e ho avviato il server dalla console, nessun output aggiuntivo è apparso. Ho impostato sun.security.ssl.allowUnsafeRenegotiation=true senza alcun risultato.
EDIT 2
Si scopre il software che stiamo usando utilizza uno stack personalizzato per HTTPS al posto del default. È stata emessa una correzione che sembra risolvere il problema anche se non so esattamente quale parte della richiesta TLS ha attivato l'errore (visto che la maggior parte degli handshake TLSv1 ha avuto esito positivo).
Grazie per il feedback, è stata una ricerca interessante se inutile. Vivere e imparare.
Puoi mostrare un elenco di codici che il cliente sta proponendo? – Jonathan
Qual è la versione completa di Java che stai utilizzando? Inoltre: si dispone dei file dei criteri di Crittografia illimitata resistenza installati in Java Runtime? –
(Non è necessario aggiungere il provider BouncyCastle in generale.) Se questa applicazione utilizza 'HttpsUrlConnection', provare ad impostare questa proprietà di sistema:' https.protocols = SSLv3, TLS'. Solo per provare alcune altre cose: 'sun.security.ssl.allowUnsafeRenegotiation = true' (non raccomandato, nel caso ...). Sarebbe anche utile vedere se ci sono più dettagli quando si attiva il debugging: 'javax.net.debug = all' o almeno' javax.net.debug = handshake'. – Bruno