Fastest SSL cipher implementation for Nginx if strength is NOT needed?

Solution 1:

The data in question does NOT need to be secure... prevent warning about mixing secure

I think you should probably understand the reason for these warnings instead of just trying to ignore them as best as possible. If content on a secure site is included from a insecure site it might affect the security of the original site.

The server takes on thousands of these connections per minute, so the overhead of SSL negotiation adds up.

A fast cipher will usually not reduce the overhead of the SSL negotiation significantly. The ciphers gets mainly used after the negotiation is done and has only a small performance impact. Some part of the cipher is relevant for the handshake (the key exchange) but unless you choose a very slow key exchange (see below) the main performance impact comes from the multiple round-trips inside needed for the negotiation. These can only be reduced if you support the reuse of sessions, so that a full handshake is only needed for the first request and the next time the same client connects a less expensive session resume can be done. HTTP keep-alive can help a lot too. Of course both these optimization work only if you actually have multiple requests from the same client.

There are some ciphers with very slow key exchange, which you probably don't want to use in your case. All DHE-* ciphers have a large performance impact, but have the advantage of providing forward secrecy. You get the same advantage with ECDHE ciphers without having too much of a performance impact on today's hardware, but an overhead is still there. Using ciphers like AES128-GCM-SHA256 should be a good choice both in terms of performance and in terms of security.

At the end the choice of cipher depends also on the clients you use. While RC4-SHA is fast it is considered insecure and more and more clients disable it. Thus you might and with a fast server nobody can use because browsers disabled insecure ciphers.

Solution 2:

The absolute fastest would be eNull. To include eNull in ssl_ciphers, try aNULL:eNULL:MD5:LOW:HIGH for your cipher string. Typically, however you are going to negotiate the highest supported cipher. You therefore may want to cap it by using !HIGH, but be sure to thoroughly test this. You will at least need to keep in LOW as I believe most browsers would refuse to use the null and md5 ciphers at all.

Solution 3:

Depending on your urgency you could wait for adoption of "Salsa20" and "ChaCha" in particular that is intended to be direct replacement for RC4 in terms of performance. However, right now only google Chrome and latest releases of Android OS support it on the client side and it is not in OpenSSL yet, so no servers support yet. Otherwise I agree with others on AES-IN.