HTTPS · XB Field Notes

TLS handshakes add latency you can shrink

Mon, 28 Jun 2027 00:00:00 +0000

HTTPS latency combines several stages, and a warm request may avoid some without making cryptography faster. DNS, connection acquisition, TCP setup, TLS authentication, server work, and response transfer have different clocks. First determine which stages actually ran. Request duration alone cannot distinguish an existing connection from a new connection that resumed a TLS session.

Messages travel in flights

A TLS handshake contains several messages, but each message does not require its own round trip. Messages can travel together in a flight. A usual TLS 1.3 full handshake needs one TLS round trip before normal client application data; HelloRetryRequest adds another. TCP establishment and the later application request/response remain separate costs.

Ordinary TLS 1.3 resumption without early data also normally takes one TLS round trip. It can reduce certificate transmission and authentication work, but may still perform fresh ephemeral key exchange. Resumption derives new traffic keys rather than reusing old encryption keys unchanged. Optional 0-RTT is a separate facility with replay-related security limits, not a synonym for a fast repeat request.

HTTP connection reuse avoids establishing another connection entirely, so that request performs no new TLS handshake. HTTP/2 multiplexing can similarly share one established connection among streams. In contrast, closing an idle connection and opening another one still requires transport setup, even if a cached ticket lets TLS resume.

When it breaks

Creating a new transport for every normal request discards the connection pool. Leaving response bodies unread or unclosed can also prevent reuse. Idle timeouts, endpoint changes, or concurrent demand can create additional connections. Classify requests by observed reuse and handshake events before attributing a latency change to certificate algorithms.

A full handshake after attempted resumption is not necessarily an outage. Tickets can expire or be declined, and a client may lack usable cached state. Preserve normal certificate verification and measure the resulting behavior. Reducing authentication checks to win a benchmark would change the security contract, not simply improve the same operation.

Timing names need definitions. Time to first response byte includes more than TLS, while total request time also includes consuming the response. Trace hooks can run on different goroutines, so collectors need synchronization. Compare representative distributions and connection categories; a few loopback microsecond values cannot predict an Internet speedup.

Check it quickly

Save this as latency_probe.go and run go run latency_probe.go with Go 1.23 or newer. The fixture uses verified TLS 1.3 and HTTP/1.1. A server-side counter identifies accepted TCP connections. The first transport retains both an HTTP connection pool and a TLS session cache; a separate transport deliberately has no session cache.

package main

import (
 "context"
 "crypto/tls"
 "fmt"
 "io"
 "net"
 "net/http"
 "net/http/httptest"
 "net/http/httptrace"
 "runtime"
 "strconv"
 "sync"
 "sync/atomic"
 "time"
)

type connectionKey struct{}

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 var connections atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 w.Header().Set("X-Connection-ID", fmt.Sprint(r.Context().Value(connectionKey{})))
 w.Header().Set("X-Resumed", strconv.FormatBool(r.TLS.DidResume))
 fmt.Fprint(w, "ok")
 }))
 server.Config.ConnContext = func(ctx context.Context, _ net.Conn) context.Context {
 return context.WithValue(ctx, connectionKey{}, connections.Add(1))
 }
 server.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 defer server.Close()
 base := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 base.MinVersion, base.MaxVersion = tls.VersionTLS13, tls.VersionTLS13
 check(!base.InsecureSkipVerify, "certificate verification must stay enabled")
 cached := base.Clone()
 cached.ClientSessionCache = tls.NewLRUClientSessionCache(4)
 transport := &http.Transport{TLSClientConfig: cached}
 defer transport.CloseIdleConnections()
 fresh := &http.Transport{TLSClientConfig: base.Clone()}
 defer fresh.CloseIdleConnections()
 probe := func(label string, transport *http.Transport, wantID int64, wantReuse, wantResume bool) {
 started := time.Now()
 var mu sync.Mutex
 var handshakeStarted time.Time
 var handshakeError error
 var observation struct {
 got, starts, done, first int
 reused bool
 tlsTime, ttfb time.Duration
 }
 trace := &httptrace.ClientTrace{
 GotConn: func(info httptrace.GotConnInfo) {
 mu.Lock()
 defer mu.Unlock()
 observation.got++
 observation.reused = info.Reused
 },
 TLSHandshakeStart: func() {
 mu.Lock()
 defer mu.Unlock()
 handshakeStarted = time.Now()
 observation.starts++
 },
 TLSHandshakeDone: func(_ tls.ConnectionState, err error) {
 mu.Lock()
 defer mu.Unlock()
 observation.done++
 observation.tlsTime = time.Since(handshakeStarted)
 handshakeError = err
 },
 GotFirstResponseByte: func() {
 mu.Lock()
 defer mu.Unlock()
 observation.first++
 observation.ttfb = time.Since(started)
 },
 }
 request, err := http.NewRequest(http.MethodGet, server.URL, nil)
 must(err)
 request = request.WithContext(httptrace.WithClientTrace(request.Context(), trace))
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 response, err := client.Do(request)
 must(err)
 body, err := io.ReadAll(response.Body)
 closeError := response.Body.Close()
 must(err)
 must(closeError)
 total := time.Since(started)
 check(response.StatusCode == 200 && string(body) == "ok", "wrong response")
 check(response.Proto == "HTTP/1.1", "fixture requires HTTP/1.1")
 check(response.TLS.Version == tls.VersionTLS13 && len(response.TLS.VerifiedChains) > 0, "verified TLS 1.3 required")
 id, err := strconv.ParseInt(response.Header.Get("X-Connection-ID"), 10, 64)
 must(err)
 check(id == wantID && response.TLS.DidResume == wantResume, "wrong connection or resumption")
 check(response.Header.Get("X-Resumed") == strconv.FormatBool(wantResume), "peers disagree on resumption")
 mu.Lock()
 observed, tlsError := observation, handshakeError
 mu.Unlock()
 must(tlsError)
 wantHandshakes := 1
 if wantReuse {
 wantHandshakes = 0
 }
 check(observed.got == 1 && observed.first == 1 && observed.reused == wantReuse, "wrong request trace")
 check(observed.starts == wantHandshakes && observed.done == wantHandshakes, "wrong handshake count")
 check(total >= observed.ttfb && observed.ttfb > 0, "invalid response timing")
 fmt.Printf("%s: conn=%d reused=%t handshakes=%d connection_resumed=%t tls_us=%d ttfb_us=%d total_us=%d\n",
 label, id, observed.reused, observed.done, response.TLS.DidResume,
 observed.tlsTime.Microseconds(), observed.ttfb.Microseconds(), total.Microseconds())
 }
 probe("cold", transport, 1, false, false)
 probe("reuse", transport, 1, true, false)
 transport.CloseIdleConnections()
 probe("resume", transport, 2, false, true)
 probe("no cache", fresh, 3, false, false)
 check(connections.Load() == 3, "four requests must use three TCP connections")
 fmt.Println("timings are observations, not a speedup or wire-RTT assertion")
 fmt.Println(runtime.Version())
}

The invariant results are:

Request	TCP ID	Reused	New handshakes	DidResume
cold	1	false	1	false
reuse	1	true	0	false
resume	2	false	1	true
no cache	3	false	1	false

The second request keeps connection one. Closing idle connections before the third forces another TCP connection without discarding the TLS cache, so it resumes. The fourth request uses a transport with no cached session and performs a full handshake. Both peers’ resumption flags agree, and four HTTP requests use exactly three accepted TCP connections.

The article’s four requests use TCP IDs 1, 1, 2, and 3. Reuse has no new TLS event; resume opens TCP 2 with one resumed handshake; no cache opens TCP 3 with one full handshake. DidResume is connection state. These categories do not measure an Internet speedup, packet RTT, or early data.

DidResume describes how that connection was established, not whether the current HTTP request triggered resumption. Reusing a connection originally established by resumption can still report true without another handshake. Interpret this connection-level flag alongside the request’s reuse and handshake events, rather than counting every true response as a new resumed connection.

TLS timing spans TLSHandshakeStart through TLSHandshakeDone. TTFB starts before the request and ends when the first response-header byte becomes available; total ends after reading and closing the body. The reused row’s zero TLS duration means no new handshake event was observed. It does not mean an extraordinarily fast handshake or TLS 0-RTT.

All assertions passed on macOS with Go 1.27.0. Bodies are consumed and closed, trace state is mutex-protected, and each request has a two-second timeout. Session state stays in memory; no ticket, private key, or traffic secret is printed. On resumed connections, verified-chain state belongs to the authenticated session, not evidence of a newly transmitted certificate.

The timing numbers intentionally have no speedup assertion and will vary. This local experiment does not count packets or measure wire RTT, DNS, HTTP/2 or HTTP/3, early data, fleet ticket rotation, handshake CPU in isolation, or production latency distributions. Use the trace categories to structure those later measurements without treating this fixture as their result.

Sources

RFC 8446: TLS 1.3, handshake flights, resumption, and early-data limits, checked 2026-09-09.
Go net/http/httptrace, request hooks, handshake events, timing boundaries, and concurrency, checked 2026-09-09.
Go net/http, transport reuse and response-body lifecycle, checked 2026-09-09.
Go crypto/tls, session caching and negotiated resumption state, checked 2026-09-09.
Go net/http/httptest, isolated TLS servers and trusted test clients, checked 2026-09-09.

Audit the trust of a public edge

Thu, 06 Aug 2026 00:00:00 +0000

The web-security series treats settings as contracts with scope and failure modes. This walkthrough inspects a host you are authorized to query. The HTTP, TLS, and DNS requests are read-only observations, although they still generate logs and traffic. SSH checks read your own trust record; the deployment host may differ from the website hostname.

Use a disposable local working directory for captured output. No output shown here is a fresh measurement of www.xbcatm.com, and a passing command proves only the property it actually checks.

Each observation supports a bounded claim. Header presence, certificate dates and local records cannot combine into a whole-service safety badge.

1. Start with the policy the edge advertises

Fetch a GET response without silently following redirects, then inspect its status and headers:

host=www.xbcatm.com
url="https://$host/"
curl -sS --max-time 20 -D headers.txt -o body.html "$url"
cat headers.txt

The repository’s intended policy includes the following illustrative fields:

Content-Security-Policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

script-src 'none' is a strict choice for this script-free site, not a universal recipe for every static site. The browser enforces CSP; a report-only header does not block execution. Read the complete policy for more-specific script directives, and compare normal pages and error routes. nosniff constrains MIME handling, notably script/style destinations, but does not certify the body’s media type.

HSTS is learned from valid HTTPS responses and applies to the host that sent it. A policy received from www.example.com with includeSubDomains covers descendants of that name, not its sibling api.example.com or parent example.com. Inventory the actual scope before adopting a long duration. A proxy adding or stripping headers changes the browser contract, which is why artifact checks and edge checks are separate.

2. Verify TLS identity before reading certificate dates

SNI selects the intended virtual host; it does not verify the certificate name. Make verification failure fatal and explicitly request hostname validation. Use an up-to-date trust store appropriate to the clients under test.

openssl s_client -connect "$host:443" -servername "$host" \
 -verify_hostname "$host" -verify_return_error -showcerts \
 </dev/null > tls.txt 2> tls.log
# Continue only if the command succeeded; preserve tls.log on failure.
openssl x509 -in tls.txt -noout -subject -issuer -dates -ext subjectAltName

Run these as separate checked steps, or under a shell setup that stops on failure. Hiding stderr or piping into a successful x509 command can conceal an unsuccessful handshake. Inspect the DNS names in subjectAltName; the displayed subject CN is not sufficient for modern service-identity validation. Some library versions retain legacy CN fallback, so explicitly check that the expected SAN is present. A valid matching wildcard may be legitimate; an unrelated certificate is not.

notAfter gives the expiry time. It does not prove the chain is trusted, the hostname matches, or revocation was checked. Record the date and the measured safety window rather than relying on memory. OpenSSL’s result describes its configured trust store and checks, not every browser’s behavior.

3. Read the presented chain without inventing a fixed count

The -showcerts output contains certificates sent by the server, not a declaration that they form a verified chain. This command displays their count only:

grep -c 'BEGIN CERTIFICATE' tls.txt

There is no required count of four. The server normally supplies the leaf and necessary intermediate certificates; a root usually belongs in the client’s trust store and need not be sent. Chain length varies with the CA and chosen path. One certificate warrants investigating whether intermediates are needed, but a count alone is neither success nor failure.

Use the actual verification result from step 2, then investigate issuer/SAN changes, missing intermediates, expiry, and trust-store differences. An intermediate rotation can be normal CA maintenance. A numerically unchanged chain can still be wrong, and the count command does not automatically compare anything with an expected value.

4. Revalidate the captured representation

Caching is a separate contract, not evidence of TLS identity. Capture a current ETag and use it on a request selecting the same representation, as in the HTTP walkthrough. A matching conditional GET can return 304; a deployment between requests can legitimately produce 200. An old hardcoded validator is not a reusable test fixture for a changing site.

A no-script policy does not mean CSP never changes. Security headers can change independently of HTML, and a body ETag does not fingerprint every response header. Record the actual policy again after release.

5. Find the relevant CAA policy

CAA constrains issuance by compliant certificate authorities. It is not certificate pinning and does not retroactively invalidate an already issued certificate. Start by inspecting the queried name and its ancestors; retain response status so a DNS failure is not mistaken for an empty answer.

dig www.xbcatm.com CAA +noall +comments +answer
dig xbcatm.com CAA +noall +comments +answer

An empty answer at www does not mean issuance is unrestricted. RFC 8659 searches upward until the first relevant nonempty CAA set, following aliases during each lookup; continue through applicable ancestors if necessary. Inspect issue, and issuewild when wildcard issuance is involved. An iodef report address alone does not restrict issuance. If no restricting policy applies, CAA adds no issuer restriction, but normal domain validation and CA rules still apply.

Compare the CA’s documented CAA identifier with the relevant policy, not merely the leaf’s human-readable issuer CN. Today’s CAA result is evidence about today’s DNS policy, not proof of what existed when the certificate was issued.

6. Check the deployment host’s recorded SSH identity

Use the actual SSH destination, including the bracketed host/port form for a non-default port. ssh-keygen -F can find hashed known-host entries that a text grep of the hostname misses.

deploy_host=deploy.example.test
ssh-keygen -F "$deploy_host" -f "$HOME/.ssh/known_hosts" > host-record.txt
ssh-keygen -lf host-record.txt

Compare the fingerprint with an independently trusted record, such as the provider console or a verified administrator channel. This reads the local record; it does not prove which key the remote host presents now. A network key scan alone would not authenticate that key either. Investigate a changed key before updating trust; a rebuild is one possible explanation, not automatic permission to accept it.

Inspect all Set-Cookie fields in the captured response and any relevant redirect or application route. No cookie on one page does not establish that the entire site never sets cookies. A host-only cookie omits Domain; adding a parent Domain broadens the hosts receiving it. Path controls delivery but is not a security boundary against same-origin code.

Secure restricts transport, HttpOnly blocks script access to the cookie, and SameSite controls specified cross-site sending behavior. They address different risks and do not replace one another; SameSite=None requires Secure in modern browsers. For this site’s no-account content model, ask why a cookie is needed at all before broadening its scope. Redact cookie values from shared audit records.

Keep a bounded audit record

Record the UTC time, client versions, requested/final URL, status, enforcing headers, TLS verification result and dates, relevant CAA lookup, and SSH record source. Distinguish observed success, unexpected results, and checks not performed. These several observations take more than “two commands” and cannot prove the whole service secure.

Repeat the relevant checks after certificate, DNS, proxy, or deployment changes. Preserve prior results to identify drift, and test actual browser behavior separately when the claim depends on browser enforcement.

Sources

WHATWG Fetch Standard, nosniff processing and request destinations, checked 2026-10-15.
OpenSSL s_client, SNI, hostname verification, fatal verification errors, and presented chains, checked 2026-10-15.
RFC 9525: Service Identity in TLS, SAN-based service identity and wildcard matching, checked 2026-10-15.
RFC 8659: CAA, relevant record-set search and issuance policy, checked 2026-10-15.
RFC 6797: HSTS, host scope and policy processing, checked 2026-10-15.
OpenSSH ssh-keygen, known-host lookup and fingerprint display, checked 2026-10-15.
W3C: CSP Level 3, enforcing versus report-only policy and script directive fallback (working draft), checked 2026-10-15.
MDN: Set-Cookie, cookie attributes and their limits, checked 2026-10-15.

Read the public edge in two commands

Mon, 13 Jul 2026 00:00:00 +0000

A deployment is complete when public responses match the release contract, not when the last upload exits zero. Two read-only helpers from the operator kit expose useful evidence, but they do not prove the whole artifact was published correctly.

These are illustrative excerpts. Evaluate HTTP status and expiry separately; verify hostname, trust and body equality with the checks that actually test them.

Inspect the response headers

check-http-headers.sh performs a GET, discards the body, follows redirects, and prints the response headers for each hop plus the final status and URL:

check-http-headers.sh https://www.xbcatm.com/

This illustrative output shows the fields to inspect. It is not a fresh production observation:

HTTP/2 200
accept-ranges: bytes
content-security-policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:
content-type: text/html; charset=utf-8
last-modified: Mon, 24 Aug 2026 11:20:54 GMT
permissions-policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), microphone=(), payment=(), usb=()
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
x-frame-options: DENY

HTTP_STATUS 200
FINAL_URL https://www.xbcatm.com/

Check the expected status, final host and path, and the policy on the final response. The helper does not use curl’s --fail: an HTTP 404 or 500 can still leave the shell command successful. Treat its printed status as data to evaluate. A header mismatch warrants investigation of server, proxy, or cache configuration; it does not by itself prove the wrong output directory is live.

Inspect the certificate dates

check-tls-expiry.sh HOST [DAYS] extracts the certificate presented with SNI and checks whether its expiry is at least the requested number of seconds away:

check-tls-expiry.sh www.xbcatm.com 30

An illustrative excerpt, with the fingerprint line omitted:

subject=CN=www.xbcatm.com
issuer=C=US, O=Let's Encrypt, CN=YE1
notBefore=Aug 21 08:37:13 2026 GMT
notAfter=Nov 19 08:37:12 2026 GMT

certificate remains valid for at least 30 day(s)

The helper prints subject, issuer, dates, and SHA-256 fingerprint. It does not print the remaining day count. Its success message describes the expiry test only: the script does not enforce hostname or trust-chain validation, and -checkend does not validate notBefore. The subject CN is not sufficient hostname evidence; service identity is matched against the certificate’s subject alternative names. A valid wildcard may legitimately cover the host.

Use a separate verification when those properties matter:

openssl s_client -connect www.xbcatm.com:443 -servername www.xbcatm.com \
 -verify_hostname www.xbcatm.com -verify_return_error </dev/null

This uses the configured trust store and fails on certificate verification errors under OpenSSL’s matching rules. In OpenSSL 3.0, hostname verification can fall back to the subject CN when no suitable DNS subject alternative name is present. A successful command therefore does not by itself establish RFC 9525’s SAN-only identity policy: inspect the SAN extension and verify the intended client’s policy separately. Keep a job-level timeout around the TLS helper, which does not impose its own network deadline. Certificate inspection and automatic renewal configuration remain separate checks.

Use both around a release

Before: save the expected policy, final URL, validators, and certificate dates with a UTC collection time.
Deploy the already validated artifact.
After: repeat the probes and fetch representative bodies for comparison with that artifact.

Headers and certificate dates cannot establish byte equality. Last-Modified may stay unchanged or be rewritten during copying. The release smoke test saves bodies and compares them directly; a complete manifest extends that check beyond one page. Browser behavior, geographic edge differences, and load-dependent failures need separate tests. Record which paths and observation points were actually checked.

Sources

curl manual, GET, redirect, header output, and HTTP failure behavior, checked 2026-10-15.
OpenSSL s_client, SNI, explicit hostname checks, and failure on verification errors, checked 2026-10-15.
OpenSSL verification options, hostname matching and subject-CN fallback, checked 2026-10-15.
OpenSSL x509, certificate display and expiry-only -checkend behavior, checked 2026-10-15.
RFC 9525 — Service Identity in TLS, subject alternative names and wildcard identity matching, checked 2026-10-15.
Caddy Automatic HTTPS, automatic certificate management and renewal configuration, checked 2026-10-15.
MDN: Content Security Policy guide, CSP directive background, checked 2026-07-13.
RFC 9110 — HTTP Semantics, response metadata and validators do not establish a complete artifact match, checked 2026-10-15.

HTTPS · XB Field Notes

TLS handshakes add latency you can shrink

Messages travel in flights

When it breaks

Check it quickly

Further reading

Sources

Audit the trust of a public edge

1. Start with the policy the edge advertises

2. Verify TLS identity before reading certificate dates

3. Read the presented chain without inventing a fixed count

4. Revalidate the captured representation

5. Find the relevant CAA policy

6. Check the deployment host’s recorded SSH identity

7. Keep cookie scope no broader than necessary

Keep a bounded audit record

Sources

Read the public edge in two commands

Inspect the response headers

Inspect the certificate dates

Use both around a release

Sources