I received this error from a TLSProxy test:

Failed to start up server (localhost,4443): Transport endpoint is not
connected

So, extend the timeout before we give up trying to connect to the server.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5088)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5071)

Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4701)

Normally TLSProxy waits for the s_server process to finish before
continuing. However in cases where serverconnects > 1 we need to keep the
s_server process around for a later test so we continue immediately. This
means that TAP test output can end up being printed to stdout at the same
time as s_server is printing stuff. This confuses the test runner and can
cause spurious test failures. This commit introduces a small delay in cases
where serverconnects > 1 in order to give s_server enough time to finish
what it was doing before we continue to the next test.

Fixes #4129
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4660)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4305)

Instead of having perl modules under test/testlib, util and util/perl,
consolidate them all to be inside util/perl.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4069)

In a recent PR (#3566) it seems that TLSProxy gave up trying to connect to
the server process too quickly. This meant the test failed even though the
server *did* eventually start. Currently we try 3 times to connect with a
0.1 second pause between each attempt. That is probably too aggressive.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3587)

Issue #3562 describes a problem where a race condition can occur in the
Proxy such that a test "ok" line can appear in the middle of other text
causing the test harness to miss it. The issue is that we do not wait for
the client process to finish after the test is complete, so that process may
continue to write data to stdout/stderr at the same time that the test
harness does.

This commit fixes TLSProxy so that we always wait for the client process to
finish before continuing.

Fixes #3562
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3567)

When you want to debug a test that goes wrong, it's useful to know
exactly what subprocess commands are run.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3342)

The logic for testing whether the sessionfile has been created or not
was faulty and could result in race conditions. If you "lose" the tests
hang waiting for a session file that's never going to arrive.

Fixes #2950
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2955)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2341)

TLSProxy normally fires off s_client, which creates a connection to the
server. TLSProxy also pipes some data to send to the process and s_client
automatically exits when the pipe hits eof. Unfortunately this means that
it sends the data and closes before it has processed the NewSessionTicket
returned from the server in TLSv1.3. This commits adds an option for
s_client to stay loaded until the sesion has been processed. A side effect
of this is that s_client never sends a close_notify in this mode, so we
count success as seeing that data has been transferred.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2259)

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2205)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2157)

Also updates TLSProxy to be able to understand the format and parse the
contained extensions.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2020)

The previous commit fixed a bug where the EC point formats extensions did
not appear in the ServerHello. This should have been caught by
70-test_sslmessages but that test never tries an EC ciphersuite. This
updates the test to do that.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2153)

The indentation was a bit off in some of the perl files following the
extensions refactor.

Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich
Salz
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich
Salz
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Extend test_tls13messages to additionally check the expected extensions
under different options given to s_client/s_server.

Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich
Salz
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

After the client processes the server's initial flight in TLS1.3 it may
respond with either an encrypted, or an unencrypted alert. We needed to
teach TLSProxy about this so that it didn't issue spurious warnings.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Now that ossltest knows about a TLS1.3 cipher we can now do TLS1.3 in
TLSProxy
Reviewed-by: NRich Salz <rsalz@openssl.org>

Includes addition of the various options to s_server/s_client. Also adds
one of the new TLS1.3 ciphersuites.

This isn't "real" TLS1.3!! It's identical to TLS1.2 apart from the protocol
and the ciphersuite...and the ciphersuite is just a renamed TLS1.2 one (not
a "real" TLS1.3 ciphersuite).
Reviewed-by: NRich Salz <rsalz@openssl.org>

This is a regression test for
https://github.com/openssl/openssl/pull/1431. It tests a
maximally-padded record with each possible invalid offset.

This required fixing a bug in Message.pm where the client sending a
fatal alert followed by close_notify was still treated as success.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

On some platforms we can't startup the TLSProxy due to environmental
problems (e.g. network set up on the build machine). These aren't OpenSSL
problems so we shouldn't treat them as test failures. Just visibly
indicate that we are skipping the test.

We only skip the first time we attempt to start up the proxy. If that works
then everything else should do...if not we should probably investigate and
so report as a failure.

This also removes test_networking...there is a danger that this turns into
a test of user's environmental set up rather than OpenSSL.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Workaround an apparent IO:Socket::IP bug where a seemingly valid
server socket is being returned even though a valid connection does not
exist. This causes the tests to intermittently hang. We additionally check
that the peerport looks ok to verify that the returned socket looks usable.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

TLSProxy starts s_server and specifies the number of client connects
it should expect. After that s_server is supposed to close down
automatically. However, if another test is then run then TLSProxy
will start a new instance of s_server. If the previous instance
hasn't closed down yet then the new instance can fail to bind to
the socket.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

It's near impossible to figure out what goes wrong with the execution
of sub-commands otherwise.
Reviewed-by: NRich Salz <rsalz@openssl.org>

While IO::Socket::IP is a core perl module (since Perl v5.19.8, or so
says corelist), IO::Socket::INET6 has been around longer, is said to
be more widely deployed, and most importantly, seems to have less bugs
hitting us.  We therefore prefer IO::Socket::INET6, and only fall back
to IO::Socket::IP if the former doesn't exist on the local system.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>

When connecting to "localhost" the Proxy's choice of client address
family may not match the server's choice address family.  Without
MultiHomed => 1, the proxy may try the wrong address family first,
and give up without trying the other.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

This makes use of TLSProxy, which was expanded to use IO::Socket::IP
(which is a core perl module) or IO::Socket::INET6 (which is said to
be more popular) instead IO::Socket::INET if one of them is installed.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

CRIME protection: disable compression by default, even if OpenSSL is
compiled with zlib enabled. Applications can still enable compression by
calling SSL_CTX_clear_options(ctx, SSL_OP_NO_COMPRESSION), or by using
the SSL_CONF library to configure compression. SSL_CONF continues to
work as before:

SSL_CONF_cmd(ctx, "Options", "Compression") enables compression.

SSL_CONF_cmd(ctx, "Options", "-Compression") disables compression (now
no-op by default).

The command-line switch has changed from -no_comp to -comp.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reuse is deprecated and ReuseAddr is prefered, according to documentation.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>