Re: TLS handshake performance

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: TLS handshake performance

Mark Thomas-2
On 18/05/2017 06:04, Christopher Schultz wrote:

> Hash: SHA256
> Mark,
> On 5/17/17 5:31 PM, Mark Thomas wrote:
>> I got asked in the corridor at TomcatCon earlier today what the
>> relative performance of the TLS handshake was with 8.5.x, the NIO
>> connector and JSSE vs OpenSSL TLS implementation.
> I'm curious about what exactly "TLS handshake" was intended to mean
> (by the person who asked the question) in this context.

They are using Tomcat in a scenario where clients are making single
requests (so keep alve doesn't help). Given that the handshake uses
asymmetric encryption which is more expensive that symmetric encryption
(which is why the handshake is used to establish a shared secret so
symmetric encryption can used for the actual data) they wanted a sense
of the performance benefit - if any - of NIO and 8.5.x with OpenSSL vs
NIO and 8.5.x with JSSE.

> The handshake itself does not perform any bulk transfer of encrypted
> data, so the negotiated cipher suite does not matter. However...
>> Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z
>> ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt
> Here the cipher suite matters very much, since the client is not only
> performing the TLS handshake but also transferring the client's
> request to the server and the server's response back to the client. >
> Support for a particular algorithm may dominate the benchmark, here.

Agreed. But it is the handshake that dominates the timings (if you add
-k to use keep-alive the req/sec are an order of magnitude higher).

The cipher suite was the default one chosen by by one of the configs (I
forget which).

The cipher suite will affect the results since it also impacts the
enctrpyion used during the handshake but for any 'reaosnably' secure
cipher suite, I'd expect similar results in terms of the relative

> What happens if you negotiate a NULL cipher for instance? Or, perform
> the TLS handshake but never make an HTTP request after connecting? I
> don't know of a tool that can do that out of the box (e.g. ab makes
> HTTP requests, not just TLS connections) but one could be written in
> Java fairly easily.
>> test.txt is a 3 byte text file.
>> The results were: JSSE:    17 reqs/sec OpenSSL: 23 reqs/sec
>> So around a 35% increase.
> I'd like to see a NULL or very low-overhead cipher under the same
> circumstances.

The test was with Tomcat trunk and the test keystore from the Tomcat PMC
private repo so you should be able to set up those tests pretty quickly.
(I did it in around 30 mins which incuded building tc-native).


>> YMMV with different versions of TLS and associated ciphers, JREs,
>> OpenSSl versions etc. >
> Noted. ;)
> - -chris
> Comment: GPGTools -
> Comment: Using GnuPG with Thunderbird -
> pFhfQw/+NGm1CNQcFZ2qVzlCZ36W+TXhaKaBcWeiSCKw60jf/utEFycONRldm5Q3
> cRM7Nbrfx1GcPwAs8ufedOtHgsAfzp6JkpzqwVFqZjUX1GODbJhz1vaNgQgB3mL8
> YlGBoLqQIRKvQNOcTYJx5bP+tbnqARu96uINH16rMT+GQUF9nIzk+ua7ec0Goe+e
> 6yO6euDrkV75uOMPArBWDDToSrQVZ9QKiliqlcYpnG2IPDMu1CGWDHZtwO1pxaLG
> aMbtqea9gAj42rw3NpFjUNxqYdN4EJHhCFjIIdVCAbiqs5BZQQAjcWjaRPniq45M
> ySsuBLNFqPj2sltlhZrdg7CEklvDbVvVgVIWZA21pw0wyfIofZnsiy+KsLo8q/wD
> gHcOF/TkQ4pAYGVoP+wh5AnQHwze2SFTJq0RE7kE0s6cohtfXeNSH/Ga6lzbJW5d
> B+vHpU8+U6X1Lpha8Hg0A1KxbP7hcANfdLTiRqZNIVMQES8p6Zh+fbIX+DlVYIFR
> WLFNmFADdlZ5msxHwRjfdQ8dtL6McwyvM3kmDQeADU/YzN80bhXmr8ZHJJUevTUJ
> cya5zcw5MmPrzdlavXhH0VKspbprPoJxrd9llRU0ra5aNfUmJ4xA79jD5VxQmNL/
> Cglw5DT8QoxG3knjZEQ8YLRj0gq0NrQXQmzowxqekfMcyNc2EGg=
> =+yjT
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]