Transparent proxy and SSL protocol

A transparent proxy is essentially similar to an interception. The client thinks it is the server that you want to access. In fact, this access has already been taken over by the so-called transparent proxy, the transparent proxy host redirects user access to the local application layer proxy process, and obtains the address information that the user needs to access from the HTTP header sent by the user, then, the proxy user can access the service or implement a policy-based service according to the local configuration. A reasonable mode is VPN applications. To facilitate management, users generally need our company's proxy server to provide Internet services, however, if a user uses the confidential laptop assigned by the company during a business trip, he must connect to the company's network through a VPN and then access the Internet through the company's proxy server. In this mode, I used a simple way to describe the idea, that is, not considering the VPN details, that is, not considering the network layer, but on the application layer. After all, proxy processes all work at the application layer. I use Stunnel (APT-Get or RPM or make install in Linux, and then man or info) as the Proxy Server client that the user directly connects, using another stuunel as the server, the two stuunel are connected through the SSL protocol, which is undoubtedly safe. This connection is not a persistent connection, but an SSL connection is initialized to the Stunnel server only when stuunel receives the user's access request. The user's access process reaches the Stunnel server through this SSL connection, and then forwarded to the Real Server. There are several details here. How does the Stunnel client know the address the user wants to access, and how does the Stunnel client send this information to the server, and then let the server area proxy user access the real address.
If the Stunnel client cannot inform the Stunnel server or the Stunnel server of the actual address to be accessed by the user and does not process it, this can only partially implement a reverse proxy, Which is configured in advance, therefore, the user's actual access address must be transmitted to the server. The first detailed answer is to first redirect all access requests to the Local Machine (using iptables), then parse the HTTP header initiated by the user to obtain the original address information, if it is not an HTTP protocol but a common TCP or UDP application, because the address information is not necessarily stored in the protocol header, you must use another method to obtain the original address information, this is an IOCTL call. Linux provides a netfilter command to obtain the original address information before redirection, including the IP address and port. Now, no matter which application, HTTP or common TCP, the original address information is obtained. Because our proxy server is not locally located at the remote end, the second problem has been solved for a long time, we have to write the Protocol to transmit this information to the server. Now, it is not that troublesome. In the case of the SSL protocol, the new SSL protocol specification is introduced in rfc5246, in the Hello Message initiated by the client, an extension field is added, that is, the client can send some attachment information to Se during the Hello message. Rver, so you can transmit the original address information obtained by the client to the server in this Hello message. After the SSL connection between the client and the server is initialized, server can use the original address obtained from client-hello to initiate a connection to the real address to implement a transparent proxy.