- stunnel-users - stunnel.org

RSA too big problem
by Vikrant Agarwal 16 Feb '17

16 Feb '17

Hi, I upgraded my Stunnel server machine to CentOS 6.8 and post upgrade , the stunnel too got upgraded to stunnel 4.29 on x86_64-redhat-linux-gnu with OpenSSL 1.0.1e-fips 11 Feb 2013 . Now since then many of the stunnel client using newer stunnel client (those uses TLSv1.2 for Negotiation) are not able to connect . I get below error on the server in logs RSA_sign:digest too big for rsa key:rsa_sign’ How to fix this please? Regards, Vikrant

1 0

Re: [stunnel-users] Problem with 5.40 and Peer suddenly disconnected
by Brian McGinity 08 Feb '17

08 Feb '17

I found the archives and downgraded to 5.37 and this fixed the problem. Before going this route I tried 5.40 and 5.41 beta and both had the same issues with 'Peer suddenly disconnected'. Strange that it this was only happening for one particular connection (1 out of 7). It would happen with every test. If you would like for me to beta test another version, I would be happy to try. Bran

1 0

Problem with 5.40 and Peer suddenly disconnected
by Brian McGinity 08 Feb '17

08 Feb '17

After updating to stunnel 5.40 on x86-pc-msvc-1500 platform, I am getting a Peer suddenly disconnected each time I post data to a particular url. [VISION_WEB] client = yes accept = 127.0.0.1:1935 connect = xx.xx.web.com:443 sslVersion = TLSv1 2017.02.07 16:30:08 LOG5[160]: Service [XX_WEB] accepted connection from 192.168.100.21:53507 2017.02.07 16:30:08 LOG5[160]: s_connect: connected 11.11.111.36:443 2017.02.07 16:30:08 LOG5[160]: Service [XX_WEB] connected remote server from 192.168.100.21:53508 2017.02.07 16:30:08 LOG3[160]: SSL_connect: Peer suddenly disconnected 2017.02.07 16:30:08 LOG5[160]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket This is a production issue and is causing a lot of problems for a lot of people and I need to do something quickly. Is it possible to download stunnel 5.37 installed to see if going back to this version will fix this issue? Where is it? Or does anyone possibly know why this might be happening? Thank you for your help. Brian

1 0

Default passthrough to different destination?
by Mark Boyce 03 Feb '17

03 Feb '17

Hi All Wondering if there’s a way to pass an unencrypted connections traffic to an alternative location if a client does not SSL/TLS with the stunnel server? So considering stunnel running as a server to wrap an unencrypted SMTP server. If the SMTP client/server talks SSL/TLS all is good and as expected. If the client tries to talk without encryption it gets disconnect. Is there any way to send this traffic elsewhere rather than disconnecting the client? So that stunnel is adding an SSL/TLS option to a service rather than enforcing it. Splitting the traffic to destination servers based on if the client was encrypted or not. Thoughts? Thanks Mark

2 3

Mixed cert/PSKsecrets & TLS/SSL before proxy
by Varda Zklir 02 Feb '17

02 Feb '17

Hello Gentlemen. Needs help in configuration or negative clarifications on two issues. 1) First question whether is mixed use of cert/PSKsecrets auth possible? The same method (ether cert or PSKsecrets explicitly) serverside trough the parent [TLS] and inherited services works properly. But mixed cert/PSKsecrets like in config snippet below doesn't work. [TLS] client = no accept = 0.0.0.0:https connect = localhost:http cert = /etc/opt/stunnel/stunnel.pem [ssh] client = no sni = TLS:ssh connect = localhost:ssh [socks] client = no sni = TLS:socks protocol = socks PSKsecrets = /etc/opt/stunnel/auth/passwd The idea is to pass insensibly all incorrect or non-SNI aware requests to main http server and hide other multiplexed services. And at the same time to establish encryption and password access control to [socks] service. 2) And the second question is it possible proxy CONNECT after establishing SSL/TLS encryption? The configuration section: [ssh] accept = 22222 protocol = connect protocolHost = server.tld:443 protocolUsername = usernamehere protocolPassword = passwordhere connect = proxy.tld:8080 Say to establish unencrypted connection with proxy, pass username and password, tell proxy to establish CONNECT to target 443 and then transmit SSL/TLS to it. Goal is if I have SSL/TLS termination server/proxy on port 443 so we at first speak SSL/TLS with proxy and only then proceed to proxy requests phase. Thanks for future explanations.

1 0

installation problems
by HOFFMAN, GEOFFREY 30 Jan '17

30 Jan '17

I am having trouble installing stunnel on CentOS 7.3. I was given a directive to "use the latest OpenSSL" so on one target machine, it has 1.0.2k built from source. On the machine with OpenSSL 1.0.2k, when attempting to install stunnel, when I run ./configure, it passes with this info: configure: FIPS support not found Then make fails with: /usr/bin/ld: /usr/local/ssl/lib/libssl.a(s3_srvr.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC On another target machine, it has 1.0.1e-fips, installed via yum package. On the machine with OpenSSL 1.0.1e-fips, ./configure fails with: checking for TLS directory... not found configure: error: Could not find your TLS library installation dir Advice on installing with the latest OpenSSL (1.0.2k) would be much appreciated. This e-mail, including any attachments, is meant only for the intended recipient of the transmission, and may be a confidential communication or a communication privileged by law. If you received this e-mail in error, any review, use, dissemination, distribution, or copying of this e-mail is strictly prohibited. Please notify us immediately of the error by return e-mail and please delete this message from your system. Thank you in advance for your cooperation.

1 0

Life cycle information
by Ben Harper 30 Jan '17

30 Jan '17

Greetings, I am trying to confirm some life cycle information, mainly supported version(s) and what versions do not insure backwards compatibility. It would appear that only the latest version is supported, per the first item under 'Before you send your question to stunnel-users' on the Mailing Lists page[0]. Does this project use semantic versioning? Will incompatibilities only come when a 6.x.x version is released? It seems at one point this was the case per the 'Upgrading to stunnel 4' link on the Documentation page[1]. Are my assumptions correct? Thanks, Ben [0]: https://www.stunnel.org/lists.html [1]: https://www.stunnel.org/docs.html

1 0

Proxy one site to HTTPS?
by Jeffrey Walton 30 Jan '17

30 Jan '17

Hi Everyone, I'm having trouble setting up a proxy for one site. The client is MacPorts on OS X 10.5. It makes some requests for files over port 80, but they apparently need to be made over port 443. Also see https://trac.macports.org/ticket/53423 and https://trac.macports.org/ticket/53347. My first question is, is it possible to proxy one site to HTTPS? My second question is, how does one do so if it is possible? The concrete example from the 53423 bug report is, I need to proxy requests from http://distfiles.macports.org/... to https://distfiles.macports.org/... I also need the opposite on the responses. Thanks in advance, Jeff

1 0

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