Hi all, The following patch provides support for TCP proxying to httpd.
It consists of the following three parts:
- mod_tcp: Allows the frontend to receive pure TCP connections
- mod_proxy_tcp: Allows the proxy to make pure tcp or tls connections to a
backend
- mod_ssl_tcp: Allows the proxy to route incoming connections based on the SNI
header (tlsext)
In the following example config, incoming TCP connections are routed based on
their SNI (the tlsext protocol) to given backend servers, which then complete
the SSL connections as raw tunnels.
This allows you to use client certificates through the httpd proxy balancer all
the way to the backend server without the proxy terminating any SSL along the
way.
<VirtualHost localhost:9000>
Protocol tlsext
ServerName jira.example.com
ProxyPass / tcp://john.example.com:443
</VirtualHost>
<VirtualHost localhost:9000>
Protocol tlsext
ServerName www.example.com
ProxyPass / tcp://erica.example.com:443
</VirtualHost>
In order for mod_ssl_tcp to work, it needs to read ahead to see if any client
hello message is present, and then set aside any extra data so it could be read
again. This is fundamentally incompatible with c->data_in_input_filters which
only allows the core filter to set aside unread data. For this reason the
ability to set aside data was rolled out to all filters.
mod_ssl_tcp just cares about SNI for now, but could conceivably support APLN
too, making a configuration something like this:
<VirtualHost localhost:9000>
Protocol tlsext
ServerName secure.example.com
<Protocol imap>
ProxyPass / tcp://imap.example.com:993
</Protocol>
<Protocol pop>
ProxyPass / tcp://pop3.example.com:995
</Protocol>
</VirtualHost>
Regards,
Graham
--
httpd-tcp-proxy.patch
Description: Binary data
