• Registered: 2024-08-25
  • Posts: 4

Topic: 30x Higher Server Response Time for TLS_DHE_RSA_AES256_GCM_SHA256

Hello,

currently, I am writing my master thesis on benchmarking different TLS libraries on their response time.
Basically, I measure the time on TCP level that the TLS server takes to respond to client messages for different cipher suites and handshake flows (normal, with resumption, with OCSP, etc.)

During my testing, I observed up to 30x longer response times for the first ServerHello message when using the WolfSSL server example for TLS1.2 cipher suites with DHE key exchange compared to ECDHE key exchange. I didn't see that behaviour with other libraries (like openssl).
Also, when using the DHE cipher suites for a resumption handshake, the time consumption is only high for resumption with session ID but not for resumption with session ticket.


Below I listed some details on the testsetup and testresults. The given values are the average response time of 1000 test repetitions.
The results are also visualized here https://wg.sebastianhahn.net/nextcloud/ … 7oCndHMHob. I also marked the details in a wireshark log for comparison: https://wg.sebastianhahn.net/nextcloud/ … aQZLBXtQZ8 (this wireshark log file only shows two repetitions to keep it managable - actual .pcap file is here: https://wg.sebastianhahn.net/nextcloud/ … rkxYisLYam)

Test Setup

  • wolfssl-5.7.2, configured with ./configure --enable-all

  • Usage of ./example/server/server -p 4444 -v 3 -c <RSA2048 CERT> -k <RSA2048 KEY> -d -i -f

  • TLS library for comparison was OpenSSL 3.3.1: ./openssl s_server -cert <RSA2048 CERT> -key <RSA2048 KEY> -port 4455

  • client and server are both running on local machine

    • Operating System: Ubuntu 22.04.4

    • Kernel: Linux 5.15.0-119-generic

    • Architecture: x86-64

  • Performed 1000 TLS handshakes for each testcase to derive statistical metrics


Results for Time Consumption of Server Response to ClientHello*
* when using a resumption handshake, we also only care about the first time the server responds to client hello / for the resuming handshake, the server response time was - as expected - always very low

Testcase: TLSv1.2, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, normal handshake

  • OpenSSL: 4.934 ms

  • WolfSSL: 144.376 ms

  • WolfSSL is taking around 30x more time for sending the response

Testcase: TLSv1.2, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, Session Resumption with Session ID

  • OpenSSL: 5.147 ms

  • WolfSSL: 144.938

  • WolfSSL is taking around 28x more time for sending the response

Testcase: TLSv1.2, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, Session Resumption with Session Ticket

  • OpenSSL: 4.869

  • WolfSSL: 7.88

  • WolfSSL is not drastically taking so much more time


For comparison I did the same tests just using ECDHE instead of DHE for the key exchange. Here I don't see any significant difference either between OpenSSL and WolfSSL or within WolfSSL between no resumption or with session ID or ticket.

Testcase: TLSv1.2, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, normal handshake

  • OpenSSL: 6.283 ms

  • WolfSSL: 7.516 ms

  • Here the time usage of WolfSSL is not significantly different

Testcase: TLSv1.2, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, Session Resumption with Session ID

  • OpenSSL: 6.782 ms

  • WolfSSL: 8.437 ms

  • Here the time usage of WolfSSL is not significantly different

Testcase: TLSv1.2, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, Session Resumption with Session Ticket

  • OpenSSL: 6.292 ms

  • WolfSSL: 7.771 ms

  • Here the time usage of WolfSSL is not significantly different


It seems like that the time delay is dependent on the key exchange as we don't see it with ECDHE.
But I also find it interesting that the delay is only happening for DHE if we have no resumption or a resumption with session ID. The difference between those cases and resumption with session ticket could be how the session is treated. When using session tickets the session is usually considered stateless. But I am not sure whether this influences the internal statemachine of wolfSSL in any way that also affects the response times.

I would be very much interested whether others have seen similar artifacts.
It would be interesting to understand why this is happening and whether I should use the server example differently.
Thanks a lot!

Leonie

Share

  • Registered: 2021-07-06
  • Posts: 139

Re: 30x Higher Server Response Time for TLS_DHE_RSA_AES256_GCM_SHA256

Hello Leonie,

Thank you for your interest in wolfSSL and your extended testing.  I would strongly recommend removing --enable-all from your configure line and replacing it with: --enable-sp --enable-sp-math --enable-sp-asm --enable-intelasm.  This will enable our fastest math library, SP math, and all of our assembly speedups.  OpenSSL uses assembly by default, so this will be a more equivalent comparison.
You can also optionally add CFLAGS='-DWOLFSSL_OLD_PRIME_CHECK' for a further speedup, but this does hurt security and isn't generally recommended.

As for session tickets, we do have an internal session cache which should be enabled by default.

Thanks,
Kareem

Share

  • Registered: 2024-08-25
  • Posts: 4

Re: 30x Higher Server Response Time for TLS_DHE_RSA_AES256_GCM_SHA256

Hi Kareem,


thanks for your input. I used the new configuration setup (with all your mentioned --enable commands but without the CFLAGS='-DWOLFSSL_OLD_PRIME_CHECK') and reran the tests for a normal handshake.
The response time of the WolfSSL server improved for both ECDHE and DHE handshakes.

TLSv1.2, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, normal handshake
The ServerHello message takes 3.325 ms on average.
This time is less than half of the time WolfSSL needed with the --enable-all configuration. And it is also only half of how long OpenSSL 3.3.1 needs.

TLSv1.2, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, normal handshake
The ServerHello message takes 59.312 ms on average.
This time is just 40 % of the time WolfSSL needed with the --enable-all configuration. It is still 12x more than OpenSSL 3.3.1 for the same setting though.


Best regards,
Leonie

Share

  • Registered: 2024-08-25
  • Posts: 4

Re: 30x Higher Server Response Time for TLS_DHE_RSA_AES256_GCM_SHA256

Hi Kareem,

One other question related to the configuration.
Currently, I am using this config to include your suggestions for faster computations and to enable some other features, I am testing:

./configure CFLAGS="-DWOLFSSL_STATIC_RSA -DWOLFSSL_STATIC_DH" --enable-sp --enable-sp-math --enable-sp-asm --enable-intelasm --enable-sha512 --enable-ecc --enable-psk --enable-secure-renegotiation --enable-supportedcurves --enable-session-ticket --enable-tls13

I noticed that I cannot use a DHE key exchange (using FFDHE3072) with TLS1.3. WolfSSL seems to support this option in general as this was possible with the --enable-all configuration. For TLS1.2 it is also still possible with the above mentioned configuration.
Can you give me a hint what other configuration option I should include here?
Thanks a lot!

Share

  • Registered: 2021-07-06
  • Posts: 139

Re: 30x Higher Server Response Time for TLS_DHE_RSA_AES256_GCM_SHA256

Hi Leonie,

Thanks for the followup.  For FFDHE 3072, try defining the CFLAG HAVE_FFDHE_3072.

What size are your DH params?  Are you confident both wolf and OpenSSL are using the same size?  For wolfSSL, you should ideally use 2048, 3072 or 4096, as our code for 1024-bit is not as accelerated.

I would recommend trying WOLFSSL_OLD_PRIME_CHECK as well and seeing if it helps.

If you continue to see the same issue, it would help if you can profile your code and see which functions are taking the most time.

Thanks,
Kareem

Share

  • Registered: 2024-08-25
  • Posts: 4

Re: 30x Higher Server Response Time for TLS_DHE_RSA_AES256_GCM_SHA256

Hi Kareem,

"HAVE_FFDHE_3072" did the trick. Thanks! Now I can use the same configuration for all of my test cases.

The client configuration was the same for both libraries. Client and server agreed on a 2048 bit DH key.
As far as I see it, the libraries would even ignore a proposed "FFDHE3072" group that the client sends in the supported_group extension and send a 2048 bit key in ServerKeyExchange anyway.

With the new CFLAG "HAVE_FFDHE_3072" enabled, wolfSSL responds to a proposed FFDHE3071 in ClientHello with an according key share. But for this I haven't done any measurement comparison as OpenSSL is not using this group.

For now, I think I have a working setup and can go through all my comparison testing. Also with the other libraries.
If I have some time left at the end of the thesis, I can do a bit more digging and comparison for the different wolfSSL configuration.

Thanks a lot for your support.
Best regards,
Leonie

Share