“Xena TLS reveals

the performance

bottleneck of

TLS/HTTPS

middleboxes/

proxies”

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.

Transport Layer Security TRANSPORT LAYER SECURITY PERFORMANCE TESTING

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 state-

of-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.

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

Application (HTTP, SMTP...)

Session (TLS)

Transport (TCP)

Network (IP)

Data Link

Physical

Application

Alert

ChangeCipherSpec

Handshake

Pro

toco

l

Fragmentation

Integrity

Authentication

Encryption

Re

co

rd

Figure 1. Transport Layer Security (TLS) architecture

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.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.

SSL 2.0

1995 1999 2006

SSL 3.0

1996

TLS 1.0TLS 1.1

2008

TLS 1.2

2017

TLS 1.3 draft

Figure 2. History of SSL and TLS

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.

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.

Client

Server

SYN

SYN ACK

CipherSuite

Server Certificate

ClientCertificateRequest (optional)

...

ACK

ClientHello

ServerHello

Verity server certificate.

Check cryptographic

parameters

ClientKeyExchange

Send PreMasterSecret information

(encrypted with server public key)

Send client certificate Verity client certificate

(if required)

Finished

ServerHelloDone

ChangeCipherSpec

”"Everything I tell you from now on will be authenticated”

Finished

ChangeCipherSpec

”"Everything I tell you from now on will be authenticated”

Decryption

Verification

Decryption

Verification

Application Data

Application Data

Figure 3. TLS handshake protocol illustration

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 ChangeCipherSpec to indicate “Everything I tell you from now

on will be authenticated” and an encrypted Finished message. The Finished 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.

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

decrypt inspect police encrypt

DUT decrypts traffic and re-encrypts it

TLS Middlebox(proxy, man-in-the-middle)

Figure 4. TLS middlebox (proxy, man-in-the-middle) performance testing

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 FIN 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.

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.

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.

Application payload (20KB)

TLS record (16KB) record (4KB)

TCP Segments ...

Application payload (20KB)

… TCP Segments ...

… TLS Records ...

Figure 5. Optimizing TLS record size

Figure 6. Asymmetric cipher suites on the client and the server sides.

Cipher suite A Cipher suite B

Client port Server port

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.

SYN

ACK

FIN

FIN

SYN ACK

ACK

ACK

TL

S r

am

pu

pT

LS

ra

mp

do

wn

client

server

ClientHello

ServerHello

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

CloseNotify

CloseNotify

TLS Records

TLS Records

TLS Records

TLS Records

SYN

ACK

FIN

FIN

SYN ACK

ACK

ACK

TL

S r

am

pu

pT

LS

ra

mp

do

wn

client

server

ClientHello

ServerHello

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

CloseNotify

CloseNotify

TLS (request)

TLS (response)

TLS (request)

TLS (response)

SYN

ACK

FIN

FIN

SYN ACK

ACK

ACK

TL

S r

am

pu

pT

LS

ra

mp

do

wn

client

server

ClientHello

ServerHello

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

CloseNotify

CloseNotify

HTTP GET

Response

HTTP GET

Response

SYN

ACK

FIN

FIN

SYN ACK

ACK

ACK

TL

S r

am

pu

pT

LS

ra

mp

do

wn

client

server

ClientHello

ServerHello

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

CloseNotify

CloseNotify

(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.