Hello,
We use stunnel to secure a proprietary tcp/ip protocol over the internet.
More specifially we have
- 1 balancer
- 2 stunnel boxes
- 1 app server
The load balancer 'pings' stunnel boxes regularly to know if one is down.
Recently, we have added support for the proxy protocol in our app and
turned it on in our stunnel config. It works great except for one small new
behavior: upon receiving a load balancer ping, stunnel performs a
connection on our app (and sends the proxy header).
I ran a tcpdump for a telnet on the stunnel port (8000). With proxy
protocol disabled, stunnel does nothing while it waits for the certificate.
The connection ended at my request.
17:33:08.537385 IP 127.0.0.1.6015 > 127.0.0.1.8000: S
356922015:356922015(0) win 32792 <mss 16396,sackOK,timestamp 1085620573
0,nop,wscale 7>
17:33:08.537386 IP 127.0.0.1.8000 > 127.0.0.1.6015: S
1525966521:1525966521(0) ack 356922016 win 32768 <mss
16396,sackOK,timestamp 1085620573 1085620573,nop,wscale 7>
17:33:08.537393 IP 127.0.0.1.6015 > 127.0.0.1.8000: . ack 1 win 257
<nop,nop,timestamp 1085620573 1085620573>
17:33:19.750431 IP 127.0.0.1.6015 > 127.0.0.1.8000: F 1:1(0) ack 1 win 257
<nop,nop,timestamp 1085631785 1085620573>
17:33:19.751065 IP 127.0.0.1.8000 > 127.0.0.1.6015: . ack 2 win 256
<nop,nop,timestamp 1085631786 1085631785>
17:33:19.751794 IP 127.0.0.1.8000 > 127.0.0.1.6015: R 1:1(0) ack 2 win 256
<nop,nop,timestamp 1085631787 1085631785>
With proxy protocol enabled, stunnel establishes a connection to my app and
sends the proxy protocol before even receiving the certificate.
17:34:35.370462 IP 127.0.0.1.6026 > 127.0.0.1.8000: S
2949098861:2949098861(0) win 32792 <mss 16396,sackOK,timestamp 1085707402
0,nop,wscale 7>
17:34:35.370475 IP 127.0.0.1.8000 > 127.0.0.1.6026: S
1044893129:1044893129(0) ack 2949098862 win 32768 <mss
16396,sackOK,timestamp 1085707402 1085707402,nop,wscale 7>
17:34:35.370481 IP 127.0.0.1.6026 > 127.0.0.1.8000: . ack 1 win 257
<nop,nop,timestamp 1085707402 1085707402>
17:34:35.371035 IP 127.0.0.1.37654 > 127.0.0.1.9000: S
801705083:801705083(0) win 32792 <mss 16396,sackOK,timestamp 1085707402
0,nop,wscale 7>
17:34:35.371046 IP 127.0.0.1.9000 > 127.0.0.1.37654: S
4068822820:4068822820(0) ack 801705084 win 32768 <mss
16396,sackOK,timestamp 1085707402 1085707402,nop,wscale 7>
17:34:35.371052 IP 127.0.0.1.37654 > 127.0.0.1.9000: . ack 1 win 257
<nop,nop,timestamp 1085707402 1085707402>
17:34:35.371583 IP 127.0.0.1.37654 > 127.0.0.1.9000: P 1:44(43) ack 1 win
257 <nop,nop,timestamp 1085707403 1085707402>
17:34:35.371595 IP 127.0.0.1.9000 > 127.0.0.1.37654: . ack 44 win 256
<nop,nop,timestamp 1085707403 1085707403>
17:34:50.484991 IP 127.0.0.1.9000 > 127.0.0.1.37654: F 1:1(0) ack 44 win
256 <nop,nop,timestamp 1085722515 1085707403>
17:34:50.485892 IP 127.0.0.1.37654 > 127.0.0.1.9000: . ack 2 win 257
<nop,nop,timestamp 1085722516 1085722515>
17:35:08.824661 IP 127.0.0.1.6026 > 127.0.0.1.8000: F 1:1(0) ack 1 win 257
<nop,nop,timestamp 1085740854 1085707402>
17:35:08.824906 IP 127.0.0.1.8000 > 127.0.0.1.6026: . ack 2 win 256
<nop,nop,timestamp 1085740854 1085740854>
17:35:08.824972 IP 127.0.0.1.37654 > 127.0.0.1.9000: R 44:44(0) ack 2 win
257 <nop,nop,timestamp 1085740854 1085722515>
17:35:08.825013 IP 127.0.0.1.8000 > 127.0.0.1.6026: R 1:1(0) ack 2 win 256
<nop,nop,timestamp 1085740855 1085740854>
Note I used 'tcpdump -i lo -nn port 8000 or port 9000' for both traces.
I see no good reason to connect to the application before the ssl session
is established.
Thank you for reading!
--
Philippe Anctil