Controllo SSL Priorità / Ordine per Tomcat per evitare l'attacco BEAST

Con il recente buzz circa la vulnerabilità di SSL BEAST volevo cercare di migliorare la sicurezza di un sito web protetto da SSL basato su Tomcat 6. A tal fine ho provato l'approccio google per dare priorità a cifrature non bloccate con blocchi di block (Cipher Block Chaining) nel mio file server.xml di Tomcat nella dichiarazione del connettore HTTP:

cifrari = "TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA"

  • Come posso distriggersre TLS 1.0 senza rompere il RDP?
  • Rendi il firefox più accettabile dei self-signed SSL certs
  • Riavviare se il servizio tomcat7 non risponde
  • Come disattivo il supporto SSL 2.0 su IIS?
  • mod_jk o mod_proxy
  • certificato ssl autenticato invece di valido
  • Ma Tomcat non sembra usare l'ordine delle cifre, ma sembra invece scegliere la migliore cifra basata sulla forza chiave. Inoltre SSL Labs indica che il mio sito non mostra una preferenza di cifratura, mentre google.com fa. Non voglio rimuovere le cifre CBC a 256 bit per utilizzare la cifra RC4 a 128 bit per timore di incompatibilità SSL. Sto ipotizzando che la selezione del cifrario sia eseguita allo strato Java JSSE e non in Tomcat.

    Qualcuno sa di un modo semplice per personalizzare la priorità / ordine delle cifre SSL con il connettore HTTP Tomcat standard? C'è un modo per raggiungere questo objective utilizzando una semplice class java personalizzata? Il connettore Tomcat APR e alcune opzioni di configuration openSSL offrono un'alternativa. C'è un altro modo semplice per farlo?

    Tieni presente che questo attacco richiede uno scripting cross site o un'altra vulnerabilità simile, e non è così grave (per il mio sito). Tuttavia, se ci sono facili passi per mitigare questo attacco, li prendo. Inoltre, non voglio introdurre un frontale di Apache (supponendo che esista un modo per fare questo in Apache) a causa della complessità e quindi del rischio.

  • apache: nome mix e host virtuali basati su ip e ssl
  • Grande networking VPN (~ 600 server) con OpenVPN
  • routing traffico tra due tabs di networking attraverso firewall
  • Come specificare quale server DHCP per get il nome server?
  • Che contatori wmi può indicare l'esaurimento della port
  • Posso utilizzare i certificati RSA e ECC in apache?
  • 4 Solutions collect form web for “Controllo SSL Priorità / Ordine per Tomcat per evitare l'attacco BEAST”

    Ho lo stesso problema. Sembra che non possiamo fare quello che vogliamo.
    L'implementazione di Java SSL di Sun (Oracle) controlla solo l'ordine del client cipher side side (priorità) e ignora il lato server.

    Le classi correlate sono:
    sun.security.ssl.ServerHandshaker
    sun.security.ssl.CipherSuite

    Su ServerHandshaker,
    "void private chooseCipherSuite (ClientHello mesg)"
    http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/security/sun/security/ssl/ServerHandshaker.java.htm

    /* * Choose cipher suite from among those supported by client. Sets * the cipherSuite and keyExchange variables. */ private void chooseCipherSuite(ClientHello mesg) throws IOException { for (CipherSuite suite : mesg.getCipherSuites().collection()) { if (isEnabled(suite) == false) { continue; } if (doClientAuth == SSLEngineImpl.clauth_required) { if ((suite.keyExchange == K_DH_ANON) || (suite.keyExchange == K_ECDH_ANON)) { continue; } } if (trySetCipherSuite(suite) == false) { continue; } return; } fatalSE(Alerts.alert_handshake_failure, "no cipher suites in common"); } 

    Possiamo vedere che icanvastes suite cipher nel messaggio ciao client e sceglie suite di cifratura.

    Durante la stretta di mano il client invia le preferite suite di cifratura e il server sceglie il più forte che entrambi possono supportre.
    Non sono sicuro di quale ordine ti aspetti.

    Inoltre SSL Labs indica che il mio sito non mostra una preferenza di cifratura, mentre google.com fa

    Non riesco a capire cosa intendi qui.
    Che cosa è esattamente la denuncia? Che dalle cifre abilitate, Tomcat ha scelto una settimana less di quanto si suppone?

    Non credo che tu possa ordinare loro in base alle preferenze e una volta che ti liberi di quelli CBC, c'è una list estremamente breve di opzioni di cifratura disponibili! Tuttavia, la maggior parte dei clienti sta per connettersi a RC4-128 in qualsiasi modo – alless questo è ciò che tutti i miei log del server indicano quando mi sento come triggersre questa opzione di logging.

    Utilizzando il connettore OpenSSL, è ansible utilizzare una syntax più concisa per consentire o distriggersre certe cifre, ma non esistono opzioni per impostare l'ordine di cifratura o anche la cifra preferita.

    A partire da Tomcat 6.0.37 / 7.0.30 / 8.0.x, il connettore nativo / APR / OpenSSL support l'impostazione di configuration SSLHonorCipherOrder che consente al server di avere un ordine specificato in cui vengono scelte le cifre. Quel sorting è a voi e non si basa su definizioni fuzzy come "forza", poiché una cifra ad alto bit può essere peggiore di una cifra a basso bit in determinate situazioni.

    Così, in questi giorni , Tomcat può far valere un sorting preferito delle vostre suite di cifratura, ma deve ancora utilizzare il connettore nativo / APR / OpenSSL per farlo (il connettore basato su JSSE non può far valere il tuo ordine).

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.