WEB / WEB-05.01

TLS guarantees and cryptography

Separate channel guarantees using key roles and plaintext delivery boundaries.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Verified record

Protected channel condition
Path, hostname and handshake key proof are selected to succeed. Client user identity remains an application question.
Client · TLS
usable selected channel; plaintext ready
Server · TLS
usable selected channel; no record
Local record preparation
NOTES is selected for AEAD protection; aliases are not actual ciphertext or keys.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
usable selected channel; no record
Record reached the server
Wire arrival carries only a ciphertext/header/tag summary; no plaintext has been accepted.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
record received; verification pending; app delivery=none
Local AEAD check
Selected verification succeeds; local delivery remains separate.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
AEAD valid; verified NOTES; app unread
Application delivery boundary
Authenticated bytes were delivered locally; no business commit is established.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
app read=NOTES; commit unmodeled

Integrity failure

Protected channel condition
Path, hostname and handshake key proof are selected to succeed. Client user identity remains an application question.
Client · TLS
usable selected channel; plaintext ready
Server · TLS
usable selected channel; no record
Local record preparation
NOTES is selected for AEAD protection; aliases are not actual ciphertext or keys.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
usable selected channel; no record
Record reached the server
Wire arrival carries only a ciphertext/header/tag summary; no plaintext has been accepted.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
record received; verification pending; app delivery=none
Local AEAD check
Selected verification fails; no plaintext reaches the application.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
AEAD invalid; plaintext withheld; app delivery=none
Application delivery boundary
No application side effect is selected after failure; the actual error cause is not measured.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
channel unusable; app delivery=none; cause unmodeled

Identity failure

Independent reference identity
The expected DNS-ID is selected from the URL; the server certificate does not redefine it.
Client · TLS
reference=api.example.org; checks pending
Server · TLS
selected certificate context; no application data
Path condition
Path success is selected; hostname matching remains pending.
Client · TLS
path=true; hostname pending; app data unsent
Server · TLS
selected certificate context; no application data
Hostname mismatch
A different SAN name does not match the reference identity; key proof does not repair it.
Client · TLS
path=true; hostname=false; app data unsent
Server · TLS
selected certificate context; no application data
Transmission gate closed
No protected application record is selected; encryption is not authority.
Client · TLS
peer identity rejected; recordSent=false
Server · TLS
selected certificate context; no application data

ACTORS · STATE · DATA FLOW

HTTP semantics alone do not secure a channel

HTTP methods, statuses and header rules do not by themselves prove who the peer is or that bytes remain private in transit. An https URI requires secure communication to the selected origin and certificate verification; changing one letter in a URL does not execute those mechanisms. This lesson selects an ordinary certificate-authenticated HTTPS channel using TLS 1.3.

HTTP application semantics and transport/cryptographic protection have separate responsibilities. QUIC-based HTTP/3 also protects communication, but does not carry TLS records as TCP does. The record example here belongs to TLS-over-TCP; it produces no HTTP response, application authorization or persistence result.

Three guarantees answer different questions

Confidentiality keeps protected application bytes from a channel observer; integrity detects changes before acceptance; authentication binds negotiated keys to a verified peer. Compressing these into one “encrypted” label can make any peer with a public key appear to be the expected server.

The client independently constructs a reference identity for api.example.org; certificate path, hostname and handshake proof are selected to succeed. This supplies the server authentication assumption. No client certificate is requested: establishing TLS does not tell the server that its user is Duru or may read a report. User identity and authorization belong to the application.

Symmetric keys protect directional traffic

TLS 1.3 protects records with AEAD. Alias c-app-0 represents the client write key and the server read key for that direction; s-app-0 represents the reverse direction. These have distinct direction and phase scopes. Encrypting every HTTP byte with the certificate public key is not this model.

AEAD takes a key, nonce, plaintext and authenticated additional data. In TLS, the record header enters the AAD; the nonce is derived from the direction’s write IV and record sequence. The artifact exposes no actual key or nonce bytes. Nonce uniqueness under a key and key usage limits matter; copying one nonce alias to every record is not a valid design.

Asymmetric roles: agreement and signature

The selected new connection uses ephemeral X25519 key shares to calculate a shared secret; a private share is not transmitted. HKDF derives separate traffic secrets and keys from shared input and handshake context. The long-term certificate key instead signs CertificateVerify to bind possession proof to the handshake context. The CA certificate signature has a different signer and signs different content.

“Encrypt with the private key, decrypt with the public key” is not a correct general definition of a signature. Signature verification does not open message plaintext; key agreement is not signing either. This X25519 branch does not cover every TLS profile: PSK and combined modes exist, and the current TLS text also distinguishes KEM extensions. Forward secrecy depends on selected ephemeral agreement and secret-management assumptions; it does not promise protection for endpoint plaintext.

A record arrived but is not yet delivered

The scene separates arrival of a protected record, local AEAD verification and local application delivery at the server. Seeing record header, ciphertext and tag bytes does not establish accepted plaintext. In the integrity-failure branch, the selected AEAD check fails; plaintext is not delivered to the application and the channel is not treated as usable.

Some cryptographic APIs return provisional plaintext during deprotection; those bytes are not authenticated until verification completes. Final verification failure must not leave an application side effect that already started. This separates reading ciphertext, obtaining authenticated plaintext and application consumption into three boundaries; one verification failure does not establish the actual cause of an error.

HTTPS stops at its endpoints and application boundaries

A TLS terminator can read application bytes. With termination at a reverse proxy, browser-to-proxy and proxy-to-upstream protection are separate channel and policy questions; protecting the first does not prove protection on the second. TLS also does not hide destination IP, traffic timing and lengths entirely; padding can reduce some observations but provides no anonymity guarantee.

Valid path, hostname and key proof identify the selected server; a certificate does not certify content accuracy, absence of harmful behavior or resource permissions. The current source is RFC9846, which obsoletes RFC8446 while retaining TLS version 1.3. Teaching aliases are not a real TLS stack, public trust store or certificate capture.

Read every scenario without motion

Identity gate

Encrypted-channel predicates were separated
In identity-failure, path and key-proof predicates pass but the hostname does not match. Intended identity api.example.org is therefore not accepted. One passing gate does not repair another gate’s failure.
Channel predicates
Path passes / hostname fails
Acceptance gate
No acceptance gate
Application boundary
No application delivery
The acceptance gate is a conjunction
path, hostname, keyProof are peer-authentication predicates; usable channel and successful AEAD verification are separately required for plaintext delivery. One true predicate does not cancel another failure.
Channel predicates
Path passes / hostname fails
Acceptance gate
Independent predicates retained
Application boundary
No application delivery
Premature trusted plaintext was stopped
Hostname failure gives recordSent=false and applicationDelivered=null. Protected application sending is not selected before intended identity acceptance.
Channel predicates
Path passes / hostname fails
Acceptance gate
Independent predicates retained
Application boundary
applicationDelivered=null
Key roles stayed distinct
leaf-sign-public verifies signatures, c-eph-public is an agreement share and c-app-0 is client-write/server-read. A public share replaces neither private signing nor directional traffic keys.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Independent predicates retained
Application boundary
applicationDelivered=null
TLS is not user entitlement
This fixture proves neither TLS user authentication, resource authorization nor business outcome. A valid channel does not complete application role or tenant checks; business commit needs its own outcome.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Transport guarantees / app gates separate
Application boundary
applicationDelivered=null
The failure boundary stayed in place
The identity gate stops sending early. Endpoints can read plaintext and not all metadata is hidden; encryption does not imply every security property.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Transport guarantees / app gates separate
Application boundary
Identity rejected / record withheld

Integrity gate

Encrypted-channel predicates were separated
In integrity-failure, path, hostname and key proof are supplied as passing, while record AEAD verification fails. Accepted peer identity and authenticated record content are different outcomes.
Channel predicates
Identity passes / AEAD fails
Acceptance gate
No acceptance gate
Application boundary
No application delivery
The acceptance gate is a conjunction
path, hostname, keyProof are peer-authentication predicates; usable channel and successful AEAD verification are separately required for plaintext delivery. One true predicate does not cancel another failure.
Channel predicates
Identity passes / AEAD fails
Acceptance gate
Independent predicates retained
Application boundary
No application delivery
Premature trusted plaintext was stopped
aeadValid=false leaves applicationDelivered=null. Provisional decrypt output is not turned into an application side effect before verification completes.
Channel predicates
Identity passes / AEAD fails
Acceptance gate
Independent predicates retained
Application boundary
applicationDelivered=null
Key roles stayed distinct
leaf-sign-public verifies signatures, c-eph-public is an agreement share and c-app-0 is client-write/server-read. A public share replaces neither private signing nor directional traffic keys.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Independent predicates retained
Application boundary
applicationDelivered=null
TLS is not user entitlement
This fixture proves neither TLS user authentication, resource authorization nor business outcome. A valid channel does not complete application role or tenant checks; business commit needs its own outcome.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Transport guarantees / app gates separate
Application boundary
applicationDelivered=null
The failure boundary stayed in place
Record receipt may occur but verified-plaintext delivery does not. Cause is not diagnosed beyond the supplied Boolean condition; no actual AEAD or encoded record is produced.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Transport guarantees / app gates separate
Application boundary
Record rejected / application withheld

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: encryption supplies authority

An encrypted channel without verification of the intended hostname and certificate path does not establish the requested service identity. The necessary mistake is binding a channel to a public key while skipping its relationship to the expected service.

Keep certificate path, independently selected reference identity and handshake possession proof as separate requirements. TLS server identity must not be treated as an application role or tenant permission.

Broken assumption: decrypt output is accepted data

Processing provisional plaintext before final verification may leave an application side effect even after integrity failure. The required condition is consuming incomplete authentication output as trusted input.

The control is the delivery boundary for authenticated plaintext. The failure branch delivers no application bytes; the synthetic outcome does not diagnose the cause of a real error.

Broken assumption: TLS guarantees business rules

A valid channel does not repair missing application permissions. Endpoint plaintext and termination policy also form separate boundaries beyond TLS wire protection.

Keep operation scope, user authentication, authorization and upstream-channel requirements explicit. An HTTPS connection is not evidence of commit or once-only execution.

Read every scenario without motion

Directional keys

The aliases were interpreted
leaf-sign-private signs server CertificateVerify, c-eph-private participates in X25519 agreement and c-app-0 protects traffic. Aliases contain no secret bytes; secret=true is classification, not a shareable credential.
Key-role evidence
Inert signing/agreement/traffic aliases
Verification review
No receipt scope
Guarantee review
No guarantee review
Direction was matched at both peers
c-app-0 is client-write/server-read, while s-app-0 is server-write/client-read. Reusing one alias for both sending directions breaks the key-role ledger contract.
Key-role evidence
Inert signing/agreement/traffic aliases
Verification review
c-app-0 ↔ client→server
Guarantee review
No guarantee review
Record evidence is not encoding
NOTES is ASCII plaintext, ciphertext/tag are opaque-teaching-alias and the nonce is c-seq-0-with-write-iv. realTlsRecordProduced=false; no key schedule or nonce bytes follow.
Key-role evidence
Semantic record aliases / no encoding
Verification review
c-app-0 ↔ client→server
Guarantee review
No guarantee review
Verification is separate from delivery
In the normal model, a record is sent and AEAD verification is supplied as successful. NOTES reaches the application only after that check. These are teaching predicates, not executed cryptographic verification or a network capture.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Supplied verified delivery: NOTES
Guarantee review
No guarantee review
The guarantee table retained its gaps
Peer authentication needs path/hostname/keyProof. User authentication, resource authorization and commit remain separate UNKNOWNs; endpointCanReadPlaintext=true and allMetadataHidden=false define the table’s scope.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Supplied verified delivery: NOTES
Guarantee review
TLS scope ≠ user/resource/business proof
Normal and failure baselines stayed separate
The client-write/server-read role of c-app-0 and NOTES delivery after verification appear as separate fields. Actual review needs the receiver's TLS verification result and an application-delivery record correlated to that connection. Ciphertext on the wire alone proves neither result; secret key bytes need not be collected.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Supplied verified delivery: NOTES
Guarantee review
Key directions consistent / app proof absent

Integrity evidence

The aliases were interpreted
leaf-sign-private signs server CertificateVerify, c-eph-private participates in X25519 agreement and c-app-0 protects traffic. Aliases contain no secret bytes; secret=true is classification, not a shareable credential.
Key-role evidence
Inert signing/agreement/traffic aliases
Verification review
No receipt scope
Guarantee review
No guarantee review
Direction was matched at both peers
c-app-0 is client-write/server-read, while s-app-0 is server-write/client-read. Reusing one alias for both sending directions breaks the key-role ledger contract.
Key-role evidence
Inert signing/agreement/traffic aliases
Verification review
c-app-0 ↔ client→server
Guarantee review
No guarantee review
Record evidence is not encoding
NOTES is ASCII plaintext, ciphertext/tag are opaque-teaching-alias and the nonce is c-seq-0-with-write-iv. realTlsRecordProduced=false; no key schedule or nonce bytes follow.
Key-role evidence
Semantic record aliases / no encoding
Verification review
c-app-0 ↔ client→server
Guarantee review
No guarantee review
Verification is separate from delivery
In integrity-failure, the record is sent but its AEAD check fails. No plaintext is delivered to the application. Separate observation points for receipt and verified delivery show that boundary.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Receipt yes / delivery no
Guarantee review
No guarantee review
The guarantee table retained its gaps
Peer authentication needs path/hostname/keyProof. User authentication, resource authorization and commit remain separate UNKNOWNs; endpointCanReadPlaintext=true and allMetadataHidden=false define the table’s scope.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Receipt yes / delivery no
Guarantee review
TLS scope ≠ user/resource/business proof
Normal and failure baselines stayed separate
This branch has record receipt but failed receiver verification, so NOTES delivery is skipped. Identity-failure instead stops before sending a record. Distinguishing them in practice needs separate identity-check, record-verification and application-delivery evidence for the connection; a missing record is not converted into success.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Receipt yes / delivery no
Guarantee review
Integrity fail / identity fail distinct

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Read the key-role ledger

Match aliases for certificate signing, ephemeral agreement and directional traffic keys. Explain why c-app-0 is the server read key and is not selected for the reverse direction.

A public key can be shared; a secret alias contains no secret material. Signature verification does not establish message secrecy or certificate trust.

Separate receipt, verification and delivery

In the normal branch, NOTES reaches the application only after successful local verification. The failure branch has arrival but no verified plaintext or application read.

The identity-failure branch shows declarative local conditions rather than a handshake: successful path checks alone do not select protected application transmission when the hostname does not match.

An AEAD consumer must keep provisional decryption output away from its parser and application state until verification completes. In the Node.js crypto example, decipher.update output is not yet authenticated; decipher.final completes that check. On failure, discard the provisional result and skip normal NOTES delivery. Check both successful delivery and complete plaintext withholding in the integrity-failure branch to verify the implementation boundary.

Connect the guarantee table to product decisions

Write the conditions for confidentiality, integrity and server authentication; keep user identity, authorization and business outcome separate. This constrains the claim that having TLS completes every security requirement.

In HTTP/3, QUIC performs packet protection. Do not use a TLS-over-TCP record ledger as QUIC packet encoding; these models reach similar channel goals using different carriage mechanisms.

NOW APPLY IT TO THE CASE

Why are identity, record integrity and business authority separate gates?

TLS peer acceptance for api.example.org needs path, hostname and key proof together. Failed AEAD verification withholds NOTES from the application. A valid TLS channel grants no user or resource entitlement.

Who is the peer of the case’s secure connection? Explain TLS peer trust, browser origin and user object permission as separate decisions.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas · tls-key-guarantee-ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "protocol": "TLS 1.3 over TCP",
    "currentSpecification": "RFC9846",
    "originalSpecification": "RFC8446 (obsoleted)",
    "handshake": "selected new certificate-authenticated X25519 branch",
    "referenceDnsId": "api.example.org",
    "clientCertificateRequested": false,
    "secretsExported": false
  },
  "keyRoles": [
    {
      "alias": "leaf-sign-public",
      "role": "CertificateVerify signature verification",
      "secret": false
    },
    {
      "alias": "leaf-sign-private",
      "role": "local server CertificateVerify signing",
      "secret": true
    },
    {
      "alias": "c-eph-private",
      "role": "local selected X25519 agreement",
      "secret": true
    },
    {
      "alias": "c-eph-public",
      "role": "ClientHello key share",
      "secret": false
    },
    {
      "alias": "s-eph-public",
      "role": "ServerHello key share",
      "secret": false
    },
    {
      "alias": "c-app-0",
      "role": "client write / server read, application phase",
      "secret": true
    },
    {
      "alias": "s-app-0",
      "role": "server write / client read, application phase",
      "secret": true
    }
  ],
  "record": {
    "plaintext": "NOTES",
    "encoding": "ASCII",
    "keyAlias": "c-app-0",
    "nonceAlias": "c-seq-0-with-write-iv",
    "aad": "TLS record header (semantic alias, no encoding)",
    "ciphertext": "opaque-teaching-alias",
    "tag": "opaque-teaching-alias",
    "realTlsRecordProduced": false
  },
  "cases": [
    {
      "case": "normal",
      "path": true,
      "hostname": true,
      "keyProof": true,
      "aeadValid": true,
      "recordSent": true,
      "applicationDelivered": "NOTES",
      "businessCommitProven": false
    },
    {
      "case": "integrity-failure",
      "path": true,
      "hostname": true,
      "keyProof": true,
      "aeadValid": false,
      "recordSent": true,
      "applicationDelivered": null,
      "businessCommitProven": false
    },
    {
      "case": "identity-failure",
      "path": true,
      "hostname": false,
      "keyProof": true,
      "aeadValid": null,
      "recordSent": false,
      "applicationDelivered": null,
      "businessCommitProven": false
    }
  ],
  "guaranteeScope": {
    "peerAuthenticationRequires": [
      "path",
      "hostname",
      "keyProof"
    ],
    "plaintextDeliveryRequires": "selected usable channel and successful AEAD verification",
    "tlsUserAuthenticationProven": false,
    "resourceAuthorizationProven": false,
    "businessOutcomeProven": false,
    "endpointCanReadPlaintext": true,
    "allMetadataHidden": false
  },
  "limits": "Aliases, conditions and outcomes only; no real certificate, TLS encoding, key schedule, nonce bytes, packet capture or network."
}

keyRoles: Distinct key responsibilities without secret bytes.
record: Inert protected-record summary for one direction and phase.
cases: Selected verification and delivery conditions.
guaranteeScope: Boundary separating channel guarantees from application decisions.

Key/certificate aliases and selected outcomes; no real TLS encoding, trust store or certificate verification.

Two reality checks

Every message verified with a public key is secret.

Signature verification checks an authenticity/integrity relationship; it does not encrypt the message.

HTTPS proves the user’s resource permission.

TLS protects a channel and authenticates the server; user authentication and authorization remain separate.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Path and hostname passed; the selected record has aeadValid=false. Is plaintext delivered to the application?

No; applicationDelivered remains null.
Yes; a trusted certificate permits accepting an invalid record.

Read the explained answer

No; applicationDelivered remains null. — Successful peer identity does not make failed record authentication valid; the selected delivery gate closes.

Why are these three key aliases not interchangeable?

Selected lesson artifact fields; teaching example

keyRoles[0]: {"alias":"leaf-sign-public","role":"CertificateVerify signature verification","secret":false}
keyRoles[2]: {"alias":"c-eph-private","role":"local selected X25519 agreement","secret":true}
keyRoles[5]: {"alias":"c-app-0","role":"client write / server read, application phase","secret":true}

One serves signature verification, one agreement, and one application traffic protection.
Every key inside TLS is the same symmetric encryption key.

Read the explained answer

One serves signature verification, one agreement, and one application traffic protection. — A key role depends on purpose; a public signing key is not an application-record write key.

NOTES was delivered in the normal TLS case. Why is separate evidence required for user identity and resource permission?

Read the explained answer

TLS preserves the selected service identity and channel confidentiality/integrity conditions. This profile requests no client certificate and supplies no TLS-user-authentication or resource-authorization outcome. Endpoints can read plaintext; TLS does not guarantee hidden metadata or a business commit.

□ I separated service identity from user identity.

□ I did not add resource permission to the TLS outcome.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

TLS 1.3 — current specification (2026)1 Introduction · 1.2 Relationship to RFC8446 · 2 Protocol Overview · 4.2 Hello Messages · 4.3 Extensions · 4.4.1 Encrypted Extensions · 4.5 Authentication Messages · 4.5.1 Certificate · 4.5.2 Certificate Verify · 4.5.3 Finished · 5.2 Record Payload Protection · 5.3 Per-Record Nonce · 7.1 Key Schedule · 7.4.2 Elliptic Curve Diffie-Hellman
TLS 1.3 — original specification (2018; obsoleted by RFC9846)2 Protocol Overview · 4.4.2 Certificate · 4.4.3 Certificate Verify · 4.4.4 Finished · 5.2 Record Payload Protection
Service Identity in TLS6.1.1 Constructing Reference Identifiers — Rules · 6.2 Preparing to Seek a Match · 6.3 Matching the DNS Domain Name Portion · 6.4 Matching an IP Address Portion · 7.7 Certificate Trust · Appendix A Changes from RFC6125
HTTP Semantics4.2.1 http URI Scheme · 4.2.2 https URI Scheme · 4.3.4 https Certificate Verification
Node.js v24 crypto API — local primitive evidencedecipher.update / decipher.final / decipher.setAuthTag · crypto.generateKeyPairSync · crypto.sign / crypto.verify · crypto.diffieHellman · decipher.update authenticated plaintext uncertainty

YOUR NOTES / THIS BROWSER

TLS guarantees and cryptography

1. Core · Mechanism

Verified record

Integrity failure

Identity failure

HTTP semantics alone do not secure a channel

Three guarantees answer different questions

Symmetric keys protect directional traffic

Asymmetric roles: agreement and signature

A record arrived but is not yet delivered

HTTPS stops at its endpoints and application boundaries

2. Red · Trust & Impact

Identity gate

Integrity gate

Broken assumption: encryption supplies authority

Broken assumption: decrypt output is accepted data

Broken assumption: TLS guarantees business rules

3. Blue · Secure development & defense

Directional keys

Integrity evidence

Read the key-role ledger

Separate receipt, verification and delivery

Connect the guarantee table to product decisions

Why are identity, record integrity and business authority separate gates?

Two reality checks

Path and hostname passed; the selected record has aeadValid=false. Is plaintext delivered to the application?

Why are these three key aliases not interchangeable?

NOTES was delivered in the normal TLS case. Why is separate evidence required for user identity and resource permission?

Sources and scope