All,

On 10/25/19 10:09, Christopher Schultz wrote:

All,

I've been using stunnel in two environments (dev, prod) for a long time without any problems. Recently, my dev environment started acting funny and I can't connect to it from outside the box.

Can someone take a look and let me know if you have any suggestions for where to look for a problem?

Both environments have the following things in common:

1. Hosted in Amazon EC2, no load-balancer in the way
2. Configuration requires client-certificate to connect
3. All certificates are valid, self-signed, and properly-trusted by both

sides 4. TLS configuration has been locked-down to TLSv1.2, selected cipher suites, FIPS mode=off 5. All versions are the same: stunnel 4.56 w/OpenSSL 1.0.2k-fips

The production (working) environment happens to be i686 and the development environment happens to be x86-86, but I don't believe that is relevant.

When I use e.g. "openssl s_client" to connect to the production environment and I *do not* provide a client certificate, I am able to perform the initial TLS handshake, get a cipher suite negotiated, etc. and then the connection fails because I didn't provide the client certificate, of course. I *can* see in the handshake the list of allowed client certificates.

When I do the same in development, I get a handshake failure. No allowed client certificates are shown. No nothing.

If I connect on localhost to the dev server, I get what I'm expecting: allowed client certificates are listed, connection is closed because I'm not using the client certificate. Connecting from another host gets my a handshake failure.

Again, there are no load-balancers or anything between the outside and the EC2 instance. I'm connecting as directly as it's possible to connect. The box definitely allows incoming connections on the port I'm trying to use; the AWS security group is configured correctly.

I have tried dropping ALL security configuration on the dev server's stunnel.conf such as client-cert requirements, TLS protocols, cipher suites, etc. and I get the same behavior every time. I'm starting to think that it has nothing to do with my stunnel.conf configuration at all, but I'm at a loss as to where to look, next.

Any ideas?

Some more information:

0. The error I get on the client is "handshake failure" and the stunnel server drops this log message:

SSL_accept: 1408A0C1: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher

Note that I have disabled all but TLSv1.2 on the server. Removing this restriction does not change the behavior.

1. I have multiple stunnel configuration files on this server. Actually, I have 4 of them. Connections to ports defined in 2 of these files are not connecting successfully. Connections to ports defined in the OTHER two files *are* connecting successfully.

The configurations seem to follow a pattern: those using RSA certificates as the server-certificate are working as expected, while those with EC server-certificate are failing.

When I say "working" versus "failing", I mean that this command will give me a cipher suite and master key, but still drop the connection because I'm not providing a client-certificate for these tests:

$ openssl s_client -connect host:port

2. I have a Java-based service that *is* able to connect through this stunnel instance just fine. It's running on a recent version of Java 8. My CLI client (not OpenSSL) is also running the same version. My CLI client cannot connect. *weird* In both cases, I am using EC client certificates, but the certificates are different from each other. Both of these certificates are trusted by the server.

3. When using OpenSSL 1.0.2t, I *can* connect, get the list of acceptable client certificates, etc. even without providing a client certificate.

When using OpenSSL 1.1.1d, I can *not* connect.

So perhaps the inside/outside networking thing I was thinking the problem might be is incorrect.

AFAIK, both versions of OpenSSL should be able to use EC certificates and cipher suites.

Thanks, -chris