Hallo Dave.
On 2024-06-07 (Fr.) 16:12, Dave Cottlehuber wrote:
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:
Great, thanks for testing :-)
- examples/upstream-proxy-squid.conf needs the ^M line endings removed.
That's strange as I have created the file on Linux, anyway I have now saved it
again with Linux line endings.
- a few trailing whitespace and stray tabs in the diff should go
in upstream-proxy.cfg include/haproxy/server-t.h src/connection.c
Well, I will fix this after the patch have the full features :-)
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
Yep.
www.test1.com:4433
- is this the url we are requesting to proxy?
- not sure why its needed here
This is the destination host and will be used for the "CONNECT " call.
upstream-proxy-tunnel 127.0.0.1:3128
- ok, this is the upstream proxy we are connecting to
Yep. The plan is that this address could be a name which is resolvable.
upstream-proxy-header-host "www.test1.com:4433"
- not sure why its needed here
That's documented in the RFC https://www.rfc-editor.org/rfc/rfc7231#page-30
```
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
```
I just wanted to be as much compliant as possible.
This line will be obsolete as soon as the "tcp-request .... header ..." feature
is implemented.
sni str(www.test1.com)
- I assume I can add this from a fetch
- i.e. dynamic for each connection?
That's useless for now, only when the destination server have another name as
the destination host on sni level.
init-addr 127.0.0.1
- I assume this is only needed for test
Yep.
We have the requested url 3x here, and I'm not clear why thats required.
Aren't they always the same?
It's mainly for testing.
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
?
Well as written above I would like to have a "tcp-request ... header ..."
feature which is able to handle the HAProxy expressions.
That's on the way :-)
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.
That's exactly what I also like to have :-)
I'm on the way to send updated patches which have now implemented the upstream
header feature but with hard coded variables names, for now.
upstream-proxy-header*
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!
LG
Alex
