基于端口敲门实现浏览器与本地服务的可靠信息传输方案问询

Great question—let’s break down how to address each of your requirements effectively, with a focus on Windows (your primary OS) while maintaining cross-platform compatibility for modern systems. We’ll leverage native IPC mechanisms and Windows-specific APIs to avoid common pitfalls like TLS certificate storage and antivirus TCP proxy interference.

Antivirus tools like Kaspersky and Sophos often proxy all TCP connections (including local loopback) for inspection, so relying on HTTP/WebSocket over TCP is risky. Instead, use non-TCP IPC mechanisms that bypass these proxies:

• Browser Native Messaging (Chrome/Firefox/Edge)
  This is the most reliable browser-native method. It lets the browser communicate directly with a local executable via stdin/stdout, no TCP involved—antivirus tools won’t intercept this since it’s pure process IPC.

  • On Windows, register a manifest file in HKCU\Software\Google\Chrome\NativeMessagingHosts\com.yourcompany.yourservice (per-user) or HKLM (system-wide) pointing to your service’s client executable.
  • The client executable runs in the same Windows login session as the browser, so it can safely pass requests to your system-level daemon.

• Named Pipes (Windows) / Unix Domain Sockets (Linux/macOS)
  If you need more flexibility than Native Messaging, use local IPC sockets. On Windows, named pipes (\\.\pipe\YourService_{SessionId}) are isolated per-session if you suffix them with the user’s session ID, and antivirus tools don’t proxy these.

  • The browser can connect to the pipe via a lightweight JavaScript wrapper (using a Native Messaging bridge, since browsers can’t directly access named pipes).

To map browser requests to the correct user session, use these Windows-specific techniques:

• Get Session ID from Browser Process
  When your Native Messaging client starts, it can get the browser’s process ID (passed via the Native Messaging protocol or via Windows APIs like GetWindowThreadProcessId on the browser window), then call ProcessIdToSessionId to retrieve the session ID.

  • Example code snippet (C++):

    DWORD sessionId;
    if (ProcessIdToSessionId(browserPid, &sessionId)) {
        // Use sessionId to identify the user's session
    }
    

• Retrieve User SID for Stronger Identification
  For definitive user identity, get the security identifier (SID) of the user running the browser:

  1. Open the browser process’s token with OpenProcessToken.
  2. Call GetTokenInformation with TokenUser to get the SID.
  3. Convert the SID to a string with ConvertSidToStringSid for easy storage/transmission to your daemon.

• Session-Aware Daemon Communication
  Your system-level daemon can listen on multiple named pipes (one per active session) or a single pipe that accepts session ID/SID metadata from the client, then routes requests appropriately.

Since we’re using local IPC (Native Messaging/named pipes), TLS isn’t necessary—Windows handles process isolation and security for these mechanisms. If you must use a network protocol (e.g., for cross-machine support), use these alternatives:

• In-Memory Generated Certificates
  Generate a temporary self-signed certificate when your service starts, store it only in memory, and discard it on shutdown. Use Windows APIs like CertCreateSelfSignCertificate to create the certificate without writing it to the system certificate store.

• Windows SSPI for Authentication
  Skip TLS entirely and use Windows’ built-in Security Support Provider Interface (SSPI) for NTLM/Kerberos authentication. This leverages the user’s existing Windows credentials, no certificates required, and works seamlessly with local services.

For Linux/macOS, mirror the Windows approach:

• Use browser Native Messaging (supported on all major browsers).
• Use Unix domain sockets instead of named pipes.
• Retrieve session/user info via getpid + getsid (Linux) or proc_pidinfo (macOS) to identify the user’s session.

内容的提问来源于stack exchange，提问作者Larytet