Fix BoringSSL external test failures
authorMatt Caswell <matt@openssl.org>
Wed, 22 Aug 2018 13:10:48 +0000 (14:10 +0100)
committerMatt Caswell <matt@openssl.org>
Wed, 22 Aug 2018 14:15:19 +0000 (15:15 +0100)
We recently turned on the TLSv1.3 downgrade sentinels by default.
Unfortunately we are using a very old version of the BoringSSL test
runner which uses an old draft implementation of TLSv1.3 that also
uses the downgrade sentinels by default. The two implementations do
not play well together and were causing spurious test failures. Until
such time as we update the BoringSSL test runner we disable the failing
tests:

SendFallbackSCSV

In this test the client is OpenSSL and the server is the boring test runner.
The client and server fail to negotiate TLSv1.3 because the test runner is
using an old draft TLSv1.3 version. The server does however add the
TLSv1.3->TLSv1.2 downgrade sentinel in the ServerHello random. Since we
recently turned on checking of the downgrade sentinels on the client side
this causes the connection to fail.

VersionNegotiationExtension-TLS11

In this test the test runner is the client and OpenSSL is the server. The
test modifies the supported_versions extension sent by the client to only
include TLSv1.1 (and some other spurious versions), even though the client
does actually support TLSv1.2. The server successfully selects TLSv1.1, but
adds the TLSv1.3->TLSv1.1 downgrade sentinel. This behaviour was recently
switched on by default. The test runner then checks the downgrade sentinel
and aborts the connection because it knows that it really supports TLSv1.2.

VersionNegotiationExtension-TLS1
VersionNegotiationExtension-SSL3

The same as VersionNegotiationExtension-TLS11 but for TLSv1 and SSLv3.

ConflictingVersionNegotiation

In this test the client is the test runner, and OpenSSL is the server. The
client offers TLSv1.2 in ClientHello.version, but also adds a
supported_versions extension that only offers TLSv1.1. The
supported_versions extension takes precedence and the server (correctly)
selects TLSv1.1. However it also adds the TLSv1.3->TLSv1.1 downgrade
sentinel. On the client side it knows it actually offered TLSv1.2 and so the
downgrade sentinel check fails.

[extended tests]

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7013)

test/ossl_shim/ossl_config.json

index 0643d71136299c3e801d2ee8ca2c13aab88dbfe3..1e57499065176f1075e9f3453eba7d4f14f5f3ae 100644 (file)
         "DTLS-Retransmit-Server-12":"Test failure - reason unknown",
         "DTLS-Retransmit-Fudge":"Test failure - reason unknown",
         "DTLS-Retransmit-Fragmented":"Test failure - reason unknown",
-        "TrailingMessageData-ClientHello-DTLS":"Test failure - reason unknown"
+        "TrailingMessageData-ClientHello-DTLS":"Test failure - reason unknown",
+        "SendFallbackSCSV":"Current runner version uses old draft TLSv1.3",
+        "VersionNegotiationExtension-TLS11":"Current runner version uses old draft TLSv1.3",
+        "VersionNegotiationExtension-TLS1":"Current runner version uses old draft TLSv1.3",
+        "VersionNegotiationExtension-SSL3":"Current runner version uses old draft TLSv1.3",
+        "ConflictingVersionNegotiation":"Current runner version uses old draft TLSv1.3"
     },
     "ErrorMap" : {
         ":UNEXPECTED_MESSAGE:":"unexpected message",