On Thu, 6 Jun 2024, at 22:57, Aleksandar Lazic wrote:
> Hi.
>
> I was able to create a working setup with the attached patches, I'm
> pretty sure
> that the patch will need some adoptions until it' ready to commit to
> the dev branch.
>
> It would be nice to get some feedback.
Hi Alex,
This is pretty exciting, thanks! I rebased Brent's old patches last year
for IIRC 2.5, but couldn't figure out how to inject some headers for
TCP mode. Your C is better than mine already.
Patches compiled fine against 3.0.0. Minor nits:
- examples/upstream-proxy-squid.conf needs the ^M line endings removed.
- a few trailing whitespace and stray tabs in the diff should go
in upstream-proxy.cfg include/haproxy/server-t.h src/connection.c
I couldn't quite understand how to use upstream-proxy.cfg example:
server https_Via_Proxy1 www.test1.com:4433 upstream-proxy-tunnel
127.0.0.1:3128 upstream-proxy-header-host "www.test1.com:4433" sni
str(www.test1.com) init-addr 127.0.0.1
but what is the purpose of each of the fields here?
server https_Via_Proxy1
- name as usual
www.test1.com:4433
- is this the url we are requesting to proxy?
- not sure why its needed here
upstream-proxy-tunnel 127.0.0.1:3128
- ok, this is the upstream proxy we are connecting to
upstream-proxy-header-host "www.test1.com:4433"
- not sure why its needed here
sni str(www.test1.com)
- I assume I can add this from a fetch
- i.e. dynamic for each connection?
init-addr 127.0.0.1
- I assume this is only needed for test
We have the requested url 3x here, and I'm not clear why thats required.
Aren't they always the same?
Is it possible to have that URL set from say SNI sniffer fetch, similar
to
https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension
?
My scenario:
I have a very similar setup, (done outside haproxy), where I SNI sniff the
header, compare it to a dynamic allow list, and then forward traffic through
firewall with CONNECT. To track usage, a custom header is pre-pended on connect.
We're not decrypting the TLS session to preserve privacy of message. Just not
destination.
Here's your setup, with a slight amendment to match what I'm doing:
> Just for my clarification is the following setup now possible with HAProxy
> with all the new shiny features :-)
$ curl https://httpbun.com/
...
client => frontend
sniff SNI request, check in ACL: are you allowed to go here?
big brother is watching.
|
\-> backend server dest1 IP:port
|
\-> call "CONNECT httpbun.com:443 on upstream proxy
|
send additional headers, like
host: httpbun.com:443
authentication: bearer abc123
|
upstream replies HTTP/1.1 200 OK
|
now we switch to tunneling, and fwd the original TLS
traffic
\-> TCP FLOW to destination IP
In my case I would have to vary the httpbun.com in both CONNECT and HOST:
headers, per each allowed domain.
In practice I could create lots of backends per each SNI header, if its
not possible to use the inspected SNI name.
A+
Dave
———
O for a muse of fire, that would ascend the brightest heaven of invention!
