On 11/19/2020 1:37 PM, Howard Chu wrote:
This would require that you actually read and process the proxy header immediately after the accept call. It strikes me that this is the wrong thing to do, if you also want to support TLS.
Unless I'm misunderstanding the specification, that is the only way it would work. The TLS negotiation, barring TLS interception by the proxy, is between the client and the backend server, not between the proxy and the backend server. The proxy would have no way to inject encrypted data into that communication. The "proxy" protocol is also used not just for application level proxies, but also for basic network level load-balancing. Those systems have no idea if TLS is in use are not, they are just shuffling packets back and forth between two endpoints, so again would have no way to insert encrypted data into the TLS layer.
The proxy protocol data is always shimmed in at the very beginning of the connection before the initial data supplied by the client, the server sucks it out and then passes the client data and the rest of the connection traffic to the protocol level.
This does seem to make it susceptible to man in the middle attacks where someone could swap out the proxy protocol data, but I think the general assumption is that the connection between the proxy/load balancer and the backend server is within a trusted network where such an attack is not a concern.
