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