On Thu, Mar 29, 2012 at 17:16, Michal Trojnara Michal.Trojnara@mirt.net wrote:
Marek Majkowski wrote:
Also "proxy" protocol is implemented before SSL protocol negotiation. The option should be supplied in the master (accepting) service.
Good to know. Even better if that was documented somewhere :)
It would be better indeed, although hardly feasible in practice, to document all corner cases of interaction between stunnel options. Feel free to contribute documentation.
2012.03.29 15:00:54 LOG6[21966:3076373360]: Server-mode proxy protocol negotiations started 2012.03.29 15:00:54 LOG7[21966:3076373360]: -> PROXY TCP4 aaa bbb 56413 443 2012.03.29 15:00:54 LOG6[21966:3076373360]: Server-mode proxy protocol negotiations succeeded 2012.03.29 15:00:54 LOG5[21966:3076373360]: SNI: switched to section https_yyy
You're right. With current architecture of protocol negotiations, remote host has to be connected before SSL_accept(). As the result SNI is mostly ignored.
If I may add my two cents, it's absolutely fine to just assume that `connect` can't be used in slave services. By doing otherwise you risk that stunnel may become another haproxy.
But this should be coherent - 'connect' should not work on slaves always, not only on `protocol=proxy`.
For a solution I'm using now - I'm just doing dispatching based on hostname on haproxy layer and it works like charm, that's it.
(the only risk is that an attacker may send different hostname on http layer and different on TLS SNI, but that's not critical)
Marek