Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6741)

Test that a server can handle an unecrypted alert when normally the next
message is encrypted.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6887)

Also retains support for drafts 27 and 26

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

(resolve uninitialized variable warning and harmonize output).
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5975)

Address the concern that commit c53c2fec raised differently.

The original direction of the traffic is encoded in bit 0
of the flight number.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5923)

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

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

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

When the proxy re-encrypted a TLSv1.3 record it was adding a spurious
byte onto the end. This commit removes that.

The "extra" byte was intended to be the inner content type of the record.
However, TLSProxy was actually adding the original encrypted data into the
record (which already has the inner content type in it) and then adding
the spurious additional content type byte on the end (and adjusting the
record length accordingly).

It is interesting to look at why this didn't cause a failure:

The receiving peer first attempts to decrypt the data. Because this is
TLSProxy we always use a GCM based ciphersuite with a 16 byte tag. When
we decrypt this it actually gets diverted to the ossltest engine. All this
does is go through the motions of encrypting/decrypting but just passes
back the original data. Crucially it will never fail because of a bad tag!
The receiving party thinks the spurious additional byte is part of the
tag and the ossltest engine ignores it.

This means the data that gets passed back to the record layer still has
an additional spurious byte on it - but because the 16 byte tag has been
removed, this is actually the first byte of the original tag. Again
because we are using ossltest engine we aren't actually creating "real"
tags - we only ever emit 16, 0 bytes for the tag. So the spurious
additional byte always has the value 0. The TLSv1.3 spec says that records
can have additional 0 bytes on the end of them - this is "padding". So the
record layer interprets this 0 byte as padding and strips it off to end up
with the originally transmitted record data - which it can now process
successfully.
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5370)

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

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

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

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

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

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)

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

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

Fix some comments too
[skip ci]
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3069)

This change will mean we will lose interoperability with draft-18
implementations.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2895)

Add some tests for the new record construction
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

This updates the record layer to use the TLSv1.3 style nonce construciton.
It also updates TLSProxy and ossltest to be able to recognise the new
layout.
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>

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

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

Prior to TLS1.3 we check that the received record version number is correct.
In TLS1.3 we need to ignore the record version number. This adds a test to
make sure we do it correctly.
Reviewed-by: NRich Salz <rsalz@openssl.org>

We should fail if we receive an unrecognised record type
Reviewed-by: NTim Hudson <tjh@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>

Test that we handle a TLS ClientHello in an SSLv2 record correctly.
Reviewed-by: NTim Hudson <tjh@openssl.org>

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

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

This commit provides a set of perl modules that support the testing of
libssl. The test harness operates as a man-in-the-middle proxy between
s_server and s_client. Both s_server and s_client must be started using the
"-testmode" option which loads the new OSSLTEST engine.

The test harness enables scripts to be written that can examine the packets
sent during a handshake, as well as (potentially) modifying them so that
otherwise illegal handshake messages can be sent.
Reviewed-by: NRichard Levitte <levitte@openssl.org>