smartproxy/readme.plan.md

Plan: Fallback to NetworkProxy on Missing SNI

When a TLS ClientHello arrives without an SNI extension, we currently send a TLS alert and close the connection. Instead, if NetworkProxy is in use, we want to forward the connection to the network proxy first, and only issue the TLS error if proxying is not possible.

Goals

• Allow TLS connections with no SNI to be forwarded to NetworkProxy when configured for any domain.
• Only send a TLS unrecognized_name alert if proxy forwarding is unavailable or fails.

Plan

• In ts/smartproxy/classes.pp.connectionhandler.ts, locate the SNI-block branch in handleStandardConnection that checks allowSessionTicket === false && isClientHello && !serverName.
• Replace the direct TLS alert/error logic with:
  • If NetworkProxy is enabled (global useNetworkProxy setting or an active NetworkProxy instance), call this.handleNetworkProxyConnection(socket, record) (passing the buffered ClientHello) before issuing a TLS alert.
  • Supply an error callback to forwardToNetworkProxy; if proxying fails or no NetworkProxy is available, fall back to the original TLS alert sequence.
• Ensure existing metrics and cleanup (record.incomingTerminationReason, termination stats) are correctly tracked in the forwarding error path.
• Add or update unit tests to simulate a TLS ClientHello without SNI on port 443 and verify:
  • When NetworkProxy is enabled, the connection is forwarded to the proxy.
  • If proxy forwarding fails or the domain is not configured, a TLS alert is sent and the socket is closed.
• Run pnpm test to confirm no regressions and that the new behavior is correctly covered.