Develop an User-mode Intercepting (Non-)Transparent Proxy for Windows

Develop an user-mode intercepting (non-)transparent proxy targeting Windows, in order to intercept web browsing and email communication for the purpose of providing additional service (security, privacy etc.). The proxy should support the following application protocols: • For web browsing control o Ability to inspect/alter any HTTP request or response  URL  Content o Protocol support:  HTTP 1.x  HTTP 2  HTTP 3 (over QUIC) • For email control o Ability to inspect/alter any incoming/outgoing email  Sender & Recipient Info  Attachments Info o Protocol support:  SMTP  POP3  IMAP • Unknown - for Traffic Passthru o Could be any TCP/UDP traffic The proxy should support the following flexibility: • Ability to exclude a connection from interception, based on any of the following information: o Remote Target IP Address / Port o TLS Connections: SNI o Client Application Path Target OS: Windows 7, Windows 8, Windows 10 (x86 & amd64) Programming Environment/Language: • Solution/IDE: Visual Studio 2017/2019 • Language: C Design/Implementation Considerations: Network Implementation: The core network module should use Asynchronous Windows Sockets Programming technique using IOCP (utilizing a common thread-pool for TCP & UDP) to perform connect/accept/send/recv. Use of any cross-platform async io library that can abstract the underlying Windows-specific implementation is preferred, as this can later be ported to different platforms (Linux/MacOS) easily, however, this isn't a must-have requirement at present. A single-listening/bound port should be used for all redirected incoming TCP and UDP communication. Existing Packet-Divert packages such as WinDivert ( [login to view URL] ) maybe utilized for performing the required redirection of application(eg:- webbrowsers, email-clients) traffic (TCP & UDP) to the above mentioned port. Application Traffic Identification: The initial packet can be inspected to identify prospective handlers for the traffic, TLS traffic can be decrypted within the process (by acting as server to the client, and as client to the remote server). The plaintext packet data can be used to identify prospective application protocol handlers. Some form of extensible architecture where additional protocols can be added for support is desired. TLS Traffic Processing: The proxy server can generate a Per-Machine Self-Signed Root CA certificate under the Trusted Publishers of the system (similar to tools such as Fiddler, CharlesProxy etc.). TLS Connections (by detecting initial Client Hello), can be conditionally decrypted by generating a fake Server certificate based on the remote server’s certificate, but signed by the locally generated/trusted CA. Third-Party Library Usage (if any) should be limited to C-based libraries with commercial-usage friendly requiring no source-code disclosure (Eg:- MIT License). A few potential libraries that maybe used for TLS & HTTP traffic processing have been identified, and listed below: • HTTP/1.x - [login to view URL] • HTTP/2 - [login to view URL] • QUIC/HTTP/3 - [login to view URL] & [login to view URL] • OpenSSL (Patched) - [login to view URL] Deliverables: • High Level Design document • Full source code transfer