Nginx – RC4_128 to avoid BEAST

encryptionnginxopensslssl

I'm using a Verisign Extended SSL cert which is piped downstream by nginx running the default cipher suite config.

This results in a 256 bit encrypted connection.

However, since it's a CBC method, should I be concerned about a BEAST attack?

The nginx manual offers the following suggestion to drop back to RC4 (which doesn't appear to be affected by that particular attack):

ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

That's fine, but it drops the encryption back to 128 bit, too.

Is it preferable to opt for 256 bit that's vulnerable to BEAST, or 128 bit that's not (but may be vulnerable to other attacks)?

Best Answer

No, there aren't supported RC4 ciphers of a greater key length than 128 bit.

The use of this cipher as the current "best practice" might open the door a bit wider for a brute force attack against the shorter key, but is the lesser of two evils at the moment.

Related Solutions

Ssl – Control SSL Cipher Priority/Order for Tomcat to avoid BEAST attack

I have the same issue. It seems that we can't do what we want.
The Sun(Oracle) Java SSL implementation checks only the client side cipher suite order(priorities) and ignores the server side.

Related classes are:
sun.security.ssl.ServerHandshaker
sun.security.ssl.CipherSuite

On ServerHandshaker,
"private void 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");
}

We can see that it itelates cipher suites in the client hello message and chooses cipher suite.

Ssl – In Stud, which Private RSA Key should be concatenated in the x509 SSL certificate pem file to avoid “self-signed” browser warning

SSL X509 certificate file is a file containing a certificate in the format specified by the ITU in their X series of specifications - specifically x.509. There is no private-key information there as it is a certificate format so things like names, public keys, signatures, validity dates and other goodies go in there - but not private-keys.

PEM is a set of specifications for Privacy Enhanced Mail - it offers for the most part packaging standards that are build off of the PKCS specs (PKCS specs were developed by RSA and RSA labs themselves for public use to enable interoperability between various implementations - this was done again by the IETF and by the community in other arenas). You can use openssl to convert formats around - see here http://www.openssl.org/docs/apps/openssl.html . Concatenation won't help you any.

If the certificate is self-signed then it's kind of odd that a CA gave it to you - that makes me think that you are telling about feeding the Gandi CA certificate to openssl which is telling you that cert is self signed (ergo it is a root or end entity certificate but certainly not an intermediate aka chain certificate).

To address some of your points: 1 Self signed certs will always generate warnings in good clients because they lack trust until the user decides they are trustworthy (or for most users.. until Microsoft , Mozilla Foundation, Google, or Opera) decides the user should trust that CA). If your clients (browsers or whatever) have the CA stored and marked as trusted then this warning won't pop-up. 2 Possibly 3 Looks like you used the right key and CSR with Gandi 4 Looks to me like you need to load the domain key and cert and possibly CA into OpenSSL either via OS level trust configuration or via Stud configuration.

Best Answer

Related Solutions

Ssl – Control SSL Cipher Priority/Order for Tomcat to avoid BEAST attack

Ssl – In Stud, which Private RSA Key should be concatenated in the x509 SSL certificate pem file to avoid “self-signed” browser warning

Related Topic