tomcatを保護する6 apr SSLをBEAST攻撃する

Question

ネイティブのApache Portable Runtime SSLコネクタを使用してTomcat 6上でWebアプリケーションを実行し、SSL接続を提供します。 BEAST攻撃を防ぐためにサーバーをどのように構成できますか？推奨ソリューション（1）は、SSLHonorCipherOrderパラメータ（2）を設定できないため、Tomcat設定では設定できません。

現在のところ、SSLCipherSuite = "ECDHE-RSA-AES256-SHA384：AES256-SHA256：RC4：HIGH：！MD5：！aNULL：！EDH：！AESGCM"という設定のみを使用していますが、サーバーはまだBEAST攻撃に対して脆弱です。 TomcatにApacheのプロキシを付けて問題を解決できることは分かっていますが、この変更は短期間に実装するにはあまりにも侵略的です。サポートを追加するためにTomcatにパッチを当てることもできますが、これはポリシーに反するTomcatパッケージの自動更新を妨げます。

1：https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls

2：http://tomcat.apache.org/tomcat-6.0-doc/apr.html

Answer 1

私は私の解決策の投稿はありません。これはちょっとしたハックですが、JSSEまたはTomcatをパッチ/再コンパイルする必要はありません。

次のクラスを作成します。

/* 
SSLSettingHelper prevents BEAST SSL attack by setting the appropriate option. 
Due to protected variable must be in org.apache.tomcat.util.net package... 
Instruction: 
1) Compile and place JAR in tomcat /lib 
2) Add protocol="org.apache.tomcat.util.net.SSLSettingHelper" to SSL APR connector 
*/ 
package org.apache.tomcat.util.net; 

public class SSLSettingHelper extends org.apache.coyote.http11.Http11AprProtocol { 
    @Override 
    public void init() throws Exception { 
     super.init(); 
     org.apache.tomcat.jni.SSLContext.setOptions(endpoint.sslContext, org.apache.tomcat.jni.SSL.SSL_OP_CIPHER_SERVER_PREFERENCE); 
     log.info("SSLSettingHelper set SSL_OP_CIPHER_SERVER_PREFERENCE to prevent BEAST SSL attack"); 
    } 
} 

次に、このヘルパークラスを使用してコネクタを設定：

<Connector server="Server" protocol="org.apache.tomcat.util.net.SSLSettingHelper" port="8443" maxThreads="256" scheme="https" secure="true" SSLEnabled="true" SSLCertificateFile="..." SSLCertificateKeyFile="..." SSLCertificateChainFile="..." SSLCipherSuite="ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM" compression="on" compressableMimeType="text/html,text/xml,text/plain,application/json,text/css,text/javascript" maxPostSize="1024000"/> 

これはBEAST攻撃を修正します。

Answer 2

TomcatはこのBugzillaのリンクが示すように、Tomcatの7.0.30に組み込まれているように見えるCipherOrderディレクティブを実施することであるため、この問題を解決するための論理的な方法それ以降。私はこれを試してみたいと思っています。 https://issues.apache.org/bugzilla/show_bug.cgi?id=53481

Answer 3

「SSLHonorCipherOrder」のようなプレーンなJavaを有効にするソリューションが見つかりました。 （bootclasspath）を介してオリジナルSun JSSEの一部にパッチを適用して、サーバサーバの注文を にする。

クラス：sun.security.ssl.ServerHandshaker

はメソッドchooseCipherSuiteを交換フィールド

public static boolean preferServerOrder = true;

を追加します。

private void chooseCipherSuite(final HandshakeMessage.ClientHello mesg) throws IOException { 
    if(preferServerOrder) { 
     final CipherSuiteList clientList = mesg.getCipherSuites(); 
     for(final CipherSuite serverSuite : getActiveCipherSuites().collection()) { 
      if (this.doClientAuth == 2) { 
       if (serverSuite.keyExchange == CipherSuite.KeyExchange.K_DH_ANON) continue; 
       if (serverSuite.keyExchange == CipherSuite.KeyExchange.K_ECDH_ANON) continue; 
      } 
      if(!serverSuite.isNegotiable()) continue; 
      if(clientList.contains(serverSuite)) { 
       if (trySetCipherSuite(serverSuite)) return; 
      } 
     } 
    } else { 
     final Collection list = mesg.getCipherSuites().collection(); 
     for(final CipherSuite suite : list) { 
      if (!(isNegotiable(suite))) continue; 
      if (this.doClientAuth == 2) { 
       if (suite.keyExchange == CipherSuite.KeyExchange.K_DH_ANON) continue; 
       if (suite.keyExchange == CipherSuite.KeyExchange.K_ECDH_ANON) continue; 
      } 
      if (trySetCipherSuite(suite)) return; 
     } 
    } 
    fatalSE(Alerts.alert_handshake_failure, "no cipher suites in common"); 
}