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

nginxperformancessl

I have a use case that is the inverse of most: I'd like to implement very weak SSL ciphers in the name of performance, with the option to fall back to stronger ciphers if the client requests it.

Backstory: I have a public-facing web server that receives a giant quantity of POST traffic from thousands of remote clients, with each POST being rather small. A client will a payload once and disconnect. The server takes on thousands of these connections per minute, so the overhead of SSL negotiation adds up.

The data in question does NOT need to be secure; the reason for using HTTPS at all is because the traffic originates from a JavaScript tag on a given website, and if said site is using HTTPS, then our supplementary traffic must use HTTPS as well to prevent warning about mixing secure and insecure content. Again, the security of the data in this connection is not important at all, even if the "parent" site is SSL secured for whatever reason.

Because of this, it makes sense to me to present the weakest possible cipher to clients while maintaining full compatibility with browsers. I'd also like to offer the option to increase security to full ECDHE if requested, merely to satisfy more security-conscious clients, but definitely as a secondary option.

A few years ago, some variant of RC4 would have fit the bill, but since that is universally panned as insecure today, I'm concerned that browser compatibility may become an issue. In the wake of that – what ciphers would offer me the features I'm looking for above, with the greatest speed?

Best Answer

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.

Related Topic