TLS is a transport layer security protocol, used to protect data at application layer. It is mainly designed for TCP applications. Higher layer protocols can layer up on top of TLS. There are multiple versions of TLS: TLS 1.0, TLS 1.1, TLS 1.2 and TLS 1.3. Here we will be discussing about TLS 1.3. TLS 1.3 standard is : RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (rfc-editor.org). TLS ensures that data is encrypted, authenticated, and remains private and integral. TLS encrypts the data being transmitted which ensures confidentiality.
TLS secure channel provides the following properties:
- Authentication: Server side is always authenticated, client side authentication is optional.
- Confidentiality: Data is only visible to endpoints.
- Integrity: Data cant be modified by attackers without detection.
TLS has two components:
- A handshake protocol: This is used to authenticate endpoints, negotiate cryptographic modes and parameters, establishes shared keying material. It is designed to resist tampering, the attacker cant be able to force the peers to negotiate different set of paraters.
- A record protocol uses parameters established by the handshake protocol. It divides the traffic into a series of records and protects them using traffic keys.
TLS handshake protocol consists of 3 phases:
- Key exchange: Establishes shared keying material and selects cryptographic parameters
- Server parameters: Establishes other handshake parameters.
- Authentication: Authenticates server and optionally client.
Below diagram showing the sequence of messages in the TLS handshake protocol:
- ClientHello: Client initiates the handshake with this message. It can contain the information of list of cipher suites, supported finite/elliptical DH groups and public keys, signature algorithms and corresponding certificates, preshared key extensions.
- ServerHello: Server will respond to ClientHello with a ServerHello message, containing the selected cipher suite, supported_versions extension, key_share and/or pre_shared_key extensions.
- Encrypted Extensions: Server must send this message after ServerHello. This can have server_name, max_fragment_length, supported_groups, use_srtp, heartbeat, app_layer_protocol_negotiation, client_certificate_type, server_certificate_type, early_data extensions information which is encrypted.
- Certificate: The certificate message will have the certificate information that is used for authentication.
- CertificateVerify: Signature over value: transcript-hash(handshake_context, certificate)
- Finished: A MAC over value transcript hash(handshake context, certificate, certificateVerify) using MAC key.
Following table defines the handshake context and MAC base key:
Transcript hash is used to ensure the integrity and authenticity of the handshake process. It is computed by hashing the concatenation of all handshake messages exchanged between the client and server, including the handshake message headers but excluding the record layer headers.
Some of the post handshake messages are:
- New Session Ticket messages allow clients to resume previous sessions without performing a full handshake.
- Post-Handshake Authentication (PHA) in TLS 1.3 allows clients and servers to authenticate each other after the initial handshake has been completed. This feature is particularly useful in scenarios where authentication needs to be deferred or additional identities need to be verified during an ongoing session.
- Key and Initialization Vector update is used to indicate that sender is updating its sending cryptographic keys.
TLS Record Protocol
The TLS Record Protocol is responsible for encapsulating higher-level protocol messages, such as handshake messages and application data, into records. These records are then encrypted, compressed, and transmitted over a secure channel. Here are the key components and functions of the TLS Record Protocol as specified in RFC 8446:
- Fragmentation: Messages are fragmented into blocks. Each block is then encapsulated into a record.
- Compression: The protocol allows for the possibility of compressing data before encryption.
- Encryption: Each record is encrypted using the negotiated cipher suite. This ensures the confidentiality and integrity of the data being transmitted.
- Message Authentication: A Message Authentication Code (MAC) is added to each record to ensure data integrity and authenticity. In TLS 1.3, authenticated encryption (AEAD) modes are used, which combine encryption and authentication into a single operation.
- Record Header: Each record has a header that includes information such as the content type (e.g., handshake, application data), version, and length of the record.
- Transmission: The encrypted records are transmitted over the network to the peer, where they are decrypted and reassembled into the original messages.
Alert Protocol
The alert protocol in TLS 1.3 is a mechanism used to signal errors and other conditions during a TLS session. Alerts are used to notify the peer about errors or other important events. Each alert message consists of two bytes: Level and Description
- Level: Indicates the severity (
warningorfatal). Warning indicates non-fatal issues that do not require the connection to be terminated. Fatal indicates serious errors that result in immediate termination of the connection. - Description: Provides specific information about the alert (e.g.,
close_notify,unexpected_message). Close_notify indicates that the sender will not send any more messages. Unexpected_message is an inappropriate message was received. Handshake_failure is used when the sender was unable to negotiate acceptable security parameters.
The key schedule in TLS 1.3 is a structured process for deriving the cryptographic keys used throughout a TLS session. Here’s a detailed overview:
Key Schedule in TLS 1.3
The key schedule in TLS 1.3 is a structured process for deriving the cryptographic keys used throughout a TLS session. Here’s a detailed overview:
- Initial Secret: This is derived from the pre-shared key (PSK) or the Diffie-Hellman (DH) key exchange. It forms the basis for all subsequent keys.
- Early Secret: Derived from the initial secret, this is used for early data (0-RTT data) encryption. It allows the client to send data to the server before the handshake is complete.
- Handshake Secret: Derived from the early secret, this is used during the handshake phase to secure handshake messages. It ensures the integrity and confidentiality of the handshake process.
- Master Secret: Derived from the handshake secret, this is used to generate the final session keys. It is the foundation for the keys used in the application data phase.
- Application Traffic Keys: These are derived from the master secret and are used for encrypting application data after the handshake is complete. They ensure the confidentiality and integrity of the data exchanged during the session.
Key Hierarchy:
- Early Traffic Keys: Used for encrypting early data (0-RTT data).
- Handshake Traffic Keys: Used for securing handshake messages.
- Application Traffic Keys: Used for encrypting application data post-handshake.
TLS 1.3 supports periodic key updates to enhance security by refreshing encryption keys during a session. This process ensures that even if a key is compromised, the impact is limited to a short period.
0-RTT and Anti replay
0-RTT is a feature in TLS 1.3 that allows clients to send data to the server immediately after the initial handshake, without waiting for the server’s response. This can significantly reduce latency and improve performance, especially for repeated connections. During the first connection, the client and server perform a full handshake and establish a session. For subsequent connections, the client can use the previously established session parameters to start sending data immediately, without waiting for the server to complete the handshake.
Anti-replay mechanisms are crucial for 0-RTT because the data sent during this phase is vulnerable to replay attacks. Replay attacks occur when an attacker intercepts and retransmits the data, potentially causing unintended actions on the server. Servers can implement mechanisms to detect and reject replayed messages. This often involves keeping track of previously seen messages and their timestamps. Using unique session tickets for each connection can help mitigate replay attacks by ensuring that each session is distinct. Limiting the rate at which 0-RTT data is accepted can reduce the impact of potential replay attacks.
mbedTLS library
Mbed TLS is an open-source library designed to provide cryptographic and SSL/TLS capabilities for embedded systems and applications. Mbed TLS is widely used in various applications, including IoT devices, secure communications, and any system requiring robust cryptographic security. Here’s a brief overview:
- Cryptographic Primitives: Implements essential cryptographic algorithms like AES, RSA, ECC, and SHA.
- SSL/TLS Protocols: Supports SSL and TLS protocols, including the latest TLS 1.3, ensuring secure communication over networks.
- X.509 Certificates: Provides tools for handling X.509 certificates.
- Portable and Lightweight: Designed to be highly portable and suitable for resource-constrained environments, making it ideal for embedded systems.
- Configurable: Offers a highly configurable codebase, allowing developers to enable or disable features as needed to optimize for their specific use case.
Integration of mbedTLS with applications
- Include Headers: Add the necessary Mbed TLS headers to your source files. eg.
#include "mbedtls/ssl.h"
#include "mbedtls/net_sockets.h"
#include "mbedtls/entropy.h"
#include "mbedtls/ctr_drbg.h"- Initialize Mbed TLS Components: Initialize the required Mbed TLS components (e.g., entropy, random number generator, SSL context). eg.
mbedtls_ssl_context ssl;
mbedtls_ssl_config conf;
mbedtls_entropy_context entropy;
mbedtls_ctr_drbg_context ctr_drbg;
mbedtls_ssl_init(&ssl);
mbedtls_ssl_config_init(&conf);
mbedtls_entropy_init(&entropy);
mbedtls_ctr_drbg_init(&ctr_drbg);Set Up the SSL/TLS Connection
- Configure SSL/TLS Parameters: Set up the SSL/TLS parameters, such as the protocol version, cipher suites, and certificates. eg.
mbedtls_ssl_config_defaults(&conf,
MBEDTLS_SSL_IS_CLIENT,
MBEDTLS_SSL_TRANSPORT_STREAM,
MBEDTLS_SSL_PRESET_DEFAULT);
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_OPTIONAL);
mbedtls_ssl_conf_rng(&conf, mbedtls_ctr_drbg_random, &ctr_drbg);
mbedtls_ssl_setup(&ssl, &conf);- Establish the Connection: Use the configured SSL context to establish a secure connection. eg:
mbedtls_net_context server_fd;
mbedtls_net_init(&server_fd);
mbedtls_net_connect(&server_fd, "example.com", "443", MBEDTLS_NET_PROTO_TCP);
mbedtls_ssl_set_bio(&ssl, &server_fd, mbedtls_net_send, mbedtls_net_recv, NULL);
mbedtls_ssl_handshake(&ssl);Handle Data Transmission
- Send and Receive Data: Use the SSL context to securely send and receive data.
const char *request = "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n";
mbedtls_ssl_write(&ssl, (const unsigned char *)request, strlen(request));
unsigned char buffer[1024];
int len = mbedtls_ssl_read(&ssl, buffer, sizeof(buffer) - 1);
buffer[len] = '\0';
printf("Received: %s\n", buffer);Clean Up: Clean up and free the allocated resources. eg.:
mbedtls_ssl_free(&ssl);
mbedtls_ssl_config_free(&conf);
mbedtls_entropy_free(&entropy);
mbedtls_ctr_drbg_free(&ctr_drbg);
mbedtls_net_free(&server_fd);KTLS
KTLS (Kernel TLS) is a feature that allows Transport Layer Security (TLS) encryption and decryption to be offloaded to the kernel space, rather than being handled in user space. This can improve performance and efficiency for applications that require secure communication:
- Performance Improvement: By handling TLS operations in the kernel, KTLS can reduce the overhead associated with context switching between user space and kernel space.
- Reduced Latency: KTLS can lower latency for secure connections, making it beneficial for high-performance applications.
- Resource Efficiency: Offloading TLS operations to the kernel can free up resources in user space, allowing applications to run more efficiently.
Here’s how KTLS works
- Integration with Sockets: KTLS integrates with the existing socket API, allowing applications to use it without significant changes to their code.
- Kernel Modules: It relies on kernel modules to handle the encryption and decryption processes.
- Compatibility: KTLS is designed to be compatible with existing TLS libraries and protocols, ensuring a smooth transition for applications.
Please provide some pointers of how to integrate mbedTLS with KTLS.
Introducing Jyo Services — Your Go-To Partner for Tech Solutions
Are you looking to boost your career or bring your tech ideas to life? Jyo Services offers a range of specialized solutions tailored just for you:
- One-on-One Interview Preparation: Tailored coaching for freshers and professionals with up to 7 years of software development experience.
- Custom Software Development: Expertise in embedded technologies, AI/ML, Gen AI, Cyber Security, Linux-based applications, and network protocol developments.
- Patent Assistance: Comprehensive support for drafting, filing and maintaining patents in India.
- College Projects: Professional guidance for Engineering students on academic projects.
Unlock your potential with Jyo Services! Contact us today to get started.
DM me at: www.linkedin.com/in/jyothivs or jyos.v.s@gmail.com
References
