Re: STUNNEL error response to encapsulated program
- From: Rich Jordan <jordan@xxxxxxxxxxx>
- Date: Mon, 12 Jan 2009 09:41:18 -0800 (PST)
On Jan 9, 5:46 pm, "Richard Maher" <maher...@xxxxxxxxxxxxxxxxxx>
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...@xxxxxxxxxxx> wrote in message
news:a3c3d885-561f-47c8-905f-0b033d6d3215@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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
.
- References:
- STUNNEL error response to encapsulated program
- From: Rich Jordan
- Re: STUNNEL error response to encapsulated program
- From: Richard Maher
- STUNNEL error response to encapsulated program
- Prev by Date: Re: 2009 VMS Bootcamp notice
- Next by Date: Re: 2009 VMS Bootcamp notice
- Previous by thread: Re: STUNNEL error response to encapsulated program
- Next by thread: Re: rx2600 ATI Radeon 7500 initialization
- Index(es):
Relevant Pages
|