Hello to readers of the haproxy list, This is my first-ever mail to the list, to propose my first-ever contribution to the project, so I apologize in advance if anything here runs afoul of your customs. I hope I've come close enough to make it worth your while.
What I'm proposing has been coded up here: https://github.com/slimhazard/haproxy/commit/2093dc54f0d5f7d0fb30c918c2c7689b8764bec1 And of course I can send a git-formatted patch to the list (but my understanding is that an RFC discussion is preferred first). The idea is probably best understood from a sample config: listen fe # ... server s0 0.0.0.0:0 ssl verify none forward-dst-sni This is only relevant for the case of "forwarding" the client's destination address, by using 0.0.0.0 or * in the server config. When the new option 'forward-dst-sni' is enabled for such a server, then for clients who send an authority TLV in the PROXY header, the SNI for the backend is set to the value of the TLV. The use case is for clients who want to use haproxy's "address forwarding" feature, but also need to communicate with backends via haproxy that use SNI for "virtual hosing with SSL". With this feature they can do that by using PROXYv2 and TLV. The option is a NOP for servers that don't have the 0.0.0.0/* config. When it's enabled for such a server, and when the authority TLV is sent, then the authority value overrides any SNI set in the client TLS handshake. The rationale is that if a client goes to the trouble of sending the TLV, then they want that to be used for the SNI (otherwise they can just let the SNI be passed on from the client TLS). I considered adding a test in reg-tests, but I don't see a way to set a PROXY TLV value using VTest and haproxy (happy to be corrected if I'm wrong). But we do have some varnishtest VTCs for it here, for a PR that my colleague and I are working on for Varnish: https://github.com/slimhazard/varnish-cache/blob/proxy_via_authority/bin/varnishtest/tests/c00100.vtc https://github.com/slimhazard/varnish-cache/blob/proxy_via_authority/bin/varnishtest/tests/c00101.vtc As for the coding, I suspect that my newbie status with haproxy shows mostly in the way space is allocated for the authority string, which the patch adds as a new field to struct connection. Since the feature is likely to be used only rarely, it doesn't seem sensible to foresee all of the space for a host name right in the struct. In the patch I have it as a pointer to struct buffer, which is NULL unless the authority TLV is read from the PROXY header. It seemed to make sense to use a memory pool for the allocation, but it also felt like overkill to add a new memory pool just for this feature. So in the patch I'm just using the "trash pool". Aside from the fact that the name "trash pool" makes me think that it might not be meant to be used this way, if I understand correctly the default allocation size is 16KiB, and users are advised not to reduce it. That's far too large for a host name (usually max 255 bytes). So I suspect that this may not be best practice for haproxy. Maybe define a dedicated pool after all? I'd be grateful for any feedback about the feature and the code (or anything else). And of course I can send a patch to the list if you're interested. Thanks, Geoff Simmons -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstraße 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de
signature.asc
Description: OpenPGP digital signature
