[Info-vax] STUNNEL error response to encapsulated program

[Richard Maher]

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" <jordan 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.
>