Java Server, TLSv1.1 fast, TLSv1.2 extremely slow (90MByte/sec versus 4MByte/sec)

Question

The only change between tests is changing the TLS version. Behavior is the same between Chrome and FireFox.

TLSv1, and TLSv1.1 both get 90 MegaByte/sec. They get this speed on Java 6 (TLSv1), and Java 8 (TLSv1/TLSv1.1).

TLSv1.2 however drastically drops the speed. We get 4 MegaByte/sec. No ciphers were changed, no other settings, etc. Not only our dev machine, but customers have reported the same thing, Windows OS, Java 8, TLSv1.2. We are using OS X, Java 8, TLSv1.2. So it seems to be a general trend. The tests are being done on localhost, Xeon 6 core processor, SSD drive. If we don't use HTTPS we get over 200MB/sec. So 4MB/sec is just a terrible insult to what we can do.

This isn't the initial connection, or cache, or renegotiation, etc. This is just the raw transport speed. I didn't find any known java bugs on this, does anyone have any guesses?

This is what Chrome reports for the connection and cipher:

TLSv1.2

Your connection to 127.0.0.1 is encrypted with modern cryptography.

The connection uses TLS 1.2.

The connection is encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key exchange mechanism.

TLSv1.1

Your connection to 127.0.0.1 is encrypted with obsolete cryptography.

The connection uses TLS 1.1.

The connection is encrypted using AES_128_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism.

Ideas?

Answer 1

Hate answering my own question, but I just realized TLS v1.2 allowed for a newer cipher. Its the cipher that causes Java 8 to use software for handling the encryption aspect instead of using hardware acceleration, and resulting in the horrible speeds.

Disabling all the GCM ciphers on the server resulted in the same speeds as chrome used a CBC cipher.

Slow AES GCM encryption and decryption with Java 8u20

--Ben