Exported Authenticators (ExpAuth) are a feature in the TLS 1.3 protocol designed to provide mutual authentication after an encrypted session has already been established. Essentially, they allow for client or server authentication to be performed after the initial handshake has completed, without needing to renegotiate a new session. This is useful in scenarios where authentication is deferred or where multiple parties need to authenticate during the same secure connection.
In TLS 1.3, the initial handshake sets up a secure encrypted session between a client and server. During this handshake, the server typically authenticates itself to the client using a certificate, and optionally, the client may authenticate itself as well.
However, there are scenarios where it’s beneficial to authenticate after the session has already started, rather than during the handshake. This is where Exported Authenticators (ExpAuth) come into play. They allow for additional or deferred authentication using certificate-based authentication after the handshake is complete, leveraging the existing secure session.
Session Established: First, a TLS 1.3 session is established between the client and server. This session is already encrypted and secure.
Authenticator Export: During or after the session, either the client or server can generate an exported authenticator, which is essentially a cryptographic proof of identity tied to the established session.
Deferred Authentication: Exported Authenticators allow for deferred or additional authentication to take place after the secure connection has been established, which can be useful in multi-phase authentication processes.
No Need for Renegotiation: Traditional TLS would require renegotiating a session to perform new authentication steps. Exported Authenticators avoid this by using the existing session, reducing overhead and potential security issues related to renegotiation.
Mutual Authentication: Both the client and server can authenticate each other during an ongoing session, making it ideal for environments where multi-party authentication is required.
A common use case for Exported Authenticators might be a secure web service that initially only requires the server to authenticate to the client during the TLS handshake (like most HTTPS connections). Later in the session, when the client tries to access sensitive resources, the server may request the client to authenticate using an exported authenticator, without breaking or renegotiating the existing connection.
The correlation between TLS (Transport Layer Security) versions and HTTP (Hypertext Transfer Protocol) versions revolves around securing communication between clients (like web browsers) and servers (like websites). While HTTP defines how data is structured and transferred, TLS provides the encryption layer that secures that data in transit.
Although TLS and HTTP are separate protocols with distinct functions, they often work together. Below is a breakdown of their relationship through different versions.
HTTP/1.1: - Introduced in 1997. - Uses a text-based request-response model (e.g., GET and POST methods). - Works with both non-secure (HTTP) and secure (HTTPS) protocols. HTTPS in HTTP/1.1 is enabled by adding TLS encryption on top of it (via a handshake before the HTTP data is transferred). - Can use multiple versions of TLS (e.g., TLS 1.0, 1.1, 1.2, and 1.3).
HTTP/2: - Introduced in 2015. - Binary-based, instead of text-based, which makes it more efficient. - Designed to support multiplexing (sending multiple requests at once over a single connection), header compression, and server push. - Often used exclusively over TLS, and many browsers require HTTP/2 to be used with TLS 1.2 or higher. It improves performance but relies heavily on encryption.
HTTP/3: - Built on top of QUIC (a transport layer protocol that integrates security natively). - Uses TLS 1.3 exclusively as its encryption mechanism, but it handles the TLS handshake within QUIC, not separately as in earlier versions.
TLS 1.0 (deprecated): - Released in 1999. It had several vulnerabilities, which led to its deprecation. - Compatible with HTTP/1.1, but generally not recommended anymore.
TLS 1.1 (deprecated): - Released in 2006. Like TLS 1.0, it is now deprecated due to security flaws.
TLS 1.2: - Released in 2008. Still widely used and supported by most browsers and services. - Compatible with both HTTP/1.1 and HTTP/2. - Provides strong encryption and more robust security mechanisms compared to its predecessors.
TLS 1.3: - Released in 2018. It simplifies the handshake process and enhances security and performance. - Compatible with HTTP/1.1, HTTP/2, and HTTP/3. - HTTP/3, built on QUIC, requires TLS 1.3 due to its more efficient handshake and stronger security features.
| HTTP Version | TLS Version Compatibility |
|---|---|
| HTTP/1.1 | TLS 1.0, 1.1, 1.2, 1.3 (modern sites use 1.2 or 1.3) |
| HTTP/2 | TLS 1.2, TLS 1.3 (1.2 is most common) |
| HTTP/3 | TLS 1.3 only |
A datagram is a basic unit of data transfer in a packet-switched network. It is a self-contained, independent packet that carries information necessary for its delivery. Datagrams are used in communication protocols where reliability and ordering are not guaranteed, such as the User Datagram Protocol (UDP).
User Datagram Protocol (UDP):
Unicast and Anycast are two different methods of routing network traffic to deliver data to its destination.
Unicast is a one-to-one communication method where data is sent from one specific sender to one specific receiver. Each receiver has a unique IP address, and the data is sent directly to that IP address.
Anycast is a one-to-nearest communication method where data is sent from one sender to the nearest or best receiver out of a group of potential receivers. All the potential receivers share the same IP address, but the network directs the data to the closest one.
Google:
Cloudflare:
Synthetic testing is a method used to measure and analyze the performance and functionality of a website or application by simulating user interactions in a controlled environment. Unlike Real User Monitoring (RUM), which gathers data from actual users, synthetic testing uses automated tools to create virtual users that interact with the website or application.
Google: Google uses synthetic testing to monitor the performance of its search engine and other services. By simulating user interactions, Google can detect and address performance issues before they affect real users.
Amazon: Amazon employs synthetic testing to ensure that its e-commerce platform remains fast and reliable. By running tests from various locations, Amazon can optimize its website for users around the world.
In the last month I learned so much more than what I learned in the almost two years at my last job.
Is it easy? No, not all. It is a extremely complicated area and unfortunately, the day only have 24hrs.
Am I enjoying it? Hell yes! I’m exhausted and my brain has zero capacity, but the satisfaction I’m getting is worthy.
So yeah, a rollecoaster of emotions.
]]>Real User Monitoring (RUM) is a method used to measure and analyze the performance of a website or application based on real users’ interactions. It involves collecting data from actual users in real-time as they interact with a website, rather than relying solely on synthetic tests or simulations.
Google:
Amazon:
These resources provide further details and technical documentation on implementing and utilizing RUM for performance monitoring and optimization.
]]>Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) protocol that allows a client to specify the hostname it wants to connect to at the start of the TLS handshake process. This is particularly useful when multiple websites are hosted on the same IP address, allowing the server to present the correct SSL/TLS certificate for the requested hostname.
Cloudflare: Cloudflare uses SNI to provide SSL/TLS protection for websites on their content delivery network. This allows them to secure multiple websites hosted on the same IP address with different SSL certificates.
Amazon Web Services (AWS): AWS uses SNI in services like Amazon CloudFront and Elastic Load Balancing to enable secure connections for multiple domains on a single server or load balancer.
Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft, which allows users to connect to and control another computer over a network. It provides a graphical interface to the user, allowing them to log into the remote computer and interact with its desktop as if they were physically present at that location.
Microsoft is the primary company using and developing RDP, integrating it into their Windows operating systems. Many businesses use RDP to allow employees to work from home or to access their office computers remotely.
Amazon Web Services (AWS) offers services like Amazon WorkSpaces, which provides RDP-based virtual desktops to businesses, allowing users to access their desktop environments from any device.
RDP was introduced by Microsoft in 1998 with the release of Windows NT 4.0 Terminal Server Edition and has since become a standard tool for remote desktop access. It follows the T.128 application sharing protocol as its base.
MoQ stands for “Media over QUIC.” It’s like a special helper that makes sure videos and games can get to you quickly and smoothly over the internet.
It is an emerging protocol designed to facilitate the efficient streaming and real-time delivery of media content, such as videos and audio, over the QUIC protocol. QUIC (Quick UDP Internet Connections) is a transport layer network protocol developed by Google, which combines the benefits of TCP and UDP to provide a faster and more reliable internet experience.
Google, a pioneer in developing QUIC, is actively involved in the standardization and implementation of MoQ. By integrating MoQ into its media services, Google can offer improved streaming quality and reduced latency for platforms like YouTube and Google Meet. This enhances user experience by providing smooth playback and real-time interaction, even under varying network conditions.