Re: Strange connection failure in one environment

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============3323978809748394232==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="tB8vw0mzxnXfuxLGKVMX23N7Y91jWshVS"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--tB8vw0mzxnXfuxLGKVMX23N7Y91jWshVS
Content-Type: multipart/mixed; boundary="vTsrokcvW4a5wVXG9eI4wHKAuiG71SN7m";
 protected-headers="v1"
From: Christopher Schultz <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: Re: Strange connection failure in one environment
References: <[email protected]>
In-Reply-To: <[email protected]>

--vTsrokcvW4a5wVXG9eI4wHKAuiG71SN7m
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

All,

On 10/25/19 10:09, Christopher Schultz wrote:
> All,
>=20
> 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.
>=20
> Can someone take a look and let me know if you have any suggestions for=

> where to look for a problem?
>=20
> Both environments have the following things in common:
>=20
> 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 bot=
h
> sides
> 4. TLS configuration has been locked-down to TLSv1.2, selected cipher
> suites, FIPS mode=3Doff
> 5. All versions are the same: stunnel 4.56 w/OpenSSL 1.0.2k-fips
>=20
> 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.
>=20
> 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 allowe=
d
> client certificates.
>=20
> When I do the same in development, I get a handshake failure. No allowe=
d
> client certificates are shown. No nothing.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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


--vTsrokcvW4a5wVXG9eI4wHKAuiG71SN7m--

--tB8vw0mzxnXfuxLGKVMX23N7Y91jWshVS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2zELoACgkQHPApP6U8
pFig8w//VE1KvAO7zC+Cixd7ZLztcNjZe2bFl+AUTjf+7fGRw3rttj0ACTM3U6XH
VoHpPlQDuVvLXFyjMlNyrMpko4iNrP3yN+gC8+wqeVtHdJ27IO9hDkyDM/X9S0p+
CziAuBbonzj036wRNtSkJJgp9rG3BiPdmPYFr9g/k3y9MdkjLaTN+rtF0v7HCEW3
+Qna20V3w8lYjC7rUcCxKp5cKpvce7wFOuz/RmLGspkzrtCDrd5djyPWfZctagQi
axEueBzSktt9Y5rwb9szijXnOWyLQrxv5rxBeGjtLifF/Ro6bydz2eDz8yrhDWp9
kkQ6U1TIhBqKBR77VWxUt6TewBllu2Ixj+uGv1al9Q2awRDP5Gsh+GOGCoFH4G4i
Mw6Z9oBYqcjHZxwyRf6Zd8FBZe1m6zipetYZJNMAY3/Poh0WJuJVN+jEF2bZqKu5
44JnAd9Aufk5gqlREjI7kIIhdbwOYU/IIiJoTs4QmlflCwtLwzpDs+FO2iTgMkMq
aea1V0tNPABFwEY+I4Q5YlAmSZVm0K/IYS2yFow48iYtloN3TRyFUxXxwpgFS0+y
atmR4u46oJV+PhRw31g0BujShuYokYl53Wl4rl1wwR5BhEAcScNcCMLDESbnigkl
LwG6QYgmpQ2xnKfiCrO0KOKQaYcuRO1oq1pGdKSBGoratd15efE=
=gWCl
-----END PGP SIGNATURE-----

--tB8vw0mzxnXfuxLGKVMX23N7Y91jWshVS--

--===============3323978809748394232==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
stunnel-users mailing list
[email protected]
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

--===============3323978809748394232==--