By Eco research. Updated April 2026.
​

Transport Layer Security (TLS) is a cryptographic protocol that encrypts and authenticates data sent between two parties over a network, most visibly as the "S" in HTTPS. Every time a browser loads a website over HTTPS, a dApp connects to a JSON-RPC endpoint, or a wallet fetches a token balance, TLS is running underneath to prevent eavesdropping and impersonation. TLS 1.3, published in IETF RFC 8446 in 2018, is the current standard, reducing the connection setup to a single round trip.
​

TLS is a protocol that operates between the transport layer (TCP) and the application layer (HTTP, WebSocket, JSON-RPC). It provides three guarantees: confidentiality (data is encrypted so third parties cannot read it), integrity (data cannot be altered in transit without detection), and authentication (the server proves its identity with a certificate signed by a trusted Certificate Authority). TLS replaced SSL (Secure Sockets Layer), its predecessor, which was deprecated after critical vulnerabilities in SSLv3 and TLS 1.0 were disclosed between 2011 and 2015.
​

TLS is not a single algorithm but a negotiated composition of components: a key exchange algorithm, an authentication algorithm, a symmetric cipher, and a hash function for message authentication. In TLS 1.3, the set of allowed cipher suites was reduced to five, all using forward-secret key exchange (ECDHE) and AEAD ciphers. Previous cipher suites that supported RSA key exchange (which lacks forward secrecy) and older block ciphers like 3DES and RC4 were eliminated entirely. Forward secrecy means that even if a server's private key is later compromised, past sessions cannot be decrypted because session keys are derived ephemerally and never transmitted.
​

As of 2024, Cloudflare Radar data shows that roughly 80% of all internet traffic uses TLS 1.3, up from about 50% in 2021. TLS 1.2 remains widely deployed for compatibility with legacy clients. TLS 1.0 and 1.1 are effectively obsolete: the IETF formally deprecated them in RFC 8996 (March 2021), and major browsers removed support the same year.
​

The TLS 1.3 handshake establishes a shared secret and authenticates the server (and optionally the client) in a single round trip. The client sends a ClientHello containing supported cipher suites and a key share generated with an ephemeral ECDH private key. The server responds with a ServerHello, its own key share, and its certificate, then immediately sends Finished. The client verifies the certificate chain, derives the same session keys from the shared ECDH output, and sends its own Finished. From that point, all application data is encrypted with AES-GCM or ChaCha20-Poly1305.
​

TLS 1.3 also supports 0-RTT resumption for returning clients. A client that has connected before can send application data in its first message, before the handshake completes, using a session ticket from the previous connection. The security trade-off is that 0-RTT data is not forward secret (an attacker who steals the session ticket can replay it) and is not protected against replay attacks. Most TLS implementations therefore limit 0-RTT to idempotent requests and disable it for state-mutating operations. For blockchain RPC endpoints, where a single call might submit a signed transaction, 0-RTT requires careful handling by the RPC provider.
​

The complete session key derivation in TLS 1.3 uses the HKDF (HMAC-based Key Derivation Function) to produce separate keys for handshake encryption and application data encryption, as well as separate keys for each direction of the connection. This design means compromising one direction's key does not reveal the other direction's traffic. The cipher suite TLS_AES_128_GCM_SHA256 is the most commonly negotiated: AES-128-GCM for authenticated encryption with a 128-bit key, and SHA-256 for the HKDF and transcript hash.
​

TLS authentication depends on a chain of trust rooted in Certificate Authorities (CAs). A CA is an organization that verifies the identity of a certificate applicant and issues a signed certificate attesting that the public key in the certificate belongs to the named entity. Browsers and operating systems ship with a built-in list of trusted root CAs, roughly 150 to 200 organizations as of 2024. A server certificate signed by any trusted root CA (or by an intermediate CA that chains to a trusted root) will be accepted by any client that trusts that root.
​

Let's Encrypt, launched in 2015 by the Internet Security Research Group with backing from Mozilla, EFF, and Cisco, automated certificate issuance using the ACME protocol and made 90-day DV (Domain Validated) certificates free. By March 2024, Let's Encrypt reported issuing certificates covering over 500 million active certificates. The project substantially accelerated HTTPS adoption by eliminating the cost and manual process previously associated with certificate management.
​

The CA system has known weaknesses. A compromised or misbehaving CA can issue fraudulent certificates for any domain, enabling man-in-the-middle attacks. Several high-profile CA compromises have occurred: DigiNotar was compromised in 2011 and issued fraudulent certificates for google.com, used by the Iranian government to intercept Gmail traffic. As a result, the industry developed Certificate Transparency (CT), standardized in RFC 6962, which requires all publicly trusted CAs to log every certificate they issue to publicly auditable append-only logs. Browsers including Chrome enforce CT by refusing to trust certificates not present in the CT logs since 2018.
​

Blockchain RPC endpoints, wallet backends, and indexer APIs all use TLS in the same way any HTTPS API does. When a wallet like MetaMask or Rainbow sends a request to an RPC endpoint such as eth-mainnet.g.alchemy.com, that request travels over TLS. The wallet's HTTP client performs a TLS handshake, verifies the server's certificate against the operating system's trusted CA store, and then sends the JSON-RPC payload over the encrypted channel. Without TLS, a network observer could read the wallet address, pending transaction details, and token balances from the request and response payloads.
​

RPC providers including Alchemy, Infura, and QuickNode all terminate TLS at their load balancers and forward plaintext traffic internally. The security boundary is between the client and the provider's edge, not between the client and the individual Ethereum node. This is the same architecture used by any major cloud API. Providers typically enforce TLS 1.2 minimum and prefer TLS 1.3 for clients that support it.
​

WebSocket connections used for subscriptions (like eth_subscribe for pending transactions or new block headers) also run over TLS, using the WSS (WebSocket Secure) protocol. WSS is simply the WebSocket protocol upgraded on top of an existing TLS connection, in the same way HTTPS is HTTP over TLS. A raw WS connection (without TLS) exposes the full subscribe/notify message stream to any network observer on the path.
​

Hardware wallets communicate differently. Ledger and Trezor devices connect to companion applications over USB or Bluetooth, not over TLS. The companion application then communicates with backend services over HTTPS/TLS. Some hardware wallet firmware updates are delivered over HTTPS with certificate pinning in the companion software, a separate security measure described in the next section.
​

Certificate pinning is a technique where a client application hardcodes the expected certificate or public key for a specific server, rather than trusting any CA-signed certificate. If the server presents a different certificate, even one signed by a valid CA, the connection is rejected. Pinning eliminates the risk that a CA compromise or a rogue certificate could be used to intercept traffic to that specific server. The trade-off is operational rigidity: certificate rotations require updating the pin in the application, and a misconfigured pin takes the service offline for users of the old app version.
​

In Web3 specifically, certificate pinning is most relevant for:

Browser extensions like MetaMask cannot use certificate pinning in the same way mobile apps can, because Chrome's network stack manages certificate validation and does not expose a pinning API to extensions. MetaMask instead validates the RPC endpoint URL configured by the user and displays warnings for plaintext HTTP endpoints, but cannot enforce that the HTTPS certificate matches a specific expected fingerprint.
​

TLS and blockchain cryptography serve different purposes and use different trust models. The table below compares them across the dimensions that matter most for Web3 application developers.
​

TLS protects the transport channel: it ensures that a signed transaction submitted by a wallet arrives at an RPC node without being read or modified in transit. Blockchain ECDSA signatures ensure the transaction was authorized by the private key holder. The two systems are complementary. A TLS connection without transaction signatures would be secure in transit but accept transactions from anyone. ECDSA transaction signatures without TLS would authenticate the transaction but expose it to modification during relay. Production Web3 infrastructure requires both.
​

An RPC endpoint without valid TLS is an active attack surface. An attacker positioned between a user and their RPC provider (on a shared network, through a malicious router, or via a BGP hijack) can read unsigned RPC responses, inject fake responses claiming a transaction was mined when it was not, or return a manipulated balance to mislead a trading bot. In 2018, attackers successfully hijacked BGP routes for Amazon Route 53 DNS to redirect myetherwallet.com users to a phishing server; the victims' browsers showed a certificate error, but many users clicked through. TLS with strict certificate validation would have prevented the session from establishing at all.
​

RPC providers that support TLS 1.3 with HSTS (HTTP Strict Transport Security) eliminate one class of downgrade attacks. HSTS instructs browsers and clients to never attempt a plaintext connection to a domain, so an attacker who strips TLS from a redirect would cause a connection failure rather than silently downgrading the user to HTTP. The HSTS preload list, maintained by Google and respected by all major browsers, allows domains to be hardcoded as HTTPS-only before the first connection is ever made.
​

Eco's routing layer communicates with solver networks, bridge APIs, and onchain settlement contracts. Every external API call in the path uses TLS 1.3 endpoints, and internal service mesh communication uses mutual TLS (mTLS), where both the client and server present certificates. mTLS ensures that even if an attacker gains access to the internal network, they cannot impersonate a service without holding a valid certificate issued by the internal CA.
​

HTTPS is HTTP running over a TLS connection. TLS is the underlying cryptographic protocol; HTTPS is the combination of HTTP semantics with TLS transport security. A URL that begins with "https://" means the browser will establish a TLS connection before sending any HTTP data. Port 443 is the default for HTTPS, while HTTP uses port 80.
​

No. TLS authenticates that you are talking to the server that owns the certificate, not that the server is honest. A malicious or compromised RPC provider with a valid TLS certificate can still return fabricated data. For high-value transactions, verify critical state onchain using a local node or multiple independent RPC providers. Services like storage proofs allow applications to verify RPC responses against onchain state without trusting the provider.
​

Mutual TLS (mTLS) requires both client and server to present certificates, allowing both sides to verify each other's identity. Standard TLS only requires the server to present a certificate. mTLS is used in internal microservice communication (service meshes like Istio and Linkerd default to mTLS), hardware wallet companion app security, and enterprise custody APIs where every caller must be authenticated.
​

Current quantum computers cannot break TLS, but sufficiently large fault-tolerant quantum computers could break the ECDH key exchange and RSA used in TLS today using Shor's algorithm. The NIST Post-Quantum Cryptography standardization project finalized the first post-quantum algorithms in 2024, including CRYSTALS-Kyber for key exchange. TLS 1.3's modular design means key exchange algorithms can be replaced without changing the overall protocol structure.
​

Sources and methodology. TLS adoption statistics from Cloudflare Radar (Q1 2026). Let's Encrypt certificate issuance from letsencrypt.org/stats. Protocol specifications verified against IETF RFCs 8446, 8996, and 6962. Figures reflect published standards as of April 2026.
​