The Speed of Lite

The Speed of Lite -- Lite-TLS Specification

Author: 3andne.
10/10/2021

Overview

With the increasing efforts to make the Internet safer, a significant amount of daily network traffic is secured by TLS. This creates Redundant Encryption in a TLS based proxy, which encrypts already encrypted TLS streams, thus taking up extra computation and increasing latency. Some previous works (xtls) have addressed this problem. However, the need to use a forked TLS library may create loopholes. Furthermore, the implementation is not easy to port to other languages.

The Lite-LTS is another attempt to fix this problem without using a forked TLS library. This is achieved through a process called the Lite-TLS handshake. In short, when an inner TLS handshake is detected, we perform a Lite-TLS handshake to allow the client and server to leave the TLS tunnel simultaneously at a cost of an additional 0.5 round trip time.

The Lite-TLS handshake is TLS version agnostic as it only depends on some assumptions made by both TLS 1.2 and 1.3. It's very likely that this applies to future versions of TLS.

Terminologies

TLS Packet Specification

Here's the packet in TLS (1.2/1.3):

+-------------+-------------+--------+----------+
| Record Type |   version   | Length | Payload  |
+-------------+------+------+-------------------+
|      1      | 0x03 | 0x03 |   2    | Variable |
+-------------+------+------+--------+----------+

Some of the valid record types are:

• 0x14: Change Cipher Spec
• 0x16: Handshake
• 0x17: Application Data
• ...

0x14 and 0x16 are used during the handshake，and 0x17 is the type for data transmission after the handshake.

Endpoints

• user - the user that sends packets to the proxy client.
• client - the proxy client
• server - the proxy server
• target - the target website

Firsthand and Secondhand Packet

Packets that come from the user/target are considered firsthand, whereas packets from the client/server are secondhand. For example, the client gets its firsthand packets from the user, and gets its secondhand packets from the server.

The Lite-TLS handshake

  --->: tcp traffic
  ===>: tls over tcp traffic
  ####################################################################
  ---- 0x17 ---> [client]                 [server]

                 [client] ==== 0x17 ====> [server]
                                ^ the first 0x17 in this stream

                    <== ...some traffics... ==>

                 [client]                 [server] <-{..., 0x17}--
                                             ^ active side *1

                 [client] <={..., 0xff}== [server]{0x17} < buffered *3
     passive side *2 ^              ^ a 0xff is appended

                 [client]{...}            [server]{0x17}
                           ^ buffered *4

                 [client]{...} == 0xff => [server]{0x17}
                                    ^ a 0xff is returned *5

                 [client]{...}            [server]{0x17}
                    ^ quit tls               ^ quit tls *6

                 [client] <- Plain Tcp -> [server]
                 
                 [client]{...} <- 0x17 -- [server]

 <-{..., 0x17}-- [client]                 [server]
                              ......

1. active side: The second endpoint that receives Firsthand 0x17 enters active mode.
2. passive side: The endpoint that receives 0xff enters passive mode.
3. The active side buffers the 0x17 packet it receives. If 0x16/0x14 packets come before 0x17 in the same TCP packet, we append the 0xff at the end of them and send them to the passive side. If nothing goes along with 0x17, we send a single 0xff. The 0xff informs the passive side to prepare to leave the TLS tunnel.
4. The passive side verifies the 0xff described in 3 and then drops it. It buffers the 0x14/0x16 (if any) and will send them to the user as soon as the 0x17 arrives. This is crucial for browsers since they will fail to render otherwise.
5. The passive side sends a 0xff back to indicate that it will never use the TLS tunnel to send anything.
6. When the active side receives the 0xff, it knows it's safe to leave the TLS tunnel.
7. Both sides now use a TCP tunnel. The active side sends the buffered 0x17 to the passive side, just like all the previous packets it sent. Nothing different can be observed from a surveillance device. The passive side collects the 0x17 and sends it along with all the buffered packets.
8. The handshake is over.