curl -vv https://eggsbenedition.stuntedantelope.live will show the relevant transactions.
eggsbeneditation.stundedantelope.live IS effectively the ServerNameIdentification that haproxy will use to match, present the relevant certificate and then fetch if it passes muster, there is a one-to-one mapping of URL to backend server here so the sni extensions to TLS are not a concern of the phone, just the proxy. No matching URL no connection proxied, your provisioning server will never see a thing. A potential attacker would have to already have ‘leaked’ info to even know to attack eggsbenedictation. . ., but that’s another subject that a good conntracker in your firewall should make short shrift of (think Fail2Ban)
Perhaps you could try it, it shouldn’t take you more than an hour or so, if you did, watching the haproxy log is in itself a good learning experience with its likely plethora of
'<NOSRV>' and ‘SSL handshake failure’ lines amidst the legitimate proxy forwards.
Peer review always appreciated.
I will try to clarify , the initial TLS handshake always starts in http/1.1 mode so will always include the ‘server_name’ in cleartext, this is what chooses the certificate and thus the backend but the strict-sni conditional will only return to the client a certificate If there is a matching frontend with matching ACL , without it, then indeed more info will be leaked. otherwise just a 503 error.
Haproxy is not a webserver but if using http mode, fully processes TLS negotiation. The client/haproxy traffic will be encrypted https but in this scenario the haproxy/server traffic is back to http, so now open to MITM exploits but of course this is now all LAN bound.
tcpdump -An port 443 or port 80|egrep "com|org|net|live|link|. . ."
will quickly reveal the raw server_names received,
/var/log/haproxy.log a more readable trace.