TLS 1.3 handshake fails against real HTTPS servers (google.com, example.com, wikipedia.org) #216

The browser cannot load any real HTTPS page. The very first record received from the server isn't recognised as a TLS handshake record, so read_handshake_message returns Malformed(\"expected handshake record\").

Repro#

cargo run -q -p we-e2e -- --url https://example.com --out /tmp/x.png
cargo run -q -p we-e2e -- --url https://www.google.com --out /tmp/x.png
cargo run -q -p we-e2e -- --url https://httpbin.org/get --out /tmp/x.png
cargo run -q -p we-e2e -- --url https://en.wikipedia.org/wiki/HTTPS --out /tmp/x.png

All four fail with:

render error: fetch https://...: Network(Tls(Malformed(\"expected handshake record\")))

http://example.com over plain HTTP renders successfully, so DNS / TCP / HTTP-1.1 paths are fine. The defect is isolated to the TLS 1.3 client in crates/net/src/tls/.

Source#

crates/net/src/tls/handshake.rs:591:

if record.content_type != ContentType::Handshake {
    return Err(HandshakeError::Malformed(\"expected handshake record\"));
}

Most likely root causes (need investigation):

• Server replied with a TLS Alert (record type 21) because our ClientHello is rejected — e.g. an offered version, cipher suite, signature algorithm, or supported group set that real servers don't accept.
• SNI extension missing or wrong (servers serving multiple certs over one IP would Alert immediately).
• ChangeCipherSpec (record type 20) coming before ServerHello and not being skipped (middlebox-compat).
• TLS 1.2 fallback being demanded by the server — our client may only speak 1.3.

Impact#

CRITICAL — the entire modern web is HTTPS-only. Without this, no real browsing is possible. This dwarfs every other rendering bug currently filed.

Acceptance#

• cargo run -p we-e2e -- --url https://example.com --out out.png succeeds and writes a non-empty PNG showing the example.com page.
• Same for https://www.google.com, https://en.wikipedia.org/, and https://httpbin.org/get.
• A new harness scenario crates/e2e/scenarios/https_smoke.we covers at least one HTTPS site so this regression doesn't return.
• The TLS client correctly handles the early ChangeCipherSpec record for middlebox compatibility (RFC 8446 §D.4) and offers a server-acceptable parameter set (at minimum: TLS 1.3, X25519, AES_128_GCM_SHA256, sni=hostname).

Found by the new e2e smoke harness.