Re: Set information in ClientHello TLS Extension as header
Hi Michael, On Sat, Jul 10, 2021 at 09:03:40AM +0200, Michael Stiller wrote: > Hi List, > > we have the following issue to solve: > > A client puts some data value into a TLS Extension section (reserved or > arbitrary id) in the ClientHello packet. I want to read this value and set a > request header with that value which should be available to the backend which > is designated to handle this request. Haproxy terminates / handles the SSL > connection. > > My current idea is to somehow send that packet to a SPOE program, parse the > ClientHello and send the value back to haproxy which sets the header. > > I am unsure if this is even remotely possible or which other options exist to > solve this. > > I especially don't know how to detect and send the ClientHello to the SPOE. There are some callbacks for some pieces of the client hello, but these are mostly used to extract SNI or client certificates. I don't know if there's anything standard to extract arbitrary TLS extensions. > So some pointers or ideas are greatly appreciated. Please could you have a look at ssl_sock.c:ssl_sock_switchctx_cbk() ? There are some calls to certain SSL functions to retrieve some such info, I don't know if they can be used for what you have in mind. Willy
Re: Long broken option http_proxy: should we kill it ?
On 08.07.21 19:44, Aleksandar Lazic wrote: On 08.07.21 18:33, Willy Tarreau wrote: Hi all, Amaury discovered that "option http_proxy" was broken. I quickly checked when it started, and it got broken with the introduction of HTX in 1.9 three years ago. It still used to work in legacy mode in 1.9 and 2.0 but 2.0 uses HTX by default and legacy disappeared from 2.1. Thus to summarize it, no single version emitted during the last 2.5 years saw it working. As such I was considering removing it from 2.5 without prior deprecation. My opinion is that something that doesn't work for 2.5 years and that triggers no single report is a sufficient indicator of non-use. We'll still need to deploy reasonable efforts to see under what conditions it can be fixed and the fix backported, of course. Does anyone object to this ? For a bit of background, this option was added 14 years ago to extract an IP address an a port from an absolute URI, rewrite it to relative and forward the request to the original IP:port, thus acting like a non-resolving proxy. Nowadays one could probably achieve the same by doing something such asthe following: http-request set-dst url_ip http-request set-dst-port url_port http-request set-uri %[path] And it could even involve the do_resolve() action to resolve names to addresses. That's why I'm in favor of not even trying to keep this one further. +1 to remove Funny part, there was a question in SO about this topic ;-) https://stackoverflow.com/questions/68321275/unable-to-implement-haproxy-as-forward-proxy-for-https Thanks, Willy
[PR] fix: TYPED_DATA typos for UINT64
Dear list! Author: Willem van der Schyff Number of patches: 1 This is an automated relay of the Github pull request: fix: TYPED_DATA typos for UINT64 Patch title(s): fix: TYPED_DATA typos for UINT64 Link: https://github.com/haproxy/haproxy/pull/1316 Edit locally: wget https://github.com/haproxy/haproxy/pull/1316.patch && vi 1316.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/1316.patch | git am - Description:   Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
Set information in ClientHello TLS Extension as header
Hi List, we have the following issue to solve: A client puts some data value into a TLS Extension section (reserved or arbitrary id) in the ClientHello packet. I want to read this value and set a request header with that value which should be available to the backend which is designated to handle this request. Haproxy terminates / handles the SSL connection. My current idea is to somehow send that packet to a SPOE program, parse the ClientHello and send the value back to haproxy which sets the header. I am unsure if this is even remotely possible or which other options exist to solve this. I especially don’t know how to detect and send the ClientHello to the SPOE. So some pointers or ideas are greatly appreciated. Best regards, Michael Stiller
