Defend S3 Data Flows Now Against Quantum Computing Harvest Threats with F5 BIG-IP and NetApp Storage

The coming achievement of working, usable quantum computers threatens to put today’s data at risk, even with estimates of meaningful maturation in quantum computing, often called Y2Q or Q-day, being 5 to 20 years away. The most striking risk is the so-called “Harvest Now, Decrypt Later” scenario whereby if one can acquire and long-term store today’s encrypted data in flight, future compute power will render the existing applied cryptography powerless to prevent full data observability (the “harvest” part).

To address this, quickly and efficiently, quantum-resistant cryptographic methods can be applied to data in flight today. One approach is to introduce a proxy device like F5’s BIG-IP, which can today offer post-quantum cryptography (PQC) algorithms in front of S3 object storage. This article aims to help you understand the simple setup steps and suggested ways to use NetApp S3 products, including StorageGRID and ONTAP.

 

Then versus Now – Legacy Algorithms At Risk 

TLS requires that a client and server share the same keys during the act of ciphering. This allows symmetric encryption and keeps prying eyes at bay. AES-256-GCM is just one common symmetric encryption algorithm. That onus on the TLS handshake to establish an initial shared key between endpoints, one from which other keys can be locally derived from securely, is critical. The key establishment, also called key exchange or key agreement, will make use of techniques based upon asymmetric keys.

A legacy, pre-TLS1.3 key establishment was frequently the RSA key exchange, discussed here, with inherent security against an eavesdropper by the then-accepted difficulty to find values whose products are extremely large numbers, the so-called large factorials problem. 

Key exchanges in recent years, including within the current TLS1.3 handshakes, have moved to Diffie-Helman centered exchanges, approaches such as Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) which is described at a cursory level here. More advanced than RSA key exchanges, these key agreements strategies are considered safe in classical computing due to the so-called discrete logarithm problem discussed widely online, such as in this article.

Unfortunately for security practitioners today, these mathematical problems that underpin key agreement methods up until now, must be assumed to be compromised at Q-day by quantum computers. As some estimates put this date at only 2030; action is needed right now. With simple network taps coupled with increasingly inexpensive raw storage, data in flight could be harvested today and then exposed to quantum computers in five years’ time, exposing the contents to the holder of that captured data.

For a deeper understanding of how quantum computing is expected to surpass classical computing, which is based upon the binary value of a single bit, a good starting point is to understand the “qubit” and superposition, Microsoft has an interesting introduction here.

One particular “shorthand” is widely used to track advances in quantum computing. This quick method is to track qubit sizes. In 2025, many million dollar+ efforts have created working 100 to 200-qubit systems. 1000 systems have now been completed at a great cost, including expensive support systems for bespoke building spaces and demanding cooling requirements.

As impressive as the current state of the art is, projections to achieve generational changes in computing, one that will indeed threaten classical cryptography, are the 100,000-qubit threshold or greater.

 

A Solution Today – Hybrid (Elliptic Curve + KEM) Key Exchanges Resistant to Quantum Threats

Network and security practitioners are conservative by nature, why radically move away from technology that has worked for decades? Just note the incredible global economic impact of the rise of e-commerce environments, all predicated ubiquitous TLS communications. Instead, a measured approach to incrementally add resistance to quantum computing decryption was sought out.  

This topic is officially known as Quantum-Resistant Cryptography (QRC), with the goal of developing a new set of algorithms that will be impervious to future quantum attacks. 

If one looks at a typical cipher in use in TLS today, the following diagram in yellow highlights the key exchange portion of the sample cipher presented.

The initial mitigation work around the oncoming quantum computing risk is largely focused upon the key exchange mechanism, or in this particular case, ECDHE in the diagram.   Specifically, the initial work has been to harden the key exchange mechanism (called out as “Handshake” above) with the companion authentication aspect hardening to follow in the future.  In other words, a migration to hardened key agreements can be thought of as migration one. The movement to resistant authentication will follow as a second, future phase.

A sound approach gaining market traction was to arrive at shared keys by combining existing agreement methods, such as ECDHE, with new quantum-resistant techniques. The most well-known of these techniques being the Kyber approach using the mathematical concept of lattices.

A hybrid key agreement approach that is currently used be various popular clients, to avoid the harvest now, decrypt later threat, is referred to as “X25519+Kyber768Draft00”. In short, the existing curve based derived key (curve is X25519) and key derived through Kyber, are themselves both combined to serve as the symmetric key source value.

Interesting dates for adoption of PQC ciphers include:
Chrome Version 116, released August 2023
Apple iMessage, with Apple iOS 17.4, released March 2024
Firefox Version 132.0, released October 2024
Microsoft Teams – Experimental stage as of June 2025

After a multi-year exhaustive review of possible solutions, NIST has published the FIPS 203 standard, which is heavily based upon Kyber for quantum computing resistant key agreements. The formal name is ML-KEM (Module-Lattice-Based key Encapsulation Mechanism), more often than not simply called “kem” and can be studied in rich detail here. Generally  kem, or even simply “key encapsulation” when referenced in articles, serve to indicate a modern quantum-resistant analogy to classical key agreement algorithms.

The following diagram, found in Udara Panthem’s Medium article here, succinctly shows visually using asymmetric public and private keys for both curve X25519 and Kyber, arriving at a final shared secret.

Interestingly, in 2025, different ideas exist as to where quantum-resistant TLS will burst out in industry. One prediction specific to the Internet of Things (IoT) sector suggests it may begin with high-value devices like smart meters and medical equipment, before then expanding to extremely high-volume consumer devices like home routers.

 

Configure BIG-IP for TLS Interception and Harvest-Resistant TLS1.3 Cipher X25519+Kyber768Draft00

Early in 2025, F5 BIG-IP release 17.5 was released, which offers client-side interception of TLS sessions using X25519+Kyber768Draft00. Version 17.5.1 was then released in June 2025 to support the NIST standard, however this article makes use of 17.5 as its foundation.   Any client trying to reach a server on the “internal” side of the BIG-IP, think a Nginx web server or a S3-compliant storage appliance pool, can be forced to participate in quantum resistant TLS for content the BIG-IP administrator deems valuable.

Due to the somewhat higher compute load on clients resulting from using two key agreements approaches, transient data such as web server .css files as one single very simple example, may not necessitate PQC on day one. However, long lasting content, for example S3 objects which have PII or other enterprise-sensitive data and will be retained for years would be critical assets to protect. In other words, objects with anticipated value in the realm of years, are excellent candidates for PQC enabled flows.

The server side of the TLS intercepted flows, from BIG-IP to perhaps a collocated HTTPS server, can today be supported with clear channel HTTP inside the secure data center (in other words, “HTTP Offload”) or traditional HTTPS, but clear of the PQC compute tax. In the June 2025 BIG-IP release, 17.5.1, PQC was introduced as an option on both sides of BIG-IP.   The client-side only approach is likely of particular value to origin server solutions, such as S3 storage nodes, that may require development time prior to natively supporting PQC, making BIG-IP critical.

 

How You Can Do It – BIG-IP Setup

Step one today is to upgrade all BIG-IPs to a PQC enabled release, this document used release 17.5; upgrade instructions are found in this short video released in 2025.

The actual configuration steps to add PQC support to a virtual server are documented in this brief F5 knowledge base article.  The steps, reduced to a series of screenshots for version 17.5 follow. The steps are straightforward and simply set the following 4 TLS related linked objects:
Cipher rule (including X25519+Kyber) -> Cipher Group -> SSL (TLS) Client Profile -> Virtual Server client-side TLS enabled with the profile

First, we create a cipher rule that will use X25519KYBER768 in key establishment. Simply follow the numbered steps shown.

Next, we simply add our cipher rule to a cipher group, which our TLS profile can invoke.

The last configuration step is to create a TLS profile. This is a familiar step for any BIG-IP administrator already performing TLS interception. In the example, we just show a certificate and key chain. We also set the profile to use our PQC cipher group and make sure that this profile accepts TLS 1.3. TLS 1.3 brings a wide set of modernizations to TLS, including the ability to leverage PQC ciphering.

At this point, the TLS profile should be added to the client-side TLS setting of any virtual server on BIG-IP. This is to say that clients trying to reach application servers “behind” the BIG-IP (origin pool members) will need to fully communicate via TLS with the BIG-IP reverse proxy.

 

Quick Demonstration of PQC Working

Within a lab environment, Chrome was directed to engage with a virtual server and the above settings.  Good practice is to ensure Chrome is ready to engage, out of the box. It likely is, but it takes just a moment to check. This is done by entering “chrome://flags” into the browser and searching for the two entries mentioning “kyber”. Enable “TLS 1.3 post-quantum key agreement” and disable “Use ML-KEM in TLS1.3”, and now the test is ready to be performed.  BIG-IP version 17.5.1 can support the ML-KEM feature, for those using that newer release.

The virtual server uses an internal DNS resolution, this particular server instance is not live on the Internet, and Chrome Developer Tools will likely be the easiest verification tool to use.

Upon transacting with the virtual server, we note that both the HTTPS transaction succeeded, as per the 200 OK on the Network tab. By viewing the Privacy and Security tab, we note that the key exchange between client and BIG-IP did use the desired hybrid X25519Kyber method. This shows that both the classic computer resistant elliptic curve and quantum resistant algorithms can be combined to safely allow key exchange.

Using libpcap files capturing network data at the client, we can view with a tool like Wireshark to also confirm TLS behaved as expected. In the following, the client (10.150.92.204) via Chrome requests the page in question, from the BIG-IP virtual server at address .201 (double click to enlarge image).

Modern browsers like Chrome open concurrent TCP connections to websites; the above screenshot is filtered to show only the very first.   After the expected 3-way TCP handshake on port 443, we observed a common TLS 1.3 exchange. Note that only one round trip is required between the client and virtual server before the client can begin sending its encrypted HTTP request. Although not directly related to PQC, it serves as a very powerful reminder of one value of TLS 1.3, the frequent move from 2 RTT to 1 RTT to get client traffic flowing. Drilling into the TLS Server Hello of packet 169, we below see the PQC aspects in the trace (double click to enlarge).

 

BIG-IP Now Providing PQC Support to NetApp, StorageGRID and ONTAP 

The following lab setup demonstrates BIG-IP in front of a cluster of StorageGRID storage nodes. My earlier article found here dealt with the setup steps and highlighted the ability to load balance S3 flows across a NetApp origin pool. The sought after PQC value is available now, simply upgrade to BIG-IP 17.5 or 17.5.1.
As always, we instruct the virtual server to provide both TLS inspection and then subsequent secured, performant access to the backend NetApp nodes. With the lab BIG-IP 17.5 release we now can support X25519KYBER768 hybrid quantum-resistant ciphering.

A first quick proof of this is to use Chrome itself, since S3 objects are utilizing HTTP/HTTPS as the underlying transport protocol. One caveat is browsers do not have the mechanism to provide a S3 access key/secret key pair upon requesting as object. This is a typical output when using Chrome to pull content from a StorageGRID tenant, mybucket001:

The workaround for this test to work is to make a bucket, and its underlying objects, public and thus not requiring access/secret to be provided.   NetApp StorageGRID has a method to do this; it is documented here.  In short, a small .json file is used and applied against a bucket access policy to make it public. This allows the following test to be performed successfully with a simple textual demonstration file, using PQC technology (double-click to enlarge).

If we follow the numbers in the above diagram, we see after directing Chrome to the S3 bucket “mybucket005” we have retrieved a phone list object holding some fictious contact names and numbers.  We see that (1) the command has been successful in the S3 object retrieval, as per the HTTPS 200 Okay message. By expanding the Privacy and Security tab in Developer Tools (2), we have confirmed it; the hybrid quantum-resistant X15519Kyber algorithms were indeed used.
Data in flight fed to the BIG-IP, even if copied and stored long-term elsewhere in the traffic’s trajectory with remote clients, is not in imminent threat.   The data in flight is now resistant to harvest now, decrypt later attacks.

Generally, S3 traffic through BIG-IP towards NetApp will be driven through an ecosystem of third-party graphical tools that support S3 file browsing or will use automation such as the AWS SDK commands. Representative GUI-enabled S3 tools include S3Browser, Cyberduck, FileZillaPro and CloudBerry/MSP360. A typical approach to using the AWS SDK is to harness a language like Python and import the “boto3” library.

Quick testing was done with a number of the above solutions; one observation was that many could indeed support TLS1.3, which is a positive movement in infosec. However, none offered easy support for PQC algorithms in their latest releases. Take the AWS SDK for example, I loaded boto3 onto a Windows 10 virtual machine. The AWS documentation shows boto3 itself doesn’t support PQC, but it might be configured to use underlying libraries, which would open up the feature.

In this case, using Visual Studio Code and Python 3.13.5, I have written a simple script to download the Gutenberg project novel “The Great Gatsby” from the StorageGRID mybucket001. As seen in the following screenshot, the file indeed was downloaded over S3 as a simple “dir *.txt” command shows the file is now local on my Windows 10 virtual machine.

Although Wireshark revealed the AWS boto3 library did take advantage of TLS1.3, it did not, as implemented out of the box on Windows 10, make use of quantum-resistant ciphers. This PQC support today would require some additional effort or have native PQC added to the boto3 library itself.

A couple of S3’s common GUI utilities were also tested, specifically S3browser and Cyberduck.  FileZilla Pro also supports S3. However, unlike the first two tools, you need to pay for the pro version to use S3 to browse StorageGRID or ONTAP S3 buckets.   Cyberduck was found to support TLS 1.3, a positive sign, however, like the experience with boto3, it did not exhibit support for PQC. S3browser, on the other hand, running the latest possible version of the freeware, not professional, version at the time of writing, version 12.6.1, did not demonstrate support for either TLS 1.3 or any quantum resistant ciphers.  The following table summarizes client findings.

 

BIG-IP PQC Support and NetApp ONTAP S3

S3 browsing through BIG-IP was also conducted with NetApp ONTAP Select, a lab instance instantiated upon a VMWare ESX hypervisor. Unlike StorageGRID, ONTAP in multi-node clusters will internally load balance written content to optimize efficiency. The ONTAP exposed IP address for S3 traffic is a NetApp logical interface (LIF). These interfaces often map to various storage protocols, such as NFS, SMB or S3.  As such, the BIG-IP virtual server is intended for TLS inspection and security functions, not load balancing. It receives S3 client traffic and proxies flows to the S3 ONTAP LIF. It has full PQC support to ameliorate customer concerns about harvest now, decrypt later attacks on data S3 data in-flight to the ONTAP cluster.

Traffic testing was conducted in much the same manner as with StorageGRID, with BIG-IP offering full and modern TLS interception on the client side. One interesting observation with ONTAP is that for entirely new S3 use cases, ONTAP System Manager can easily create the buckets and stand on their own as object read/write targets. However, what is particularly interesting to ONTAP clusters in service for the past number of years, NAS-handled files accessed traditionally through NFS or SMB can have an S3 license used to expose such files as objects. This is attractive for AI-related workflows, which lean toward the sheer, streamlined performance of S3 over traditional chatty NAS protocols. All of this S3 traffic can be directed through the F5 BIG-IP proxy to offer PQC support today.

 

Summary

The approach of “Q day”, the point at which quantum computers will be able to circumvent many of the TLS algorithms designed to thwart classic computing is hotly contested, but a general agreement seems to be it is not an “if” question, but rather a “when” question. The risk today is retroactive, not-so-distant future decryption of sensitive data. A key attack vector would be to tap and store S3 TLS-encrypted traffic in flight today, and decrypt and steal that sensitive data when quantum computing becomes proficient.

F5 BIG-IP version 17.5, released in early 2025, allows for a PQC-ready TLS experience.   Through ciphers using algorithms like X25519+Kyber768Draft00, the BIG-IP can be a steady gatekeeper in front of NetApp storage solutions like StorageGRID or ONTAP. Clients engaging in S3 reads and writes with NetApp can be compelled to utilize PQC-enabled TLS for any data flows involving sensitive data; data with a value measured over a timeframe where exposure, say, five years out, still exhibits high risk.  The June 2025 BIG-IP 17.5.1 release expanded the offering to NIST-based ML-KEM and support for PQC on both the client side, and now the server side too.

NetApp data that is likely within the scope of PQC protections includes enterprise restricted-access documents or customer relationship files ripe with personally identifiable information. It is expected that regulatory organizations will increase requirements for data security specific to quantum computing risks. The US government and, for instance, the Quantum Computing Cybersecurity Preparedness Act will heighten the intensity at which global industry must look for innovation around security.