I'm hoping someone on this list will take the time to help me. I apologize for the newbie nature of this question.
I'm trying to create an SSL stunnel connection to an https URL then utilize netcat to send requests through that previously established link. I believe this should be possible.
My configuration file includes:
verify=0 client=yes
[https] accept=localhost:8080 connect=www.remotesite.com:443 TIMEOUTEclose=0 transparent=yes
Whenever I run:
# stunnel stunnel.config # nc -vv localhost 8080
I receive a connection refused error from netcat. Could someone point me in the right direction?
I did review the examples on stunnel.org but they all seem to reference an earlier version of stunnel.
Thanks,
Graeme
On Thu, 14 Oct 2004, Graeme Stewart wrote:
I receive a connection refused error from netcat. Could someone point me in the right direction?
Too early awake me thinks: -can you telnet localhost 8080 and what does that say? -what does the logging on your local stunnel say? -what does the logging on the remote site say? -what is your total stunnel config? -why are you using transparent?
to get more information. Then again, maybe I'm missing the obvious, I do occasionally ;)
Jan
On Fri, 15 Oct 2004 04:29:53 +0200 (CEST), Jan Meijer jan.meijer@surfnet.nl wrote:
On Thu, 14 Oct 2004, Graeme Stewart wrote:
I receive a connection refused error from netcat. Could someone point me in the right direction?
Too early awake me thinks: -can you telnet localhost 8080 and what does that say? -what does the logging on your local stunnel say? -what does the logging on the remote site say? -what is your total stunnel config? -why are you using transparent?
Jan,
My apologies, I wasn't exactly sure what information would be helpful to resolve this issue.
It may be my limited knowledge is attributing the issue to stunnel, when infact the problem is more of an SSL encryption, or TCP/IP routing issue. If this is the case I apologize for posting to this mailing list in error.
Here's the additional info:
- Results of Telnet and a printout of the routing table:
# stunnel /usr/local/etc/stunnel/stunnel.conf # telnet localhost 8080 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused # telnet 172.30.128.100 8080 Trying 172.30.128.100... telnet: connect to address 172.30.128.100: No route to host # route -v Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.30.128.0 * 255.255.248.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 172.30.128.1 0.0.0.0 UG 0 0 0 eth0
- stunnel has logging? - Told you I hadn't used it much. - Don't know what the remote site is saying as I don't have access to those logfiles. I'm pretty sure it's running Windows IIS 5.0 - Here's the complete config file:
setuid = nobody setgid = nogroup
# Workaround for Eudora bug #options = DONT_INSERT_EMPTY_FRAGMENTS
# Authentication stuff verify=0 # don't forget about c_rehash CApath # it is located inside chroot jail: #CApath = /certs # or simply use CAfile instead: #CAfile = /usr/local/etc/stunnel/certs.pem # CRL path or file (inside chroot jail): #CRLpath = /crls # or simply use CAfile instead: #CRLfile = /usr/local/etc/stunnel/crls.pem
# Some debugging stuff #debug = 7 #output = stunnel.log
# Use it for client mode client=yes
# Service-level configuration
#[pop3s] #accept = 995 #connect = 110
#[imaps] #accept = 993 #connect = 143
#[ssmtp] #accept = 465 #connect = 25
#[s1] #accept = 5000 #connect = mail.osw.pl:110 # delay = yes
#[s2] #accept = 5001 #connect = mail.osw.pl:25
[https] accept=localhost:8080 connect=targetsite.com:443 TIMEOUTclose=0 transparent=yes
- shouldn't the link be transparent to the application utilizing it?
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
On Sat, 16 Oct 2004 10:39:57 +0200 (CEST), Jan Meijer jan.meijer@surfnet.nl wrote:
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
Jan,
You rock. Thanks. I was able to figure out the problem by uncommenting the debug option, and setting: foreground=yes
I hadn't created or set write permissions correctly on the chroot directory. Once I did that everything worked perfectly.
Many, many thanks for your guidance. It sometimes takes a nudge in the right direction.
Graeme
On Tue, 19 Oct 2004, Graeme Stewart wrote:
You rock. Thanks. I was able to figure out the problem by uncommenting the debug option, and setting: foreground=yes
Logging rules :). Great you've debugged your problem, enjoy using stunnel :).
Jan
-
Graeme Stewart -
Jan Meijer