[Info-vax] STUNNEL error response to encapsulated program

[Rich Jordan]

On Jan 9, 5:46 pm, "Richard Maher" <maher... at hotspamnotmail.com>
wrote:
> Hi Rich,
>
> > In one case we need to encrypt the transmissions, so I set up STUNNEL
> > on both boxes.
>
> Why was it that you couldn't use IPsec again? Version issues? Were you told
> the < 8.4 kit was not officially supported?
>
> Obviously, you don't want to have to hand craft SSL connections or you
> wouldn't be using STUNNEL in the first place but FYI the problem goes away
> when you code your own SSL in the client as in Tier3Socket.java but still
> front-end the server with STUNNEL.
>
> Anyway, I've seen you in the STUNNEL mailing list but not this question, did
> you have no luck there?
>
> BTW have you had any issues with intrusion detection and DoS attacks with
> STUNNEL?
>
> Cheers Richard Maher
>
> PS. Just remembered I have to mail you something.
>
> "Rich Jordan" <jor... at ccs4vms.com> wrote in message
>
> news:a3c3d885-561f-47c8-905f-0b033d6d3215 at s9g2000prm.googlegroups.com...
>
> > We have a custom client-server program that has been running over an
> > open network.  The client is a NETLIB based BASIC program on VMS, the
> > server is a dotnet wintel beastie.  Works fine when they talk directly
> > to eachother; specifically when either side 'writes' a data blob to
> > the other, failure gets reported to the program if the link is down,
> > the remote program aborts or isn't there, etc.
>
> > In one case we need to encrypt the transmissions, so I set up STUNNEL
> > on both boxes.  Certificates work, verification works, etc.  It works
> > fine when everything is up and running.  However there's an issue with
> > the error trapping on failed writes.
>
> > If the local STUNNEL is down, you get a SS$_REJECT or similar status.
> > Fine.
>
> > If the remote STUNNEL or server program goes down, the VMS program
> > happily writes out its data blob (to the local STUNNEL), gets SS
> > $_NORMAL status back from the call, and in the IOSB, and continues.
> > The only difference is on the READ; if the remote server is down but
> > remote STUNNEL up, the read tries and times out (if a timeout was set
> > which we do).  If the remote STUNNEL is down, then the read fails
> > immediately with an SS$_LINKDISCON.
>
> > The problem; the client can't tell the difference between the remote
> > server receiving the data blob but taking too long to respond and
> > exceeding the timeout, and the remote server not being there at all
> > (and therefore not receiving the data blob at the start of the
> > transaction).  Also, if the client DOES time out, and close the
> > connection and socket on the VMS side, the PC server doesn't know
> > about it (STUNNEL on the PC happily accepts the response string aimed
> > at the already closed connection) so the server doesn't know the
> > client didn't receive it.
>
> > We could make the two processes send manual 'ack's to the each other
> > on receipt of the data blob or response string but you get into a
> > 'race' where the last process to 'ACK' never really knows if that ACK
> > was received by the other end.
>
> > None of this is a problem with a direct connection.  STUNNEL actually
> > does provide a proxy mode, but that is apparently only available under
> > Linux, not VMS or wintel.
>
> > I'm hoping there's something available via STUNNEL that I'm missing
> > that can cause it to "report back" an error to the program/process
> > talking to it if the downstream connections are not complete or
> > present at all.
>
> > Any info or thoughts on improving the usage of STUNNEL would be
> > appreciated.

Richard
     no response on the stunnel list to the 64 bit question.  We
tested the PC end on 64 bit Vista but we don't currently have a 64 bit
server version to try.  I thought my chances of a response here were
better, though I don't know how many folks have used STUNNEL to front
custom programs as opposed to stack provided ones like SMTP/POP/IMAP.

     The powers that be have determined to run this initial project
using STUNNEL due to time and resource constraints.  It will be
entirely LAN based, with certificate based authentication/verification
at the STUNNEL level and shared secret protection at the server/client
level.  We do not expect to have to deal with DoS or other attacks
since the LAN itself is well secured, and any such would be easy to
backtrace to the offending PC.

     IPSec is not available at the production site, and can't be made
so (procedures and policy impact) until well after the deadline for
this project.  Its under consideration for a future update, as is
writing the client to directly use OpenSSL functions to talk to the
remote STunnel; I don't know if the PC side folks are reviewing their
options for doing the same.  For now we have to work with the existing
non-encrypted server/client software.

     Thanks for responding.

Rich