Hi there.
Perhaps this is a foolishness, but it happens to me, triggering a great headache.
I'm Debian (Wheezy) user, using stunnel 4.53-1.1.
I copied the stunnel configuration from another machine for a simple LAN SMTP relay. When I tried to reload the script, I got this:
# /etc/init.d/stunnel4 start
Reloading configuration SSL tunnels: /etc/init.d/stunnel4: 34: test: /var/lib/stunnel4/: unexpected operator
A few hours laters, I discovered the problem was in config file, in the chroot parameter:
chroot = /var/lib/stunnel4
Specifically, with a hide space at the end of the line:
chroot = /var/lib/stunnel4[ ]
In the init script, in the function get_pids(), this mistake caused that this checkout fails:
--- if test -f $CHROOT/$PIDFILE; then cat $CHROOT/$PIDFILE fi ---
'cat /var/lib/stunnel4///stunnel.pid' is not the same as 'cat /var/lib/stunnel4/[ ]//stunnel.pid'
Perhaps a suggestion, a little change here:
CHROOT=`grep "^chroot" $file|sed "s;.*= *;;"`
Adding a space filter:
CHROOT=`grep "^chroot" $file|sed "s;.*= *;;" | tr -d " "`
Regards.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
F. J. Blanco wrote:
Perhaps a suggestion, a little change here:
CHROOT=`grep "^chroot" $file|sed "s;.*= *;;"`
Adding a space filter:
CHROOT=`grep "^chroot" $file|sed "s;.*= *;;" | tr -d " "`
In fact the parameters can contain "=" or or spaces. Only trailing spaces are removed.
Consequently, the line should be more like:
CHROOT=$(grep -i '^[[:space:]]*chroot[[:space:]]*=' $file | sed 's;[^=]*=[[:space:]]*(.*[[:graph:]]).*;\1;')
Mike
Dear All,
After a recent upgrade I'm currently experiencing intermittent problems with securing bidirectional comms traffic for a moitoring program with stunnel.
The system is: 70+ Client machines running BBWin on Windows (mostly 7) -> stunnel 5.01 .....internet......stunnel 5.02 -> Xymon running on 64-bit Linux Mint 17 (Virtual machine inside 2012 R2 Essentials server)
Prior to the recent upgrade, the server was an approx 3 year old 32-bit Ubuntu server, running stunnel 4.56. Comms then worked (mostly) fine for our client machines.
Since the upgrade, client requests for information from the server have been largely failing. Running the comms with direct unsecured socket connections work fine.
I've spent a bit of time over the last couple of days looking at the source for both Stunnel and BBWin and it looks to me as if there is a disconnect in understanding between BBWin and Stunnel as to how read and write connections work.
The BBWin Client makes the connection, then issues (in essence) the following sequence: send(connection, msg) shutdown(connection, SHUT_WR) do recv(connection....) until it returns zero or SOCKET_ERROR shutdown(connection, SHUT_RD) shutdown(connection, SHUT_BOTH) closesocket(connection) i.e. the client shuts down the transmission side as soon as it's done, then shuts down the receive side only once it's finished receiving any returned data.
I atttach Stunnel logs for both client and server for both failed and successful transfers. I've added a little more debugging output to the server Stunnel instance to display the data being read and written to both the socket and SSL side of the comms. This shows that the only difference between the two is that in the successful transfer the server receives and passes on data from the socket to SSL before starting the shutdown. So that looks fine - when it works. But when it doesn't, it looks just as if the return path is shut down before the server app has had time to retrieve the data to be returned
Looking at the stunnel code though, I'm confused - and my suspicion is that stunnel (on the client machine) is closing the SSL connection prematurely.. It looks as if it issues the SSL_shutdown command (client.c line 855) if: it's not already sent the shutdown the read fd on the socket is closed there's nothing left in the outboud queue (sock_ptr is 0) and SSL wants a retry (? I don't yet understand write_wants_write usage). That's all very well for closing the outbound side, but what about the inbound? Surely it should keep the SSL open until either it's notified by the other side that everything is closed down there, or BOTH read and write on the socket side have been shutdown. A further point of confusion is that the stunnel code handles read and write fds for each of SSL and socket independently, but for most cases they are both set to the same value. Is there some confusion about handling s_poll_hup()? I freely admit I don't understand fully how this works, as I've only had a day's experience of this comms stuff, and it looks pretty well thought out, but there's logic here for handling the inbound and outbound sides independently, so SSL should remain open while any one of those two channel remains active?
The bottom line is that the comms: a) works reliably when not routed through stunnel b) works reliably to transmit from client to server b) now works (in reception) less than 10% of the time when using stunnel - but does work occasionally It worked fairly reliably with 5.01 on the clients and 4.56 on a slowish server, and now doesn't on 5.02 on a highish spec server, with client software/hardware unchanged. My suspicion is that improving the spec on the server has exposed a race condition on the client installation.
Any thoughts?
Graham Nayler
Hi Michal (and if there is anyone else remotely interested :-) )
After a lot more digging, I've now confirmed it to be a race condition in the handling of the read socket in stunnel, although not the one I originally suspected. The problem occurs when the remote program feeds some data to stunnel, then immediately closes the socket, i.e.:
write(sock, buff, length); shutdown(sock, SHUT_WR); close(sock);
The write returns a valid count and this looks legal code to me - the client program should not have to wait around to confirm data has been received at the other end before start the shutdown, OK?
Looking at the way stunnel checks for incoming data, it polls the file descriptors and then takes action on the return status - particularly POLLIN and/or POLLHUP. When the transfer succeeded, the poll status was just POLLIN, and Stunnel then reads the socket correctly. In the failure scenario though, the returned status was (POLLIN|POLLHUP). Stunnel processed the POLLHUP case first, and marked the socket as closed without checking for any data still within it. Switching the order to first unload any data from the socket, and ONLY THEN marking the socket as shut fixes the problem. The read on the fd with the HUP state marked does work, as confirmed by the return byte count, and the shutdown proceeds as normal after that has been processed.
I attach a log showing the desired and failure scenarios for both the original ordered code and the fixed version. I also attach a log of the diffs between the working code and the corresponding sources in Version 5.02. The extra debugging output I added to track down the problem is included, although is clearly not strictly necessary. The version of the utility s_poll_value() for the non USE_POLL case is just a best guess, as my configuration appears to use the polling mechanism rather than select.
I've only tried to fix this particular problem. I don't know whether there is a similar scenario possible for the SSL side of the transfer as well - my knowledge of SSL is even scantier than my knowledge of sockets. I can't think of a similar problem on the write side...but again my knowledge of comms is purely on a need-to-know basis!
Graham
-----Original Message----- From: Graham Nayler (work) Sent: Monday, September 15, 2014 3:04 PM To: [email protected] Subject: [stunnel-users] Premature socket closure - race condition bug?
Dear All,
After a recent upgrade I'm currently experiencing intermittent problems with securing bidirectional comms traffic for a moitoring program with stunnel.
The system is: 70+ Client machines running BBWin on Windows (mostly 7) -> stunnel 5.01 .....internet......stunnel 5.02 -> Xymon running on 64-bit Linux Mint 17 (Virtual machine inside 2012 R2 Essentials server)
Prior to the recent upgrade, the server was an approx 3 year old 32-bit Ubuntu server, running stunnel 4.56. Comms then worked (mostly) fine for our client machines.
Since the upgrade, client requests for information from the server have been largely failing. Running the comms with direct unsecured socket connections work fine.
I've spent a bit of time over the last couple of days looking at the source for both Stunnel and BBWin and it looks to me as if there is a disconnect in understanding between BBWin and Stunnel as to how read and write connections work.
The BBWin Client makes the connection, then issues (in essence) the following sequence: send(connection, msg) shutdown(connection, SHUT_WR) do recv(connection....) until it returns zero or SOCKET_ERROR shutdown(connection, SHUT_RD) shutdown(connection, SHUT_BOTH) closesocket(connection) i.e. the client shuts down the transmission side as soon as it's done, then shuts down the receive side only once it's finished receiving any returned data.
I atttach Stunnel logs for both client and server for both failed and successful transfers. I've added a little more debugging output to the server Stunnel instance to display the data being read and written to both the socket and SSL side of the comms. This shows that the only difference between the two is that in the successful transfer the server receives and passes on data from the socket to SSL before starting the shutdown. So that looks fine - when it works. But when it doesn't, it looks just as if the return path is shut down before the server app has had time to retrieve the data to be returned
Looking at the stunnel code though, I'm confused - and my suspicion is that stunnel (on the client machine) is closing the SSL connection prematurely.. It looks as if it issues the SSL_shutdown command (client.c line 855) if: it's not already sent the shutdown the read fd on the socket is closed there's nothing left in the outboud queue (sock_ptr is 0) and SSL wants a retry (? I don't yet understand write_wants_write usage). That's all very well for closing the outbound side, but what about the inbound? Surely it should keep the SSL open until either it's notified by the other side that everything is closed down there, or BOTH read and write on the socket side have been shutdown. A further point of confusion is that the stunnel code handles read and write fds for each of SSL and socket independently, but for most cases they are both set to the same value. Is there some confusion about handling s_poll_hup()? I freely admit I don't understand fully how this works, as I've only had a day's experience of this comms stuff, and it looks pretty well thought out, but there's logic here for handling the inbound and outbound sides independently, so SSL should remain open while any one of those two channel remains active?
The bottom line is that the comms: a) works reliably when not routed through stunnel b) works reliably to transmit from client to server b) now works (in reception) less than 10% of the time when using stunnel - but does work occasionally It worked fairly reliably with 5.01 on the clients and 4.56 on a slowish server, and now doesn't on 5.02 on a highish spec server, with client software/hardware unchanged. My suspicion is that improving the spec on the server has exposed a race condition on the client installation.
Any thoughts?
Graham Nayler
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Graham Nayler wrote:
In the failure scenario though, the returned status was (POLLIN|POLLHUP).
Great work. I indeed forgot that the POLLHUP condition may be set while some buffered data is still available.
Could you try: https://www.stunnel.org/downloads/beta/stunnel-5.05b1.tar.gz ?
Mike
Compiled and installed on the Linux Mint server and looking fine so far using my test example. If nothing shows up in the next few hours of normal running it should be fine.
It's of lower priority, but I'd like to update the client machines as well when the release goes official. This may be better in a separate thread, or already exist in an FAQ I've not found, but as I have about 50 (currently, eventually >80) sites to update (mostly Windows 7, some XPSP3), is there a way for the Windows install to be run unattended? Failing that, is there a list, or way to generate a list, of updated binaries + reg/config entries so I can make myself an unattended install/upgrade? Most sites are currently on 5.01, but some are still on 4.56.
-----Original Message----- From: Michal Trojnara Sent: Monday, September 22, 2014 11:00 AM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Graham Nayler wrote:
In the failure scenario though, the returned status was (POLLIN|POLLHUP).
Great work. I indeed forgot that the POLLHUP condition may be set while some buffered data is still available.
Could you try: https://www.stunnel.org/downloads/beta/stunnel-5.05b1.tar.gz ?
Mike
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
I understand the official NSIS installer source code is available (tools/stunnel.nsi). So, You can crate your customized installation with configuration files (stunnel.conf, certificates, etc). For NSIS, the silent switch is /S. I also have a custom Inno Setup script. I find Inno Setup easier to work with, although NSIS generates smaller installers, if you're interested.
-----Original Message----- From: "Graham Nayler (work)" [email protected] Sender: "stunnel-users" [email protected] Date: Mon, 22 Sep 2014 12:13:21 To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
Compiled and installed on the Linux Mint server and looking fine so far using my test example. If nothing shows up in the next few hours of normal running it should be fine.
It's of lower priority, but I'd like to update the client machines as well when the release goes official. This may be better in a separate thread, or already exist in an FAQ I've not found, but as I have about 50 (currently, eventually >80) sites to update (mostly Windows 7, some XPSP3), is there a way for the Windows install to be run unattended? Failing that, is there a list, or way to generate a list, of updated binaries + reg/config entries so I can make myself an unattended install/upgrade? Most sites are currently on 5.01, but some are still on 4.56.
-----Original Message----- From: Michal Trojnara Sent: Monday, September 22, 2014 11:00 AM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Graham Nayler wrote:
In the failure scenario though, the returned status was (POLLIN|POLLHUP).
Great work. I indeed forgot that the POLLHUP condition may be set while some buffered data is still available.
Could you try: https://www.stunnel.org/downloads/beta/stunnel-5.05b1.tar.gz ?
Mike
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Thanks, just what I need.
As for installers, I'm a bit of a luddite where that's concerned....so just have a roll-my-own system based on a couple of .bat files and Python scripts. Allows me to checksum, set up and kick off generic subsidiary programs, copy alternate configuration-specific programs according to generic pattern, etc. all with the minimum of maintenance. Way less pretty but much more flexible and less onerous than when I used to use an old Microsoft installer. Main omission is lack of an uninstall, but as this only goes onto machines over which I have direct control, and I do most of the updates myself, it's not something I need to automate. Probably plenty of installers out there that I could get to do what I want, but if it ain't broke I've really got too much else to keep me busy to be bothered to fix it.
Graham
-----Original Message----- From: [email protected] Sent: Monday, September 22, 2014 12:28 PM To: Graham Nayler (work) ; stunnel-users ; [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
I understand the official NSIS installer source code is available (tools/stunnel.nsi). So, You can crate your customized installation with configuration files (stunnel.conf, certificates, etc). For NSIS, the silent switch is /S. I also have a custom Inno Setup script. I find Inno Setup easier to work with, although NSIS generates smaller installers, if you're interested.
Since submitting my original patch, I've realised there is a possible scenario that both my solution, and I think yours as well, still fails on: we're assuming that once the readsocket call has returned, there's nothing left in the socket buffer. Is this not dependent on the size of the data submitted by the remote program, the capacity of the socket buffer itself, and the space remaining in c->sock_buf after c->sock_ptr? I.e. there could still be data in the socket if the buffered data were longer than that returned by readsocket? Should stunnel not repoll/check the socket to ensure that POLLIN is not set before taking any action on POLLUP? Maybe s_poll_hup() should only be allowed to return POLLIN if POLLHUP is not set?
Graham
-----Original Message----- From: Graham Nayler (work) Sent: Monday, September 22, 2014 12:13 PM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
Compiled and installed on the Linux Mint server and looking fine so far using my test example. If nothing shows up in the next few hours of normal running it should be fine.
It's of lower priority, but I'd like to update the client machines as well when the release goes official. This may be better in a separate thread, or already exist in an FAQ I've not found, but as I have about 50 (currently, eventually >80) sites to update (mostly Windows 7, some XPSP3), is there a way for the Windows install to be run unattended? Failing that, is there a list, or way to generate a list, of updated binaries + reg/config entries so I can make myself an unattended install/upgrade? Most sites are currently on 5.01, but some are still on 4.56.
-----Original Message----- From: Michal Trojnara Sent: Monday, September 22, 2014 11:00 AM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Graham Nayler wrote:
In the failure scenario though, the returned status was (POLLIN|POLLHUP).
Great work. I indeed forgot that the POLLHUP condition may be set while some buffered data is still available.
Could you try: https://www.stunnel.org/downloads/beta/stunnel-5.05b1.tar.gz ?
Mike
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Ah..another possible problem with your solution...or alternatively with my understanding of the socket interface. What happens if the remote program submits the data, stunnel unloads the socket, and only then does the remote program close the socket? Will the s_poll_wait be triggered on the HUP alone (I guess yes)? If not, then stunnel will hang until something submits more data. But if triggered only on the HUP, the lines checking for internal failures will see an exit with no read or write data waiting, and take the longjmp() after "s_poll_wait returned %d, but no descriptor is ready". In my suggested version it did an additional check for sock_rd_hup to cope with just this scenario.
-----Original Message----- From: Graham Nayler (work) Sent: Monday, September 22, 2014 12:54 PM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
Since submitting my original patch, I've realised there is a possible scenario that both my solution, and I think yours as well, still fails on: we're assuming that once the readsocket call has returned, there's nothing left in the socket buffer. Is this not dependent on the size of the data submitted by the remote program, the capacity of the socket buffer itself, and the space remaining in c->sock_buf after c->sock_ptr? I.e. there could still be data in the socket if the buffered data were longer than that returned by readsocket? Should stunnel not repoll/check the socket to ensure that POLLIN is not set before taking any action on POLLUP? Maybe s_poll_hup() should only be allowed to return POLLIN if POLLHUP is not set?
Graham
-----Original Message----- From: Graham Nayler (work) Sent: Monday, September 22, 2014 12:13 PM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
Compiled and installed on the Linux Mint server and looking fine so far using my test example. If nothing shows up in the next few hours of normal running it should be fine.
It's of lower priority, but I'd like to update the client machines as well when the release goes official. This may be better in a separate thread, or already exist in an FAQ I've not found, but as I have about 50 (currently, eventually >80) sites to update (mostly Windows 7, some XPSP3), is there a way for the Windows install to be run unattended? Failing that, is there a list, or way to generate a list, of updated binaries + reg/config entries so I can make myself an unattended install/upgrade? Most sites are currently on 5.01, but some are still on 4.56.
-----Original Message----- From: Michal Trojnara Sent: Monday, September 22, 2014 11:00 AM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Graham Nayler wrote:
In the failure scenario though, the returned status was (POLLIN|POLLHUP).
Great work. I indeed forgot that the POLLHUP condition may be set while some buffered data is still available.
Could you try: https://www.stunnel.org/downloads/beta/stunnel-5.05b1.tar.gz ?
Mike
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
So it's been running for several days now and operationally it's fine for me.
I've looked a bit harder at the possible problems I outlined below, and this implementation does not show them....but I think sort of by accident.
Addressing the second problem first, what I was worrying about looks to be a result of my lack of understanding about how the poll works. If the HUP occurs after Stunnel has unloaded the socket, it looks like the poll does still complete with (POLLIN|POLLHUP), but the read length is 0. The zero length read is then taken as a signal to shut the socket down. (In my case, this is also actually the way the programs on either side of the Stunnel link detect socket shutdowns). So that's fine.
I'm not happy about the way the read-hup is handled in large transfers though. The attached logs (including printout of the relevant 'revents' fields after each poll completion, and byte transfer counts) show a number of scenarios: 1) Large transfer ( > SSL payload size), HUP received after unloading socket 2) Large transfer ( > SSL payload size), HUP received before unloading socket 3) Small transfer, HUP received along with socket read 4) Small transfer, HUP received after socket read and after write to SSL 5) Small transfer, HUP received after socket read and before write to SSL
Having read the code more closely I see that you're using a separate function s_poll_rdhup() for the read hangup, masking the poll return value with POLLRDHUP. Tracing through the return values on my system, this turns out to never return true, as the completion signal is only ever POLLHUP, never POLLRDHUP. And it's only because of this that Scenario 2) works; if that had detected a POLLRDHUP condition, it would have stopped reading the socket after its first read loop before reading all the data, and sent an incomplete payload. As the socket file descriptors are the same for both read and write, it also takes action on the HUP for the WR socket and tries to hang that up each time around the loop (this applies to both scenario 2 and 3) - although I see that actually all it's doing is to clear a flag that allows the loop to terminate, so the only real effect is to cause the debug/log message to appear more often than necessary.
So for me it's working, but I have my doubts as to how general that solution is.....but again it may be my lack of understanding about the circumstances of seeing POLLRDHUP.
Graham
----- Original Message ----- From: "Graham Nayler (work)" [email protected] To: [email protected] Sent: Monday, September 22, 2014 1:19 PM Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
Ah..another possible problem with your solution...or alternatively with my understanding of the socket interface. What happens if the remote program submits the data, stunnel unloads the socket, and only then does the remote program close the socket? Will the s_poll_wait be triggered on the HUP alone (I guess yes)? If not, then stunnel will hang until something submits more data. But if triggered only on the HUP, the lines checking for internal failures will see an exit with no read or write data waiting, and take the longjmp() after "s_poll_wait returned %d, but no descriptor is ready". In my suggested version it did an additional check for sock_rd_hup to cope with just this scenario.
-----Original Message----- From: Graham Nayler (work) Sent: Monday, September 22, 2014 12:54 PM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
Since submitting my original patch, I've realised there is a possible scenario that both my solution, and I think yours as well, still fails on: we're assuming that once the readsocket call has returned, there's nothing left in the socket buffer. Is this not dependent on the size of the data submitted by the remote program, the capacity of the socket buffer itself, and the space remaining in c->sock_buf after c->sock_ptr? I.e. there could still be data in the socket if the buffered data were longer than that returned by readsocket? Should stunnel not repoll/check the socket to ensure that POLLIN is not set before taking any action on POLLUP? Maybe s_poll_hup() should only be allowed to return POLLIN if POLLHUP is not set?
Graham
-----Original Message----- From: Graham Nayler (work) Sent: Monday, September 22, 2014 12:13 PM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
Compiled and installed on the Linux Mint server and looking fine so far using my test example. If nothing shows up in the next few hours of normal running it should be fine.
It's of lower priority, but I'd like to update the client machines as well when the release goes official. This may be better in a separate thread, or already exist in an FAQ I've not found, but as I have about 50 (currently, eventually >80) sites to update (mostly Windows 7, some XPSP3), is there a way for the Windows install to be run unattended? Failing that, is there a list, or way to generate a list, of updated binaries + reg/config entries so I can make myself an unattended install/upgrade? Most sites are currently on 5.01, but some are still on 4.56.
-----Original Message----- From: Michal Trojnara Sent: Monday, September 22, 2014 11:00 AM To: [email protected] Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Graham Nayler wrote:
In the failure scenario though, the returned status was (POLLIN|POLLHUP).
Great work. I indeed forgot that the POLLHUP condition may be set while some buffered data is still available.
Could you try: https://www.stunnel.org/downloads/beta/stunnel-5.05b1.tar.gz ?
Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlQf80IACgkQ/NU+nXTHMtG3pACfeYvvrabt8TAM7CsOP1fm9nod /0UAoPpF7W5FkGjzb1u3E+6ZRHtoyi2L =p6UY -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-
F. J. Blanco -
Graham Nayler (work) -
josealf＠rocketmail.com -
Michal Trojnara