Understanding TLS: Layered Architecture, Cipher Suites, and Secure Configuration

TLS Protocol Principles

1. Top‑down Layered Abstraction

Software is often built in layers, abstracting the problem domain into multiple levels where each layer defines a set of primitives and uses the layer below to implement its functionality.

In programming languages, assembly is a layer, above it are static compiled languages like C/C++, then dynamic scripting languages such as Python, PHP, Lua, and on top of those domain‑specific DSLs may be built.

In network architecture, Ethernet is a layer, above it the IP network layer, then transport layers like TCP, and finally application layers such as HTTP.

Cryptographic communication protocols are also constructed in layers:

The lowest layer implements basic algorithm primitives such as AES, RSA, MD5, SHA‑256, ECDSA, ECDH, etc.

The next layer selects standardized algorithms (block ciphers, signature algorithms, asymmetric encryption, MACs, etc.) like AES‑128‑CBC‑PKCS7, RSAES‑OAEP, RSASSA‑PKCS1‑v1_5, HMAC‑SHA256, ECDSA‑P256, Curve25519, and so on.

Above that, semi‑finished components combine multiple standard algorithms, e.g., symmetric transmission components (AES‑128‑CBC + HMAC‑SHA256, AES‑128‑GCM), authenticated key‑exchange components (RSA‑ECDHE), digital envelope constructions, file encryption components (PBKDF2 + AES‑128‑CBC‑HMAC‑SHA256), and key‑expansion PRFs.

The top layer assembles these components into complete cryptographic protocols/software such as TLS, SSH, SRP, GnuPG file format, iMessage, Bitcoin, etc.

Understanding each layer is essential: the first layer (basic algorithms) is widely known; the second layer involves many parameters that require deeper study; the third layer often sees developers reinventing existing components; the fourth layer—correctly using mature protocols—demands solid cryptographic knowledge.

The hardest part is linking theory to practice : abstracting a real‑world problem into its core cryptographic issues and modeling it with a rigorous, systematic approach.

2. TLS CipherSuite

From a layered perspective, TLS is composed of three main components:

Symmetric encryption component , e.g., AES‑128‑GCM (the most common choice in 2015).

Authenticated key‑exchange component , e.g., RSA‑ECDHE.

Key‑expansion component , e.g., TLS‑PRF‑SHA256.

These components are further broken down into five algorithm categories that together form a CipherSuite:

Authentication (authentication algorithm)

Encryption (encryption algorithm)

Message authentication code (MAC)

Key exchange (key‑exchange algorithm)

Key derivation function (KDF)

TLS was designed to allow negotiation of these algorithms, enabling new algorithms to be added without changing the protocol. Each CipherSuite is registered with IANA and identified by a two‑byte value (see https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4).

Example of an OpenSSL cipher list entry:

0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH    Au=RSA   Enc=AESGCM(128)   Mac=AEAD

This indicates the CipherSuite ECDHE-RSA-AES128-GCM-SHA256 for TLS 1.2, using ECDHE for key exchange, RSA for authentication, AES‑128‑GCM for encryption, and SHA‑256 as the PRF.

Some CipherSuites are insecure and must be disabled, such as:

EXP / EXPORT – weak export‑grade algorithms, exploited by the FREAK attack.

eNULL / NULL – no encryption.

aNULL – no authentication, vulnerable to MITM.

ADH – anonymous DH, also lacks authentication.

For safe configuration, follow Mozilla’s recommended settings (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations) and copy‑paste the provided configuration.

3. Protocol Layering

TLS provides encrypted data transport, so its core is a symmetric encryption component. To establish shared keys, it includes an authenticated key‑exchange component, resulting in two primary sub‑protocols:

The Record protocol – handles symmetric encryption and packetization over TCP.

The Handshake protocol – performs authenticated key exchange.

Additionally, three auxiliary protocols exist:

ChangeCipherSpec – signals the switch from Handshake to Record (removed in TLS 1.3).

Alert – conveys error and warning codes.

Application Data – carries higher‑level payloads (HTTP, SMTP, etc.) inside the Record layer.

This authentication + symmetric encryption structure is common to most secure communication protocols.

Illustrations:

The following sections are based on translations of RFC 5246, RFC 5077, and RFC 4492.