Transport Layer Security

Transport Layer Security TRANSPORT LAYER SECURITY PERFORMANCE TESTING OVERVIEW Transport Layer Security (TLS) and its predecessor Secure Sockets Layer (SSL), are the most popular cryptographic protocols used by the major web browsers, and websites around the world. HTTPS, also called HTTP over TLS, is now the de facto standard for many websites to provide secure services to their users, like Netflix, Facebook, Amazon, banks, ecommerce, etc. Testing TLS performance is important for network security equipment manufacturers, operators, enterprises, system integrators, etc., because it helps find the balance between security and performance. And for the tests to be valid, it is essential that the test equipment can send encrypted TLS traffic through the DUT while it is operating in the TLS middlebox/proxy mode. Supporting the latest encryption standard, Xena TLS reveals performance bottlenecks of TLS/HTTPS middleboxes/proxies, address security performance testing requirements, and optimize security parameters. Xena TLS reveals the performance bottleneck of TLS/HTTPS middleboxes/ proxies

Transport Layer Security Performance Testing Contents Introduction... 3 From Plaintext to Encryption... 3 Need for Communication Security... 4 History of SSL and TLS... 4 How TLS Works... 6 Need for TLS Middlebox Performance Testing... 8 Xena TLS Performance Testing... 9 TLS Above TCP... 10 Close Notify Option... 10 Optimizing TLS Record Size... 10 TLS Key Exchange and Cipher Suites... 11 Test Scenarios with TLS... 12 Conclusion... 13

INTRODUCTION Traffic encryption is ubiquitous on the internet, e.g. HTTPS, because of user privacy and data integrity protection. As in 2017, the average volume of encrypted internet traffic has surpassed the average volume of unencrypted traffic. That means everyone including internet service providers and the government is having a harder time seeing what information you are reading or posting to the web. Without encryption, it is too easy for any prying eyes to breach privacy and data integrity. Transport Layer Security (TLS) with the predecessor being Secure Sockets Layer (SSL), is the most popular cryptographic protocol adopted by major web browsers, e.g. Google Chrome, Mozilla Firefox, Microsoft internet Explorer/Edge, Opera Browser, Apple Safari, etc., as well as websites around the world. HTTPS, also called HTTP over TLS, has become the de facto tool for many websites to provide services to their users, like Netflix, Facebook, Amazon, banks, ecommerce, etc. However, there is always a tradeoff between security and performance. Since traffic content is encrypted, so are spams and viruses. Next-generation firewalls (NGFW), as well as other network security equipment, are able to act as a proxy that decrypts the traffic and encrypts it again in order to prevent users from malicious attack or virus infection. Doing this has a cost, that is, the equipment must spend a considerable amount of computational power and time to process each packet on the data path (inline device). Although security is vital, low user experience will strongly affect the popularity of an application. Testing the performance of TLS in your network or a device under test (DUT) has become the key to successfully deliver services with high user experience. Since the DUT can operate as a middlebox/proxy, it is all about getting high-performance traffic through the proxy. Xena provides a solution that can deliver such a test, where high-performance TLS/HTTPS traffic is sent between the clients and the servers, helping users to optimize their network security parameters. FROM PLAINTEXT TO ENCRYPTION Sending information in plain texts are highly risky because it exposes user privacy and sensitive data to the public on the web. Starting from the 90 s, the information technology industry has begun to develop protocols that secure data transfer. Transport Layer Security (TLS) is the stateof-art protocol that protects user privacy and data integrity between communicating applications.

Need for Communication Security Plaintext communication puts user privacy and data integrity at high risk because the information can be understood by everyone on the web with the help of unsophisticated tools, not to mention skillful hackers. Potential damages caused by plaintext communication include financial theft, identity fraud, privacy leakage, etc. More and more applications on the internet begin to encrypt their traffic in order to protect their users communication content from prying eyes. Content such as username, password, shopping orders, shopping history, TV programs being watched, chatting records, etc. are all under the protection of advanced encryption protocols and algorithms. Transport Layer Security (TLS) shown in Figure 1, with the predecessor being Secure Sockets Layer (SSL), is the most popular cryptographic protocol adopted by major web browsers, e.g. Google Chrome, Mozilla Firefox, Microsoft internet Explorer/Edge, Opera Browser, Apple Safari, etc., as well as websites around the world. HTTPS, also called HTTP over TLS, has become the de facto tool for many websites to provide services to their users, like Netflix, Facebook, Amazon, banks, ecommerce, etc. HTTPS provides authentication and protects against man-in-the-middle attacks. In addition, it provides bidirectional encryption of the communication between a client and a server. Application (HTTP, SMTP...) Session (TLS) Transport (TCP) Protocol Application Alert Handshake Network (IP) Data Link Physical Record Fragmentation Integrity Authentication Encryption Figure 1. Transport Layer Security (TLS) architecture History of SSL and TLS The use of the Secure Sockets Layer (SSL) protocol, and its newer iteration, Transport Layer Security (TLS), has been on the rise with the ever-increasing need for privacy online and data security. SSL and TLS are both cryptographic protocols that provide authentication and data encryption between servers, machines, and applications operating over a network, e.g. a client

connecting to a web server. Over the years, new versions of the protocols have been developed, standardized and released to address vulnerabilities and support stronger and more secure cipher suites and algorithms. SSL was developed by Netscape Communications Corporation in 1994 to secure transactions over the World Wide Web (WWW). SSL 1.0 was never released because of serious security flaws. As shown in Figure 2, SSL 2.0 was released in 1995, and SSL 3.0 in 1996. Soon after that, the Internet Engineering Task Force (IETF) began to develop a standard protocol that provided the same functionality. They used SSL 3.0 as the basis for that work, which became the TLS protocol. TLS 1.3 draft TLS 1.2 SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 1995 1996 1999 2006 2008 2017 Figure 2. History of SSL and TLS TLS 1.0 was first defined in RFC 2246 as an upgrade of SSL version 3.0. As stated in the RFC, the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0". TLS 1.1 was defined in RFC 4346 in 2006. It is an update from TLS 1.0. Significant differences include: added protection against cipher-block chaining attacks and support for IANA registration of parameters. TLS 1.2 was defined in RFC 5246 in 2008. It is based on TLS 1.1 with enhanced support for authentication encryption ciphers, enhancement in the client s and server s ability to specify which hashes and signature algorithms they accept. As of July 2017, TLS 1.3 is still at its draft phase with details being provisional and incomplete. Some web browser vendors have set TLS 1.3 as the default version for a short term in 2017 but them removed it as the default, due to incompatible middleboxes.

TLS and SSL are most widely recognized as the protocols that provide secure HTTP (HTTPS) for internet transactions between web browsers and web servers. TLS/SSL can also be used for other application level protocols, such as File Transfer Protocol (FTP), Lightweight Directory Access Protocol (LDAP), and Simple Mail Transfer Protocol (SMTP). TLS/SSL enables server authentication, client authentication, data encryption, and data integrity over networks such as the World Wide Web (WWW). How TLS Works The goals of the TLS protocol are cryptographic security, interoperability, extensibility, and relative efficiency. These goals are achieved through implementation of the TLS protocol on two levels: the TLS Record protocol and the TLS Handshake protocol. The TLS Record protocol negotiates a private, reliable connection between the client and the server. Although the Record protocol can be used without encryption, it uses symmetric cryptography keys, to ensure a private connection. This connection is secured with hash functions generated by using a Message Authentication Code (MAC). The TLS Handshake protocol, as shown in Figure 3, allows authenticated communication to commence between the client and server. This protocol allows the client and server to speak the same language, allowing them to agree upon an encryption algorithm and encryption keys before the selected application protocol starts sending data. Using the same handshake protocol procedure as SSL, TLS provides for authentication of the server, and optionally, the client.

Server Client SYN SYN ClientHello ServerHello Verity server certificate. Check cryptographic parameters CipherSuite Server Certificate ClientCertificateRequest (optional) ServerHelloDone ClientKeyExchange Send PreMasterSecret information (encrypted with server public key) Send client certificate Verity client certificate (if required) "Everything I tell you from now on will be authenticated "Everything I tell you from now on will be authenticated Decryption Verification Decryption Verification Application Data Application Data... Figure 3. TLS handshake protocol illustration A TLS session runs on top of a TCP session. For every TLS, a three-handshake of TCP protocol must be completed before the TLS handshake starts. As soon as the TCP connection is established, the client sends the server in plain text with a number of specifications, such as the version of the TLS protocol it is running, a list of supported cipher suites, and other TLS options it wants to use in the encryption session.

Upon receiving the ClientHello message from the client, the server, picks the TLS protocol version for further communication, decides on a cipher suite from the list, attaches its certificate, and then sends the ServerHello response back to the client. Optionally, the server can also send a request to the client, asking for the client s certificate and parameters for other TLS extensions. ServerHelloDone is sent by the server to indicate it is done with handshake negation. The client receives the feedback on the TLS version and cipher suite to be used from the server. Assume that the client agrees on the proposal from the server, and has validated server s certificate. Then the client initiates either the RSA or the Diffie-Helman key exchange that is used to establish the symmetric key for the encrypted session. The client responds with a ClientKeyExchange message, which contains a PreMasterSecret. The client and server will use the random number s and PreMasterSecret to compute a common secret, the master secret. The client and the server then send to indicate Everything I tell you from now on will be authenticated and an encrypted message. The messages will be decrypted and verified by the recipient. In case of failure, the encryption tunnel will be torn down. After TLS tunnel is established, the client and server will start exchanging application data. NEED FOR TLS MIDDLEBOX PERFORMANCE TESTING Owing to the increasing need for data security and privacy protection, more than 50% of internet traffic is now encrypted by TLS (HTTPS). The popularity of HTTPS as well as other applications that take advantages of TLS has generated many requests on performance verification of the decryption capability of networks and devices. Next-generation firewalls (NGFWs) are able to decrypt TLS traffic in order to block encrypted virus and malicious content or perform application control. Load balancers are also able to terminate the incoming encryption tunnels and communicate with the server farm in either new encrypted tunnels or in plain texts. Packet brokers are also capable of decrypting traffic and inspecting the traffic content and take actions accordingly. In other words, this network equipment can act as TLS middleboxes (also known as proxy, or man-in-the-middle) as illustrated in Figure 4 below.

DUT decrypts traffic and re-encrypts it decrypt inspect police encrypt TLS Middlebox (proxy, man-in-the-middle) Figure 4. TLS middlebox (proxy, man-in-the-middle) performance testing In order to protect information and data security, enterprises often deploy network security devices, e.g. firewalls, intrusion prevention system, intrusion detection system, packet broker, etc. in their networks. However, due to the intensive computing carried out by the devices when decryption is enabled for network visibility, network throughput will decrease. This is simple because traffic decryption and scanning take time to execute and thus less time for packet forwarding. Many solutions are developed to boost the performance of traffic decryption, e.g. TLS offloading with hardware acceleration. These solutions require thorough testing with real encrypted application traffic (e.g. HTTPS) between a client and a server before they are deployed onto the network. It is a must that the test equipment is capable of getting the encrypted TLS traffic through the DUT that is operating in the TLS middlebox/proxy mode. Otherwise, the test will be invalid. XENA TLS PERFORMANCE TESTING Xena TLS supports the latest standardized and de factor TLS version, TLS 1.2. To reveal the real performance of your DUT or network in terms of TLS performance, Xena has implemented a

native TLS protocol support over TCP. This means that users can generate high-performance TLS traffic (e.g. HTTPS) and test with TLS middleboxes as shown in Figure 4. TLS Above TCP Following the OSI model, there TLS operates on top of TCP, Xena has added TLS as an independent and configurable protocol stack above TCP with full consideration of ease-of-use and understandability. Users can select TLS when they create test scenarios and configure TLS parameters independent from the other layers. Close Notify Option CLOSE_NOTIFY is supported as an option for closing TLS sessions. Stated in RFC 5246, CLOSE_NOTIFY is a type of TLS closure alert. The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. A TLS truncation attack blocks a victim s account logout requests so that the user unknowingly remains logged into a web service. When the request to sign out is sent, the attacker injects an unencrypted TCP message to close the connection. The server therefore doesn't receive the logout request and is unaware of the abnormal termination. CLOSE_NOTIFY message notifies the recipient that the sender will not send any more messages on this connection. As of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice. Either party may initiate a close by sending a CLOSE_NOTIFY alert. Any data received after a closure alert is ignored. Optimizing TLS Record Size Maximum TLS record size of 16KB (2^14 bytes as defined in RFC 5246) is supported so users can test the performance of different size of TLS records. Like the IP or TCP layers below it, all data exchanged within a TLS session is also framed using a well-defined protocol. The TLS Record protocol is responsible for identifying different types of messages (handshake, alert, or data via the "Content Type" field), as well as securing and verifying the integrity of each message. TLS record size can have significant impact on the performance of applications. Since a TLS record (maximum 16K bytes) can be way larger than a TCP segment size (maximum 1460 bytes), it may require a number of TCP segments to deliver a TLS record. Two extreme cases are shown in Figure 5

With Xena TLS, users can tune the TLS record size to find the optimal setting for their own networks. Application payload (20KB) Application payload (20KB) TLS record (16KB) record (4KB) TLS Records... TCP Segments... TCP Segments... Figure 5. Optimizing TLS record size TLS Key Exchange and Cipher Suites Before a client and server can begin to exchange information protected by TLS, they must securely exchange or agree upon an encryption key and a cipher to use when encrypting data. For encryption, Xena supports 128-bit and 256-bit AES, in the CBC and GCM modes, ChaCha20, 3DES, and RC4. For forward secrecy, Xena supports both DHE and ECDHE. Xena features a simple cipher suite collection to use the latest "default" set of preferences. Preference customization is supported. Asymmetric cipher suites on client and server side are supported too. This is to enable users to test a DUT that uses different cipher suites on the client and the server sides. Client port Cipher suite A Cipher suite B Server port Figure 6. Asymmetric cipher suites on the client and the server sides. Public key certificates used during exchange/agreement also vary in the size of the public/private encryption keys used during the exchange and hence the robustness of the security provided. Since the TLS certificate key size has performance impact of TLS handshake performance, Xena supports up to 8KB key size. Users can test the performance of their DUT using different key sizes and also export the certificate so that they may create even more complex test scenarios by uploading Xena TLS certificate to their DUT.

Test Scenarios with TLS Xena supports various types of test scenarios, shown in Figure 7, with TLS to meet different TLS test requirements. The simplest test scenario is that TLS handshake begins right after the TCP connection is established. No TLS payload is transmitted after the ramp-up phase. Users can use such a scenario to test TLS handshake capability of their DUT, if throughput testing is not required. Another test scenario allows clients (upload) or server (download) or both (bidirectional) to send TLS traffic after the TLS session is established. With configurable payload length and pattern, users can load the data path at 100% to test the throughput performance as well as TLS handshake. Users can also generate HTTPS (HTTP on top of TLS) by using the request-response model, where a client sends requests and the server responds some content. With configurable request and response content, users can define their own HTTPS dialog. This type of communication model is ubiquitous on the internet and is thus a vital test for performance. In addition to TLS handshake performance and throughput, users can also test HTTPS transactions per second, HTTPS connection per second, etc. server server server server client client client client SYN SYN SYN SYN SYN SYN SYN SYN ClientHello ClientHello ClientHello ClientHello TLS rampup ServerHello ServerHelloDone ClientKeyExchange TLS rampup ServerHello ServerHelloDone ClientKeyExchange TLS rampup ServerHello ServerHelloDone ClientKeyExchange TLS rampup ServerHello ServerHelloDone ClientKeyExchange TLS Records TLS Records TLS Records TLS Records TLS (request) TLS (response) TLS (request) TLS (response) HTTP GET Response HTTP GET Response TLS rampdown TLS rampdown TLS rampdown TLS rampdown (1) (2) (3) Figure 7. Test with TLS traffic.

CONCLUSION Owing to the increasing need for data security and privacy protection, more than 50% of internet traffic is now encrypted by TLS (HTTPs). The widespread HTTPS as well as other applications that take advantages of TLS has generated many requests on performance verification of the decryption capability of networks and devices. Next-generation firewalls (NGFWs) are able to decrypt TLS traffic in order to block encrypted virus and malicious content or perform application control. Load balancers are also able to terminate the incoming encryption tunnels and communicate with the server farm in either new encrypted tunnels or in plain texts. Packet brokers are also capable of decrypting traffic and inspecting the traffic content and take actions accordingly. In other words, this network equipment can act as TLS middleboxes (also known as proxy, or man-in-the-middle). It is a must that the test equipment is capable of getting the encrypted TLS traffic through the DUT that is operating in the TLS middlebox/proxy mode. Otherwise, the test will be invalid. Testing TLS performance has become vital for everyone, including network security equipment manufacturers, operators, enterprises, system integrators, etc., because it helps find the balance between security and performance. Adopting the latest encryption standard, Xena TLS provides users with high-performance test solutions that can reveal the performance bottleneck of their TLS/HTTPS middleboxes/proxies, address security performance testing requirements, and optimize their security parameters.