Dear patient users,
It seems that stunnel does not encrypt outward traffic from my pc. I was able to get stunnel to work in the first place by having different proxies for each protocol. However, to test if my 8196 bit + x509 certificate keys actually encrypted my traffic I decided to do a test. I had sniffed my own computer using Cain and Able while logging in to my home router. To my disappointment, the sniffer picked up my username and password in plain text through HTTP protocol several times. Either that or Able can crack 256bit level encryption (256 x 32 = 8196) rather quickly.
My stunnel.conf file:
; Sample stunnel configuration file by Michal Trojnara 2002-2005 ; Some options used here may not be adequate for your particular configuration
; Certificate/key is needed in server mode and optional in client mode cert = C:\Program Files\stunnel\stunnel.pem key = C:\Program Files\stunnel\stunnel.pem
; Some performance tunings socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1
; Workaround for Eudora bug options = DONT_INSERT_EMPTY_FRAGMENTS
; Authentication stuff ;verify = 2 ; Don't forget to c_rehash CApath; CApath is located inside chroot jail: ;CApath = certs ; It's often easier to use CAfile: ;CAfile = certs.pem ; Don't forget to c_rehash CRLpath; CRLpath is located inside chroot jail: ;CRLpath = crls ; Alternatively you can use CRLfile: ;CRLfile = crls.pem
; Some debugging stuff useful for troubleshooting ;debug = 7 ;dutput = C:\Program Files\stunnel\stunnel.log
; Use it for client mode client = yes
; Service-level configuration
client = yes verify = 0
;[pop3s] ;accept = 995 ;connect = 110
;[imaps] ;accept = 993 ;connect = 143
[ssmtp] accept = 127.0.0.1:465 connect = httpsupportingproxy4:3124 TIMEOUTclose = 0
[http] accept = 127.0.0.1:444 connect = httpsupportingproxy3:6588 TIMEOUTclose = 0
[https] accept = 127.0.0.1:443 connect = httpsupportingproxy2:6588 TIMEOUTclose = 0
[ftps] accept = 127.0.0.1:21 connect = httpsupportingproxy1:6588 TIMEOUTclose = 0
; vim:ft=dosini
And my bat file used to generate keys:
openssl req -new -x509 -days 365 -nodes -config C:\OpenSSL\bin\openssl.cnf -out stunnel.pem -keyout stunnel.pem
;requirements: ;OpensSSL.exe in C:\windows directory ;Installation of Win32OpenSSL-v0.9.8.mis to C:\ ;Edit C:\OpenSSL\bin\openssl.cnf strings ;[ req ] ;default_bits = 8196 ;default_keyfile = stunnel.pem ;distinguished_name = req_distinguished_name ;attributes = req_attributes ;x509_extensions = v3_ca # The extentions to add to the self signed cert
Cain Log:
================================================================== = Cain's MAC Scanner/Promiscuous-mode Detector = ================================================================== IP Address: (Router) MAC Address: (RouterMAC) OUI Fingerprint: Cisco-Linksys, LLC Hostname: ARP Test (Broadcast 31-bit): * ARP Test (Broadcast 16-bit): * ARP Test (Broadcast 8-bit): * ARP Test (Group bit): * ARP Test (Multicast group 0): * ARP Test (Multicast group 1): * ARP Test (Multicast group 3): *
Am I doing something wrong here?
On Mon, 26 Sep 2005, [email protected] wrote:
It seems that stunnel does not encrypt outward traffic from mypc. I was able to get stunnel to work in the first place by having different proxies for each protocol. However, to test if my 8196 bit + x509 certificate keys actually encrypted my traffic I decided to do a test. I had sniffed my own computer using Cain and Able while logging in to my home router. To my disappointment, the sniffer picked up my username and password in plain text through HTTP protocol several times. Either that or Able can crack 256bit level encryption (256 x 32 = 8196) rather quickly.
Cain and Able is not the appropriate tool to sniff traffic, use ethereal. Cain and Able is a very appropriate tool to spoof SSL connections to unsuspecting users. You have not turned on certificate verification in your stunnel configuration file so from an stunnel point of view that makes you an unsuspecting user.
Summarized: 1. I think you're being fooled by Cain and Able. 2. Don't use Cain and Able on a production machine. Bad bad bad.
Jan
On Tuesday 27 of September 2005 03:06, [email protected] wrote:
It seems that stunnel does not encrypt outward traffic from my pc. I was able to get stunnel to work in the first place by having different proxies for each protocol.
[cut]
To my disappointment, the sniffer picked up my username and password in plain text through HTTP protocol several times.
[cut]
; Use it for client mode client = yes
What's the reason to use client mode stunnel for http? Most web browsers support http natively.
[https] accept = 127.0.0.1:443 connect = httpsupportingproxy2:6588 TIMEOUTclose = 0
The port is also confusing. Since you use client mode your httpsupportingproxy2:6588 should be an SSL-enabled server and 127.0.0.1:443 is a plain http service, isn't it?
verify = 0
And to have a certificate-based authentication it's a good idea to turn it on. SSL is vulnerable to main-in-the-middle attacks, otherwise.
Best regards, Mike
-
Jan Meijer -
Michal Trojnara -
Revelancefound＠aol.com