Table of Contents

• Cipher suites and efficiency
• Setup and Methodology
  • Hardware
  • Power monitoring
  • OpenSSL
• Scenarios
  • Idle Baseline
  • Chosen Scenarios
• Hypothesis
• Results
• Conclusion

Many companies have “green” goals that mean to reduce their environmental footprint. With a common goal, it would be most beneficial to research common scenarios from an IT perspective. What if a couple of small changes in your IT environment could reduce your electrical footprint? Encryption is a fundamental part of the IT world as we know it and applicable to every company. The impact of cipher suites might not be the first thing that comes to mind when looking at your IT environment. In 2024 GO-EUC researched the time efficiency of cipher suites in different scenarios. There was an exciting efficiency improvement measured in TLS 1.3 performance versus its predecessor, TLS 1.2. The results left GO-EUC with new questions; What is the impact on power consumption, and can we reduce it with more optimized cipher suites?

Cipher suites and efficiency

TLS operates using algorithms that encrypt data through computational processes. The algorithms available vary by protocol version and required security level. A ‘Cipher Suite’ refers to the specific set of algorithms used in a connection and their configurations.

The encryption and decryption of an TLS connection consumes computational power through a computer’s Central Processing Unit (CPU). The CPU does the computation for the algorithms. These connections, from beginning to end are often referred to as ‘SSL transactions’. The computational power required for a singular transaction is insignificant in modern IT, but what if there are millions of connections to decrypt simultaneously? In this case, the impact can clog the CPU of a server and potentially cause delays in response.

TLS has gone through multiple versions, and anything before TLSv1.2 is considered legacy (TLSv1.1, TLSV1.0, SSLv3, etc.). Currently, TLSv1.2 and TLSv1.3 are widely used protocols. Some of the improvements of TLSv1.3 over its predecessor relate to efficiency. One of those improvements relates to the approach of cipher suites.

The algorithm and behavior of encrypted traffic are determined by cipher suites and their protocol (TLS 1.2 vs TLS 1.3). A negotiation between the server and the client takes place upon connection. The server supports a predetermined amount of cipher suites. The client and server need to agree on the most preferable cipher suite.

In the TLSv1.2 vs TLSv1.3: A Deep Dive into Handshake Efficiency GO-EUC research from 2024, it was determined that TLS 1.3 has up to ~56% time efficiency increase compared to TLS 1.2. Most of the improvement comes from the newer protocol, TLS 1.3. This is because of the way TLS 1.3 operates in data exchange. It uses less back-and-forth communication than TLS 1.2. Based on the workload you can further improve efficiency by selecting the cipher suite that fits your IT environment and hardware. This means that you can optimize by both selecting TLS 1.3 as the preferred protocol and gain some extra advantage by selecting the most appropriate cipher suite.

In this research the aim is to determine the difference in power consumption between both protocols and the selected cipher suites. While the 2024 research focused on data effectiveness by measuring round-trip time (RTT), this research instead will focus on the power consumed after continuous handshakes over a defined timeframe. The same cipher suites are used as in the previous research. This selection is based on the availability of cipher suites in TLS 1.3. There are five total possibilities, of which three are standardized. The TLS 1.2 cipher suites are their equivalent.

In the list below you can find an overview of the protocols and their respective cipher suites that will be used. Each letter matches the protocol counterpart.

• TLSv1.2
  • ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLSv1.3
  • AES_128_GCM_SHA256
  • AES_256_GCM_SHA384
  • CHACHA_POLY1305_SHA256

Setup and Methodology

A key challenge in this research is simulating connections in a way that ensures each handshake is unique, avoiding performance shortcuts such as session resumption, caching, or other client/server optimization mechanisms. The optimization techniques would not simulate “real users” in a lab scenario, but rather see it as a single user connecting a lot of times. Scalability is also crucial, as testing under variable loads provides better insights into handshake efficiency under stress. It proved to be a challenge to find software that meets these needs. The choice was made to develop custom software called Achilles instead.

Achilles uses a coordinator/agent architecture with a central command center that distributes data to its agents. This data includes the target and specified cipher suite/protocol, enabling the simulation of many unique handshakes. From a research perspective, it is essential to make both the results and methodology accessible, so the source code has been made publicly available. Please note that Achilles is intended solely for research purposes and is not a commercial product. The Achilles repository can be found here.

Achilles will be used to simulate handshakes for a duration of time, based on the amount of agents. The load will be as follows:

Active Load = Agent Count * Duration (5 min) * Handshakes per second

The active load is then sent towards a NetScaler, which will answer with a simple webpage per request. The NetScaler will be deployed on Lenovo NUC 2, while Rocky Linux will be deployed on Lenovo NUC 1. Both Lenovo NUC’s will be plugged into power monitoring adapters to monitor the data.

Achilles initiates the simulation by triggering the deployed agents. These agents then perform handshakes with the SSL virtual server on the NetScaler, which responds with a webpage. Both the NetScaler and the Rocky Linux VM are plugged into the Shelly Plug adapters that transmit their data to a central server for collection. This setup allows the power consumption of both the client and server to be monitored.

Hardware

The methodology setup consists of four devices (auxiliary devices excluded; e.g. switch):

• Lenovo NUC 1: Hosts Rocky Linux for agent deployment
• Lenovo NUC 2: Hosts a NetScaler VPX
• Shelly Plug 1: Electrical socket for measuring power consumption
• Shelly Plug 2: Electrical socket for measuring power consumption

Lenovo NUC 1 and Lenovo NUC 2

Shelly Plug 1 and Shelly Plug 2

Datasheet : https://www.shelly.com/products/shelly-plug-s-gen3

Power monitoring

For the power monitoring adapters we’re making use of Shelly Plug S Gen3 devices. Each device is placed between the equipment being monitored and the power outlet. This setup allows us not only to measure power consumption but also to perform remote actions such as switching the power on or off (automatically). However, in our case, the Shelly Plugs are solely being used for monitoring active energy consumption.

Shelly does not provide official specifications regarding the measurement accuracy of its devices. Nevertheless, it is generally assumed that the accuracy margin is on the order of ±1%.

The Shelly Plugs report their data using MQTT (Message Queuing Telemetry Transport). MQTT is a lightweight communication protocol used for sending messages between devices. We use Mosquitto as the MQTT broker, which means the Shelly Plug will use Mosquitto to report their energy consumption to.

By default Shelly Plugs report their data via MQTT every 15 seconds, we used the Shelly API to change this value to a minimum of 1 second. This will ensure the consumed energy is updated each second.

To store and analyze the data, we’ve used Telegraf as a data collection agent. Telegraf is subscribed to the relevant MQTT topics on Mosquitto. Telegraf forwards the processed metrics into InfluxDB where they can be stored, queried and used for visualisation.

OpenSSL

OpenSSL is used to generate the certificates. The generation of the OpenSSL certificate is reproducible with the following command:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes -subj /C=NL/ST=Noord-Holland/L=Amsterdam/O=GooseIT/OU=GO-EUC/CN=goosecipher.com"

Scenarios

Idle Baseline

GO-EUC started with provisioning an idle load to measure the default power consumption to establish a baseline for normal behaviour. This step is important because if the Wattage(W) varies significantly during IDLE load, it may also vary under active load, potentially leading to wrong conclusions.

Chosen Scenarios

Hypothesis

Based on the results of the previous research, which measured time efficiency based on round-trip time (RTT), there is a difference expected in power consumption. In the best-case scenario, time efficiency improved by approximately 50% compared to its predecessor. Since the CPU in non-hardware accelerated setups handles the TLS negotiations and related calculations, a small but noticeable difference is expected. There is no clear expectation on the amount of watts ’s as this heavily depends on the CPU performance, but it is estimated that the total power consumption may differ by approximately 5W to 10W difference in total power consumption.

Results

Based on all the tested scenarios, the following charts were generated.

When comparing the TLS 1.2 vs TLS 1.3 equivalents, it can be observed that power consumption is close to equal across the different scenarios. Zooming in on the scenario from the previous research that provided the most difference in time:

TLS 1.2:

TLS 1.3:

Across all test scenarios, measured power consumption remained very consistent between TLS 1.2 and TLS 1.3. For instance, in one of the most active scenarios (50 agents performing 15 handshakes per second), the difference in power usage was only 2 W between the two protocols.

These minor variations mostly fall within the margin of measurement error and cannot be directly attributed solely to the protocol or cipher suite. This indicates that while TLS 1.3 improves performance efficiency, it does not significantly affect power consumption in short-lived, handshake-intensive workloads.

Although the small ±2W difference is insufficient to draw conclusions about power usage in relation to previous time-efficiency research, due to other components in the computer potentially consuming additional power, the prior study confirmed that more handshakes were completed within the same timeframe. This shows that, while energy consumption remains effectively unchanged, overall performance has improved, which is stellar.

Conclusion

A base difference in the scenario types is expected, as increased processing power is required when a higher number of containers (agents) are created. However, there does not appear to be any correlation between the selected cipher suites and power consumption across the different scenarios. Although a small variation in power consumption (±2W) is observed, this difference is negligible. This amount of power difference is so small that it can not be allotted to the scenario. These power differences can come from any of the hardware components present in the machines (Disk/Fan/RAM etc).

It is also noteworthy that both the Rocky Linux and NetScaler devices show the same behavior. This indicates that, for both client and server, there is no noticeable difference in power consumption observed, based on only the cipher suite and protocol type. It is worth noting that more handshakes are simulated with the TLS 1.3 scenarios, yet the power consumption remains the same, indicating no disadvantage in using this protocol.

The results, which differ from the initial hypothesis, encourage further research. The Achilles software simulates handshakes with only a small amount of data transfer; the web page is served by the NetScaler. Since bulk encryption type is mainly used during large data transfers, the power difference may not be noticeable because the data exchange for this test is not intensive enough. The baseline power consumption of a handshake nullifies the power consumption difference unless there is a prolonged data transfer. With this insight a new scenario could be designed to simulate bulk data transfer, which might produce different results compared to the handshake focused scenarios.

There is no notable power difference between TLS 1.2 and TLS 1.3 nor between the different cipher suites, for small data transfers like an HTTPS request. Likewise, there is also no significant difference between the cipher suites, regardless of protocol version. This is still a positive result, as the number of handshakes is higher, as proven in the previous research, without leading to increased power consumption. There may still be power consumption differences between bulk encryption types, which could be explored in follow-up research.

The time to switch to TLS 1.3 is now, not because of power savings so far, but for its improved time efficiency.

Do you measure your power output, and have you ever noticed significant consumption changes related to configuration settings in your environment? Please let us know in the comments!

Photo by Jan Huber on Unsplash