Hi,
I'm having trouble using SNI with protocol=proxy. Stunnel seems to ignore protocol option defined in the 'children', for example now protocol will be ignored:
[https_default] accept = 443 connect = 10443 cert = a.crt key = a.key
[https_one] sni = https_default:one.org protocol = proxy connect = 10444 cert = one.crt key = one.key
On the other hand when defined on the 'default' resource, the connect option seems to be ignored:
[https_default] accept = 443 protocol = proxy connect = 10443 cert = a.crt key = a.key
[https_one] sni = https_default:one.org connect = 10444 ;; nope! still 10443 cert = one.crt key = one.key
Any suggestions?
Cheers, Marek
What does server log says? Is it accepting connection at https_one? (I had a similar problem, server worked as expected (at least when connecting from openssl s_client), but client did not appear to support sni).
Hi,
I'm having trouble using SNI with protocol=proxy. Stunnel seems to ignore protocol option defined in the 'children', for example now protocol will be ignored:
...
On the other hand when defined on the 'default' resource, the connect option seems to be ignored:
[https_default] accept = 443 protocol = proxy connect = 10443 cert = a.crt key = a.key
[https_one] sni = https_default:one.org connect = 10444 ;; nope! still 10443 cert = one.crt key = one.key
yyy wrote:
What does server log says? Is it accepting connection at https_one? (I had a similar problem, server worked as expected (at least when connecting from openssl s_client), but client did not appear to support sni).
Great reply. Some debug logs might indeed be useful.
Also "proxy" protocol is implemented before SSL protocol negotiation. The option should be supplied in the master (accepting) service.
Mike
On Tue, Mar 27, 2012 at 21:35, Michal Trojnara [email protected] wrote:
yyy wrote:
What does server log says? Is it accepting connection at https_one? (I had a similar problem, server worked as expected (at least when connecting from openssl s_client), but client did not appear to support sni).
Great reply. Some debug logs might indeed be useful.
Right. I assumed this is a known issue.
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 :)
Extract from my config:
[https_default] accept = 443 protocol = proxy connect = 10443 TIMEOUTclose = 0 session = 86400 cert = xxx.crt key = xxx.key
[https_yyy] sni = https_default:yyy.xxx.org connect = 10442 TIMEOUTclose = 0 session = 86400 cert = yyy.crt key = yyy.key
Haproxy listens on 10443, nobody listens on 10442.
Connecting to yyy.xxx.org, I would expect it to be closed/refused/dropped as nobody is listening on 10442, but instead:
2012.03.29 15:04:24 LOG5[22022:3076066080]: stunnel 4.52 on i686-pc-linux-gnu platform 2012.03.29 15:04:24 LOG5[22022:3076066080]: Compiled/running with OpenSSL 1.0.1 14 Mar 2012 [...] 2012.03.29 15:00:54 LOG7[21966:3076729632]: Service https_default accepted FD=17 from aaa:56413 2012.03.29 15:00:54 LOG7[21966:3076373360]: Service https_default started 2012.03.29 15:00:54 LOG5[21966:3076373360]: Service https_default accepted connection from aaa:56413 2012.03.29 15:00:54 LOG6[21966:3076373360]: connect_blocking: connecting 127.0.0.1:10443 2012.03.29 15:00:54 LOG7[21966:3076373360]: connect_blocking: s_poll_wait 127.0.0.1:10443: waiting 10 seconds 2012.03.29 15:00:54 LOG5[21966:3076373360]: connect_blocking: connected 127.0.0.1:10443 2012.03.29 15:00:54 LOG5[21966:3076373360]: Service https_default connected remote server from 127.0.0.1:53832 2012.03.29 15:00:54 LOG7[21966:3076373360]: Remote FD=18 initialized 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
So, 'connect' option in the slave service seems to be ignored, and stunnel happily connects to 10443.
Also, slave / SNI seems to be working otherwise as the browser doesn't complain about bad certificate for yyy.xxx.org.
Marek
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.
I've added this to my TODO list: http://www.stunnel.org/?page=sdf_todo
Mike
On Thu, Mar 29, 2012 at 17:16, Michal Trojnara [email protected] 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
Marek Majkowski wrote:
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.
I don't think stunnel could ever compete with haproxy, as it's a transparent (protocol agnostic) proxy, while haproxy is a dedicated http proxy.
On the other hand for some basic scenarios it might be better to use stunnel instead of haproxy even for http. I don't mind it.
In fact I implemented server-mode SNI mostly for "connect" option. 8-)
Greetings from Warsaw, Mike
-
Marek Majkowski -
Michal Trojnara -
yyy