Hi Graeme,
On Fri, 15 Oct 2004, Graeme Stewart wrote:
My apologies, I wasn't exactly sure what information would be helpful to resolve this issue.
I have a straight-forward approach to the amount of information needed when trying to solve a problem; just give me all you got and I'll sift through it to see what is useful and what not ;).
If I sounded a bit harsh it was because I woke up at 4 am while I could sleep until at least 7 am ;).
- stunnel has logging? - Told you I hadn't used it much.
That logging probably holds the solution to your problem. Because it probably holds the problem ;). I don't know what OS you're using; if it's debian linux you'll find the logging in /var/log/daemon.log, otherwise most likely in /var/log/messages. Can you check that logging to see what it says regarding stunnel?
If the logging is not present, uncomment these settings and check the stunnel.log.
#debug = 7 #output = stunnel.log
It could be the tcpwrapper is complaining. Wouldn't surprise me.
[https] accept=localhost:8080 connect=targetsite.com:443 TIMEOUTclose=0 transparent=yes
- shouldn't the link be transparent to the application utilizing it?
Nah, because it can't be. You can make it transparent to the receiving application, if I understand the feature correctly. I've never used it; all my servers are FreeBSD hence it wouldn't work on that side.
Consider this setup to secure an otherwise unsecured imap connection between a client that can't do ssl and a server that can't do ssl:
pine -imap-> localhost-stunnel --imap-over-ssl-> remotehost-stunnel --plain imap->imap-server
the imap-server now considers the connection to originate from the remotehost-stunnel. The transparent-yes feature should make it possible to let the imap-server think it is in fact talking to my localhost-stunnel.
So it has to do with the 'serverside-stunnel', not with the client-side stunnel.
Jan