The Challenge of Transport Layer Security (TLS) Testing

TLS Engine Implementations

If you are engaged in TLS testing, chances are that you have either implemented a TLS stack or engine in your new product, or you are verifying TLS functionality in a new app or device.

Sources of TLS engines are: Botan, BoringSSL, Erland, GnuTLS, LibreSSL, MatrixSSL, NSS, OpenSSL, wolfSSL, and many more.

If you have implemented one of these TLS engines, you will need to test TLS compliance against the TLS protocol.

This means that you have examined both:

• IETF RFC 5246 “Transport Layer Security, Version 1.2”

• IETF RFC 6176 "Prohibiting Secure Sockets Layer (SSL) Version 2.0”

And you are certain that in the face of pathological packets, your app or device will behave correctly.

TLS Functionality Addition

If, on the other hand, you are verifying TLS functionality in a new app or device, then you will have to meet the requirements of the organization that governs your app or device area.

For example, PCI, the Payment Card Industry, defines standards for PCI Compliance. Companies involved in the credit card processing industry must meet PCI requirements. Initially, this began with an SSL test, as that was the first security algorithm used in the transmission of payment data.

Later, TLS compliance was required. However, it was not about testing that the app or device complied or conformed to the TLS protocol. Instead, PCI TLS compliance addresses REGULATORY COMPLIANCE, meaning that the company can produce audit ready reports for the regulatory agency.

Likewise, email clients and servers are now in the position of clarifying appropriate TLS compliance in their area. For example, best practices now suggest that at start-up, the email client should not use the STARTTLS mechanism but use instead “Implicit TLS”. “Implicit TLS” means that TLS is negotiated immediately at the connection start on a separate port.

Thus TLS compliance is somewhat dependent on the industry group utilizing the protocol.

What is the difference between a TLS compliance test and a TLS vulnerability test?

A set of TLS compliance tests will test that the device under test behaves properly for each protocol assertion contained in the standards document, including unexpected packets and malformed packets.

A set of TLS vulnerability tests (also known as fizzing or fuzzier tests) will modify the encapsulation protocol of each packet and check for a device failure (typically that the device is still operational). The fuzz tests do not pinpoint specific areas and flag how and why the TLS implementation has failed.

The Maxwell Pro TLS Test Suite intelligently impairs all aspects of the TLS protocol using 100 unique tests cases, extendable through parameters for greater coverage. The engineer may:

• Incorporate his own data sources

• Start testing immediately; no porting exercise to instrument the TLS stack

• Receive tech support from senior protocol engineers

• See pass/fail results; no need to analyze complicated outputs

• Replicate customer reported bugs, customize the environment to properly test and replicate the problem

TCP Server Test Tool and TCP Client Test Tool

One might assume that open source operating systems, such as Linux and FreeBSD, with their presumably stable implementations of the standard suite of network protocols, would address all application needs; so there should be no requirement for a developer to create a new TCP/IP stack.

TCP stack test (or TCP Engine Test)

Yet developers often need to customize or optimize their own implementations to serve specific purposes. When that occurs, it is important to engage in thorough TCP testing to assure that all functions of the protocol continue to operate. This means testing TCP conformance, compliance, and robustness / vulnerabilities in the face of attacks.

TCP Connection Diagnostics

Some TCP test tools are limited to initiating and capturing TCP packets from one device to another for debugging TCP session connectivity issues. This is a limited task that is not TCP testing, but rather a “capture and replay” tool; Wire shark is a popular choice.

TCP Socket Testing

Many free tools exist under the “TCP socket test” category – their whole purpose is to aid application developers; they are only a little more useful than telnet clients and echo servers. They provide almost no TCP stack test value (other than “fair weather” testing.)

TCP Server Test Tool and TCP Client Test Tool

Network utilities establishing a TCP connection between two nodes to exchange messages is of course essential to assure basic functionality of a new implementation in both client and server roles. The network traffic exchange could be captured and manually reviewed to examine the traffic exchange between various network services, firewalls, etc. However, this is not a TCP test tool, in that there is no definition of a test, expected outcome, or source of authority. Instead it is a diagnostic or inspection tool to allow one to probe and examine the traffic stream; it requires expert TCP knowledge on the part of the user.

For manual review of such packet traffic, Wire shark is probably the best free tool for the job. However, for serious, comprehensive testing, the Maxwell Pro TCP Test Suite [https://iwl.com/protocol-testing/tcp] actually finds bugs in TCP stacks or engines by sending series of pathological conditions to the TCP client or TCP server over IPv4 or IPv6. The tests ensure a sufficiently robust TCP stack or engine that is not vulnerable to the wide range of attacks in today’s Internet. The tests make use of the Maxwell Pro network emulation environment, so that each test sequence can intelligently impair all aspects of the TCP protocol. The procedure for each test is described in plain language and references the IETF RFC requirements (source of authority) being examined. The tested device's response is compared to the set of expected outcomes so it can automatically present not just a pass/fail grade, but the reason for the pass or fail. The end result is a complete report on a TCP stack's conformance and robustness.

Why Does SNMP, A Protocol Based On Polling Agents, Permit SNMP Notifications?

The original design of SNMP (the Simple Network Management Protocol) was based on managers and managed devices (with agents). The manager’s responsibility was to determine what data was needed and how often it was needed. Agents provided the data only when requested by managers. Thus, the manager polled the agent and determined, based on that data, if the agent was functioning properly.

A drawback of this polling approach is the lag time between a problem or error condition occurring with an agent and the manager discovering the issue. The larger the number of managed agents, the longer the delay in discovery. Thus polling was not realistic in networks with large numbers of managed devices. By enabling the SNMP agent in a managed device to determine when an important event or error conditions has occurred within the device, the agent could then notify the management application.

The application of these notifications has changed with each version of the SNMP protocol.

With SNMPv1, an SNMP TRAP was sent by the agent. The TRAP reported the occurrence of an event to the management app. However, there was no certainty or safeguard that the management app received the TRAP.

With SNMPv2c, the agent sent an SNMP INFORM and the management app acknowledged the receipt of that INFORM. This was a big improvement as it increased confidence that the management app could at least now take action on the information contained in the SNMP INFORM. (Note that many times when significant failures occur on networks, a loss of connectivity may prevent receipt of the INFORM by the management app, and thus a failure to take any action.)

In both SNMPv1 and SNMPv2c, the TRAP or the INFORM contained an event and a list of variables and their associated values. The management application then interpreted this information and determined the next action.

As discussed in the popular paper, “Implementing Secure Network Management”: [http://iwl.com/idocs/implementing-secure-network-management]

SNMPv3 also introduced a new concept of the command generator and the command responder. These terms replace the traditional notion of a smart manager and a non-intelligent agent. SNMPv3 recognizes that many network devices and applications operate in dual or multiple modes. These devices are now "entities" and an entity can be a command generator (used to be a manager) or a command responder (used to be an agent).

To verify that notifications are properly working, an SNMP test tool, like Silver Creek [https://iwl.com/products/silvercreek], may be helpful. Silver Creek includes trap library tests that verify the following against the loaded MIBS:

• Syntax type, range and size for all included variable bindings.

• Variable bindings are ordered correctly and complete.

• Variables have valid instance identifiers. Includes support for IMPLIED indexing.

What You Should Look for in a WAN Emulator Appliance?

With the advent of cloud computing and the Internet of Things, the importance of pre-deployment network performance testing cannot be over-emphasized. Will your app or device perform under all network conditions ranging from the routine to the extreme?

Some apps and devices will simply not work when certain kinds of network conditions occur. Voice communications, for example, generally become unintelligible at certain levels of packet delay that are a common occurrence on today’s Internet!

Best practice is to characterize the full performance profile of the app or device. This way you can avoid inappropriate usage scenarios for your app or device or handle these scenarios with a message to the user that “the network is currently unreachable”.

First, there’s some basics you should cover when selecting test equipment to characterize performance:

1. Will you use a WAN emulator appliance or a conventional network emulator? Do you know what level of accuracy is required for your app or device to function properly? A WAN emulator appliance (a network emulator application operating in a virtualized environment) can eliminate installation and configuration issues, but may not offer the level of accuracy required.

2. How does your app or device respond to packet loss (a frequent occurrence on the Internet)? Can your emulator act as a packet loss simulator? Or, better yet, the emulator should go beyond simulation and actually drop packets (and introduce other common impaired network phenomenon, such as delay, reordering, jitter, etc.) before the packets reach your device or app. so that you can truly understand performance under various packet loss conditions.

3. Another important consideration, particularly in voice and video apps and devices is delay or latency. Can your emulator serve as a latency generator by stepping through all the conditions that are likely to occur that delay the delivery of packets on the Internet?

4. Finally, although it is a little complicated, your emulator should serve as a network bandwidth simulator. You will need to understand how your app or device performs when bandwidth is limited. In addition, there’s a difference between rate limitation and bandwidth limitation.