- stunnel-users - stunnel.org

Client certificate using CAPI
by stunnel.org＠pepak.net 29 Jan '17

29 Jan '17

Hi! I am trying to use stunnel to connect to my own server using both a server and a client certificate. I got the tunnel to work, provided that the client uses a PEM certificate stored in a file. However, I would like to use CAPI, because that would allow me to use a smart card, which I finally got Windows to recognize (a nightmare of its own). Unfortunately, it seems that the client-side stunnel won't send a client certificate because the server-side stunnel will always close the connection with: SSL_accept: 140890C7: error:140890C7:SSL routines:ssl3_get_client_certificate:peer did not return a certificate My client-side stunnel log shows that server sent some kind of identification of all the supported client certificates to the client, but that's all - the client stunnel fails to follow through: TLS state (connect): SSLv3 read server key exchange A Client CA: emailAddress=some(a)email.com, O=Some name, CN=Pepak Yubico 4 White Client CA: emailAddress=root(a)email.com, CN=Pepak (root CA) TLS state (connect): SSLv3 read server certificate request A TLS state (connect): SSLv3 read server done A TLS state (connect): SSLv3 write client certificate A TLS state (connect): SSLv3 write client key exchange A TLS state (connect): SSLv3 write change cipher spec A TLS state (connect): SSLv3 write finished A TLS state (connect): SSLv3 flush data SSL_connect: Peer suddenly disconnected As far as I can tell, the CN=Pepak Yubico 4 White matches what my Windows show as the name of the certificate on the smartcard. Following up on https://www.stunnel.org/pipermail/stunnel-users/2016-February/005393.html, I tried to add a "key = Pepak Yubico 4 White" line to the client-side stunnel's config, but it doesn't seem to have any effect. What could be the problem? The client-side config file is: compression = deflate debug = debug fips = no taskbar = no options = NO_SSLv2 engine = capi [echo-client] client = yes accept = 3000 connect = 10.0.0.1:30000 requireCert = yes verifyChain = yes verifyPeer = yes CAfile = desktop.pem engineId = capi key = Pepak Yubico 4 White The only suspicious thing that I see is that my client certificate says that its only purpose is to verify the identity of the remote computer. Could that be the reason the handshake fails? Thanks for any help. Pepak

1 0

SSL errors do not trigger failover?
by Richard Monk 27 Jan '17

27 Jan '17

Hello! We are using stunnel to work around an SSL issue in another service, and set stunnel.conf up to do prio failover. We noticed something unusual. If the TCP session connects, but the SSL negotiation fails, it doesn't fail over to the next server on the list. I looked at the code for the latest version and this doesn't seem to be caught anywhere. What I saw in client.c shows that it only checks failover after trying to establish the TCP session, but then the SSL session happens later and doesn't give any info back to the failover code should something go wrong. Is this expected behavior, or should I look into a bug report / patch? I was thinking maybe a configurable option to allow SSL errors to trigger failover just like TCP errors. -- Richard Monk (rmonk(a)redhat.com) - Senior Principal Security Analyst Red Hat Inc. - Raleigh NC GPG Key ID: 0x942CDB25

1 0

Please Help to configure Stunnel for SHOUTcast
by Frans Rehl 24 Jan '17

24 Jan '17

Hello Stunnel Members I am wondering if any of you can help me to configure stunnel for shoutcast. I have a VPS with Windows Server 2012 R2 and I cannot find the correct configuration for windows server. Can someone help me please? My shoutcast is currently streaming on port 8000 however, I don't understand some part of the configuration, such as; cert -pem and ca-pem Could someone guide me? Best

1 0

Creating tunnel to smtp.office365.com:587
by Andrew Culver 17 Jan '17

17 Jan '17

Hello, This is my first time using stunnel so I'm still learning how it works. This may have already been asked, but I'm not sure what to search for in the archives. We have a number of hosts in private IP space that we'd like to be able to send mail to smtp.office365.com:587. I'm trying to configure stunnel for this purpose. What I'd like is to set up a stunnel instance on a server which will accept TLS connections on port 50025. Stunnel will then connect to smtp.office365.com:587 which also uses TLS. How can I do this? I am able to configure stunnel to accept my connection on 587, but the connection is immediately closed (below). If I add client = yes, then I just get: aculver stunnel # openssl s_client -starttls smtp -connect localhost:50025 CONNECTED(00000003) didn't found starttls in server response, try anyway... Here is my config: aculver stunnel # egrep -v '^;|^$' stunnel.conf ; Sample stunnel configuration file for Unix by Michal Trojnara 2002-2015 setuid = nobody setgid = nogroup pid = /usr/local/var/run/stunnel/stunnel.pid [o365-smtp] accept = 50025 cert = /usr/local/etc/stunnel/stunnel.pem connect = smtp.office365.com:587 verifyChain = yes CApath = /etc/ssl/certs protocol = smtp What am I doing wrong? Here's what I get when I don't have client = yes: aculver stunnel # openssl s_client -starttls smtp -connect localhost:50025 CONNECTED(00000003) depth=0 C = CA, ST = Ontario, L = London, O = The University of Western Ontario, OU = ITS, CN = aculver.ws.its.uwo.ca, emailAddress = aculver(a)uwo.ca verify error:num=18:self signed certificate verify return:1 depth=0 C = CA, ST = Ontario, L = London, O = The University of Western Ontario, OU = ITS, CN = aculver.ws.its.uwo.ca, emailAddress = aculver(a)uwo.ca verify return:1 139954991064736:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1263:SSL alert number 40 139954991064736:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- Certificate chain 0 s:/C=CA/ST=Ontario/L=London/O=The University of Western Ontario/OU=ITS/CN=aculver.ws.its.uwo.ca/emailAddress=aculver(a)uwo.ca i:/C=CA/ST=Ontario/L=London/O=The University of Western Ontario/OU=ITS/CN=aculver.ws.its.uwo.ca/emailAddress=aculver(a)uwo.ca --- Server certificate -----BEGIN CERTIFICATE----- MIIEJzCCAw+gAwIBAgIJAM0DgGLDIh5lMA0GCSqGSIb3DQEBCwUAMIGpMQswCQYD VQQGEwJDQTEQMA4GA1UECAwHT250YXJpbzEPMA0GA1UEBwwGTG9uZG9uMSowKAYD VQQKDCFUaGUgVW5pdmVyc2l0eSBvZiBXZXN0ZXJuIE9udGFyaW8xDDAKBgNVBAsM A0lUUzEeMBwGA1UEAwwVYWN1bHZlci53cy5pdHMudXdvLmNhMR0wGwYJKoZIhvcN AQkBFg5hY3VsdmVyQHV3by5jYTAeFw0xNzAxMTcxODAwNTdaFw0yMDAxMTcxODAw NTdaMIGpMQswCQYDVQQGEwJDQTEQMA4GA1UECAwHT250YXJpbzEPMA0GA1UEBwwG TG9uZG9uMSowKAYDVQQKDCFUaGUgVW5pdmVyc2l0eSBvZiBXZXN0ZXJuIE9udGFy aW8xDDAKBgNVBAsMA0lUUzEeMBwGA1UEAwwVYWN1bHZlci53cy5pdHMudXdvLmNh MR0wGwYJKoZIhvcNAQkBFg5hY3VsdmVyQHV3by5jYTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL2A3QEU7ReMc+2dTJdxVnQx33dIomQvO6QOAaFkI9pt XF/UhSBCg3ZD2yZeKe5GQ0+KqSCjuxTZE+BMTIeNUtaFEDr9bMAx0toknm29ve1B wTErWoIjE4yqQ+j/D9JLp4BzBcptz1zaEdvhzzZo2zWVpqHrUHSXzoIELD4xyZyF UgbQ057diKr1fqM7q3ozCofslFGEjWtc8SsfwgToT72g7bRhx8a6F6SSX8afcVx0 hvvC998QbTNUCpJO6GPzWWCsITc3RPMZK3OJsbI4NNBKDZ8eE2NTSkcKjnibRWFx bwCTlSZ5XABQrgXmEO51cx6DBAK/8cV8W2H/VNr9SXkCAwEAAaNQME4wHQYDVR0O BBYEFMPXcnQduKdorSNrFIR1up+a5V7RMB8GA1UdIwQYMBaAFMPXcnQduKdorSNr FIR1up+a5V7RMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAKqmaC+g RD1KEWT2yJit0FRIuwzFYmh/jgQ0ofabWQIuQtyNeqVnATU5FMOmox9MgbbsBanC SBVxuiLsWruk6VTjByHaIPAfsdWVKYMfLXO2Rku8GTp1X0B+HcNxh18tKr9s72rB AmapnD1GrYDAlBBgwQz+Ei1iRz+rqKsPvvJ/IEzZ02uhxV0ZWxBi5gTqAQc+pi3y I8DNBTxev2BMw+YCeNnrH3ryrJ8vKYlUmxE0k2POH1ihlpzdx9jtKC9TKR1kahMP 3lbldSHmW9DWeOfzQZ6NDHADSI698HaYfWQXUqbXjNJsxFb47pnjmyWgKseAT9iw w9nPDtkCmUihuBM= -----END CERTIFICATE----- subject=/C=CA/ST=Ontario/L=London/O=The University of Western Ontario/OU=ITS/CN=aculver.ws.its.uwo.ca/emailAddress=aculver(a)uwo.ca issuer=/C=CA/ST=Ontario/L=London/O=The University of Western Ontario/OU=ITS/CN=aculver.ws.its.uwo.ca/emailAddress=aculver(a)uwo.ca --- No client certificate CA names sent --- SSL handshake has read 1741 bytes and written 138 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: 9B6FC3BBEEADF6673416272CA03FA44A2B10BADB3B843317403C03904F0E45E922EA2581F313BF5282C0A47498E43C8D Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1484680413 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- aculver stunnel # Thanks, Andrew

1 0

Forwarding ip without HAProxy protocol
by John BYaka 06 Jan '17

06 Jan '17

Is it possible to forward real ip in special header? I know about 'protocol=proxy' but for using this i need to implement HAProxy protocol in app.

1 0

Stunnel and tokens on Windows
by stunnel.org＠pepak.net 31 Dec '16

31 Dec '16

Hi! I would very much like to switch my Stunnel setup to use hardware tokens. Stunnel apparently supports that using a PKCS11 engine, but I am having hard luck trying to figure it out for Windows, because 1) my practical experience with tokens is nonexistent at the moment, and 2) there are very few pages with a relevant information (basically, I was only able to find the very ancient http://martlaak.wikia.com/wiki/Stunnel_and_engine_pkcs11 and two russian pages http://forum.rutoken.ru/topic/1639/ and https://habrahabr.ru/post/135369/ which probably do just what I need, but I am not so sure they are applicable to my needs as I do not have a rutoken). I guess I would be satified if someone told me, "yes, these pages are applicable, just buy a xxxtoken instead of rutoken"; I would be happier with a full guide, but I can't expect anyone to write it - with the possible exception of Michal Trojnara's paid support (would that be possible?). Thanks, pepak

1 0

Re: [stunnel-users] Public domain [PATCH] support environment variables in config file
by Dmitry Bakshaev 21 Dec '16

21 Dec '16

2016-05-31 12:02 GMT+04:00 Pierre Delaage <delaage.pierre(a)free.fr>: > Did not have a look at the code yet, but should it be possible to replace > envvars usage by some keys in the registry on windows platform and/or > %userprofile%/config-file ? > > Anyway, my opinion on the patch is that there is no real interest for > "generic/self-expanding" config file , and it is even dangerous : > I would not trust stunnel if, at run time, its config could be modified by > USER envvars... > which difference between %userprofile%/config-file and USER envvars? both are USER owned and USER controlled. certificate and keys also USER private data. and stunnel started by USER owned by USER. if stunnel started by SYSTEM/ADMIN he uses SYSTEM/ADMIN envvars (if needed), certs, keys, etc. global "generic/self-expanding" config file is ADMIN owned. USER has permissions to substitute some values, restricted by ADMIN.

2 10

problem running stunnel as windows service
by Jeff Saxton 09 Dec '16

09 Dec '16

stunnel 5.38 on x86-pc-msvc-1500 platform compiled/running with OpenSSL 1.0.2j-fips 26 Sep 2016 Windows Server 2012R2 Standard When I try and start the service I get: Windows could not start the Secure Socket Tunneling Protocol Service on the Local Computer. Error: 1079: The account specified for this service is different from the account specified for other services running in the same process. So after a little reading I went into Services->Logon and checked: Allow Service to interact with desktop Same Error So I created an account in the Local Administrators group and gave it logon as a service Same thing Any ideas? -- Jeff Saxton Tanium CELL: +US 650.235.0776

1 0

Using transparent destination option with multiple network interfaces.
by Rodney Lott 08 Dec '16

08 Dec '16

Hi, there. Base server details: - Using the latest stunnel 5.37 - Ubuntu Trusty - The computers communicating with each other use bridged interface addresses that are configured by the clustering software (i.e. to ensure that at least one of the nodes is master and host to some common addresses) - For discussion purposes, let's say that each server has an eth0 and eth1, and that the master node has two additional bridged address (ie. eth0:shared-ip1, eth1:shared-ip2) - The slave nodes will try to connect to eth0:shared-ip1:20001 and eth1:shared-ip2:20001 that are hosted on the master - The master node will also try to connect to these as well, while listening on port 20001 - Not running in a chroot and am running stunnel as stunnel4 user - I have created a working solution using 4 services in the stunnel config and using hard-coded destinations in the iptables rules and the stunnel config. I want to create something more dynamic and versatile. I am trying to insert a stunnel instance between my server application that attempts to connect to its twin on another server, using the bridging addresses. I am trying to avoid hard-coding destination IP addresses in my stunnel configuration file and the iptables rules. I also don't want to have separate rules for each interface. For example, from server A's perspective (i.e. the master node), the desirable sequence of events are: - Attempt to connect to port 20001 using the bridge addresses as destinations (in this case, they would be local interfaces). - Intercept the requests to port 20001 on server A and divert them to port 40000 for encryption (i.e. the local stunnel instance). - Send unencrypted data from stunnel directly to local 20001. At the same time, server B is doing the same, except that the bridge addresses reside on server A and are not local. So, server A would also need to do this: - Intercept external request for port 20001 and send it to stunnel port 40000 for encryption - Send decrypted packets to local port 20001 This same type of sequence would also be happening My stunnel configuration looks like this: fips=yes pid=/var/run/stunnel4/testsrv.pid debug=7 output=/var/log/stunnel4/testsrv.log sslVersion = TLSv1.2 key = <private-key-location> cert = <cert-location> CAfile = <ca-file-location> ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:AES256-GCM-SHA384:AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:AES128-GCM-SHA256:AES128-SHA256 [test-srv] client=yes accept=40000 transparent=destination My iptables rules, base on what I read in the man page, are this: STUNNEL_UID=$(id -u stunnel4) # Redirect any incoming requests to port 20001 iptables -t nat -A PREROUTING -p tcp --dport 20001 ! -i lo -j DNAT --to-destination 127.0.0.1:40000 iptables -A INPUT -p tcp --dport 40000 -j ACCEPT # Redirect any outgoing locally generated requests for 20001 to stunnel port 40000 iptables -t nat -A OUTPUT -p tcp --dport 20001 -m owner ! --uid-owner $STUNNEL_UID -j DNAT --to-destination 127.0.0.1:40000 # Redirect the output of stunnel to the local 20001 port iptables -t nat -A OUTPUT -p tcp --dport 20001 -m owner --uid-owner $STUNNEL_UID -j REDIRECT --to-ports 20001 iptables -t nat -A INPUT -p tcp -d 127.0.0.1 --dport 20001 -j ACCEPT These rules are not completely adequate. For now, I'm just trying to get server A's connection to port 20001 working without having to worry about incoming from server B. When I do this and start stunnel and my process, server A's stuff appears to loop endlessly. I think this is happening because the packets that come out of stunnel, due to the transparency configuration, look exactly the same as the original. If I log stuff using iptables, I see repeat entries like this: nat-OUTPUT: IN= OUT=lo SRC=150.150.242.26 DST=150.150.242.27 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30541 DF PROTO=TCP SPT=50101 DPT=20001 WINDOW=43690 RES=0x00 SYN URGP=0 filter-OUTPUT: IN= OUT=lo SRC=150.150.242.26 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30541 DF PROTO=TCP SPT=50101 DPT=40000 WINDOW=43690 RES=0x00 SYN URGP=0 nat-POSTROUTING: IN= OUT=lo SRC=150.150.242.26 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30541 DF PROTO=TCP SPT=50101 DPT=40000 WINDOW=43690 RES=0x00 SYN URGP=0 filter-INPUT: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=150.150.242.26 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30541 DF PROTO=TCP SPT=50101 DPT=40000 WINDOW=43690 RES=0x00 SYN URGP=0 filter-OUTPUT: IN= OUT=lo SRC=150.150.242.26 DST=127.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=30542 DF PROTO=TCP SPT=50101 DPT=40000 WINDOW=342 RES=0x00 ACK URGP=0 filter-INPUT: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=150.150.242.26 DST=127.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=30542 DF PROTO=TCP SPT=50101 DPT=40000 WINDOW=342 RES=0x00 ACK URGP=0 nat-OUTPUT: IN= OUT=lo SRC=150.150.242.26 DST=150.150.242.27 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48827 DF PROTO=TCP SPT=50102 DPT=20001 WINDOW=43690 RES=0x00 SYN URGP=0 filter-OUTPUT: IN= OUT=lo SRC=150.150.242.26 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48827 DF PROTO=TCP SPT=50102 DPT=40000 WINDOW=43690 RES=0x00 SYN URGP=0 nat-POSTROUTING: IN= OUT=lo SRC=150.150.242.26 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48827 DF PROTO=TCP SPT=50102 DPT=40000 WINDOW=43690 RES=0x00 SYN URGP=0 filter-INPUT: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=150.150.242.26 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48827 DF PROTO=TCP SPT=50102 DPT=40000 WINDOW=43690 RES=0x00 SYN URGP=0 filter-OUTPUT: IN= OUT=lo SRC=150.150.242.26 DST=127.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=48828 DF PROTO=TCP SPT=50102 DPT=40000 WINDOW=342 RES=0x00 ACK URGP=0 filter-INPUT: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=150.150.242.26 DST=127.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=48828 DF PROTO=TCP SPT=50102 DPT=40000 WINDOW=342 RES=0x00 ACK URGP=0 filter-OUTPUT: IN= OUT=lo SRC=150.150.242.26 DST=127.0.0.1 LEN=269 TOS=0x00 PREC=0x00 TTL=64 ID=48829 DF PROTO=TCP SPT=50102 DPT=40000 WINDOW=342 RES=0x00 ACK PSH URGP=0 filter-INPUT: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=150.150.242.26 DST=127.0.0.1 LEN=269 TOS=0x00 PREC=0x00 TTL=64 ID=48829 DF PROTO=TCP SPT=50102 DPT=40000 WINDOW=342 RES=0x00 ACK PSH URGP=0 ... As can be seen, line 1 and line 7 are virtually identical. In the stunnel log, I can see that stunnel is receiving multiple requests for port 20001 in rapid succession but is not actually receiving any reply from the final destination. So, if anyone has any ideas, tweaks or suggestions for how to solve this problem or where I am going wrong, I would appreciate it. I can use a static configuration with hard-coded destination IP's but if there is an alternative, I would like to know. I have tried for several days to figure this out and have searched Google extensively, including stunnel-users postings, to figure out how to do this without success. Thanks, Rodney Lott

1 1

setgroups: notowner (1)
by Jones, Russell - NONEMP 08 Dec '16

08 Dec '16

I am working on a project where we are migrating to a new datacenter. The new datacenter will not allow compilers on their servers, so I am unable to do a new stunnel build on the new server. I am attempting to move the stunnel install/executables from the old server to the new one. I got past several errors for libraries not found, but now I am stuck. stunnel process will not start, and gets several messages "setgoups: Not owner (1)" I am not sure what I need to do with permissions, ownership, etc to make this work. log attached Thanks for your help, Russell J. This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose.

1 0