You’re probably familiar with the saying of “Don’t put all of your eggs in one basket.” The implication being that if you do use a single basket, you’re at risk of losing all of those precious eggs. This saying has many different applications depending on what aspect of life you’re talking about. When it comes to personal finance, the idea is to avoid investing all your money in only one stock, and instead diversify your investments among multiple stocks as well as bonds, gold, real estate, etc. This way you avoid risk if the one stock takes a very bad hit and you lose all of your money.
When it comes to security and how organizations manage their configuration access to Servers, the equivalent to a “single basket” is using a “single key” for all encrypted communications between client and server. This is especially important when it comes to avoiding Man In the Middle Attacks (MITM), where a cyber criminal gets into a position to capture and record all the network traffic between a client and server connection. Hence the term “in the middle”. To solve the single key scenario, NetApp ONTAP data management software has the capability to employ Perfect Forward Secrecy (PFS) to protect your organization’s data.
MITM attacks have been around for a while and are still relevant today. Per the 2019 Verizon Data Breach Investigation Report Michael D’Ambrosio, Deputy Assistant Director, United States Secret Service said “Other traditional and effective attack vectors should not be overlooked. These include spear phishing for login credentials or malware delivery and “Man in the Middle” attacks through poorly secured routers or web gateways.”
PFS provides additional security for encrypted communications. To understand why utilizing PFS is so important, let’s start by looking at how a network session using Transport Layer Security (TLS) is setup and how an attacker might try to compromise a TLS session that doesn’t utilize PFS. There are five primary steps to the TLS Handshake.
A cyber criminal might try to exploit the TLS connection in order to obtain organizational data by utilizing a MITM attack.
As an example of a MITM attack, consider how any server system is managed. When configuration changes need to be made to the server, a client needs to establish a session with the server. The client would most commonly be a desktop or laptop device that an administrator is using to manage the server. When ONTAP is acting as the server, the administrator brings up System Manager for the cluster and types in https://ontapclustername at which time, a Transport Layer Security (TLS) encrypted session is setup between the client and ONTAP. This means that any information (username, password, configuration data, etc.) that passes between the client and ONTAP is encrypted and can’t be read by an attacker. Utilizing the MITM method, the attacker can still use a packet sniffer to record and save these encrypted sessions. Later, if the attacker is able to compromise and obtain the private key used by the server, then all of these previous sessions could be decrypted at that time. The example below gives a closer look at the MITM scenario.
Using Perfect Forward Secrecy (PFS) can ensure that even if a MITM attack occurs, any previously encrypted data obtained via a MITM attack will not be easily decrypted. PFS is a method of key exchange that requires a unique key be used for each network session between a client and server. Without a cipher suite that utilizes PFS principles, each network session establishes the encryption utilizing the server’s private key. PFS on the other hand requires a different key to be used for each and every session and does not utilize the server’s private key for encryption.
In the TLS Handshake example above, step 2 was where the server sent the cipher suites it supports to the client. This is very important because if those cipher suites do not support a PFS method of key exchange then the encryption key is based on the server private key. This means that if the private key is compromised as indicated in the above MITM attack example, then the attacker will be able to decrypt the data sent between the client and the server. Ephemeral Diffie-Hellman (DHE) and Elliptic-curve Diffie-Hellman Ephemeral (ECDHE) are cipher suites that employ the PFS method of key exchange. When the server is configured with only cipher suites that employ PFS principles, then a MITM attack will not be successful in being able to decrypt all the prior sessions, even if the attacker has obtained the server’s private key.
NOTE: You can see above that even with a compromised private key the attacker is not able to decrypt the previously recorded sessions.
To utilize PFS in ONTAP you have to configure only cipher suites that utilize the PFS method of key exchange, such as DHE and ECDHE for HTTPs connections. PSK (pre shared key/pre shared secret) should also be included because ONTAP functions, such as Cluster Peering Encryption, utilize PSK. At the same time, you would also need to configure all the other cipher suites to not be supported. This can be accomplished by modifying the ONTAP SSL interface using the “security config modify” command. For more information on how to configure PFS in ONTAP see the KB article “Does ONTAP support Perfect Forward Secrecy (PFS)?”
While it’s critical to protect the server’s private key, it’s important to prepare for the risk of the key being compromised. Configuring PFS in ONTAP provides peace of mind that previously recorded encrypted sessions cannot be automatically decrypted. You will have effectively kept all of your encrypted sessions (eggs) from getting broken in one “basket”.
NOTE: While this article focuses on how configuring PFS can prevent a cyber criminal who has employed a MITM attack from reading past networking sessions, the article is not directly meant to address how to protect your entire network from the MITM attack in the first place. It is important to develop an overall “defense-in-depth” approach for your network to avoid common MITM attacks such as:
Now on his 2nd tour at NetApp across 10 years, Matt is a Security Evangelist with a primary focus on ransomware prevention and recovery, cyber resiliency, and data-centric portfolio security. This includes but is not limited to Zero Trust, Data Governance and Privacy Frameworks, Security Tools, and Security Best Practices. Prior to this Matt held the dual role of Product Manager and Technical Marketing Engineer for ONTAP Security driving the latest security features and capabilities into NetApp’s flagship product. He has also held the position of Staff Engineer at NetApp during which he focused on ONTAP product Supportability specifically in the areas of networking and SMB/CIFS. In between NetApp stints Matt worked with a NetApp partner (Eze Castle Integration) for 7 years as pre sales/post sales storage architect focusing on early 7-mode to cDOT migration. He has also focused on Microsoft Windows Active Directory, Exchange, SQL and VMware during his 23 years of IT experience with 17 of those years coming in the storage industry. Prior to NetApp and ECI, Matt worked a contract at Microsoft as a Technical Support Engineer.