feat: authenticate verified TCP peers with TLS - #7
Conversation
|
Warning Review limit reached
Next review available in: 26 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (30)
Comment |
|
@coderabbitai review Please review the exact current head |
|
|
|
@cwl-noema-review @opencode-agent Please perform an independent exact-head review of |
|
/oc Continue from the exact current head and inspect the latest function/line/region/branch coverage artifact before editing. Close every remaining production TLS path with tests first: handshake write-zero/read-EOF/no-progress/deadline/no-wants arcs; peer inspection and inherited peer mismatch; unsupported protocol, unoffered ALPN, trailing leaf DER; empty/excessive certificate bounds; optional no-application-protocol classification; and the required-empty-ALPN policy branch. Use only a narrow private deterministic test seam where concrete rustls/TcpStream state makes an error path unreachable. Preserve WebPKI, explicit roots/time, TLS 1.2/1.3, exact existing TCP peer, no reconnect/DNS, bounded certificate/ALPN/deadline inputs, credential-free evidence, and public API. Remove measurement/branch-writer workflows and generated diagnostic artifacts from the final tree. Run format, locked check, all tests, strict Clippy, rustdoc warnings-as-errors, exact nightly 100% function/line/region/branch coverage, Security Scan, and SAST. Resolve only addressed threads and keep Draft until the workflow-free exact head is fully green. Do not merge or bypass protection. |
Buyer-visible problem
OriginWeave can prove that a policy-approved address became the exact operating-system TCP peer, but TCP peer equality does not authenticate the requested HTTPS service. A trusted identity boundary must reject untrusted, expired, future-dated, wrong-name, malformed, or protocol-incompatible peers without reconnecting or weakening WebPKI.
Implemented vertical slice
originweave-tlscrate;DirectTcpConnectionwith no reconnect, DNS, proxy, PAC, HTTP, or Chromium authority;Exact-head verification
Verified at head
732c85afffc5328270bdac18ea28a008f60f6ecd:Standards and evidence
The implementation and doctoring records are grounded in RFC 5280, RFC 9525, RFC 9846, rustls primary documentation, and the repository's authority-boundary threat model. References are recorded in APA 7th form in
docs/doctoring.mdand ADR 0006.Out of scope
HTTP request/response parsing, proxy/PAC, QUIC/HTTP3, system trust discovery, OCSP/CRL fetching, client certificates, ECH, Chromium Network Service integration, downloads, MIME validation, and connection pooling remain separate independently reviewable slices.
Closes #6