[stunnel-users] SNI with protocol=proxy ?

[Marek Majkowski]

On Thu, Mar 29, 2012 at 17:16, Michal Trojnara <Michal.Trojnara at 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