wbrawner/openssl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fix BoringSSL external test failures

Browse source 
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)
This commit is contained in:
Matt Caswell 2018-08-22 14:10:48 +01:00
parent 5627f9f217
commit 2fe3e2b682
1 changed files with 6 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
test/ossl_shim/ossl_config.json
View file

@ -248,7 +248,12 @@
"DTLS-Retransmit-Server-12":"Test failure - reason unknown", "DTLS-Retransmit-Server-12":"Test failure - reason unknown",
"DTLS-Retransmit-Fudge":"Test failure - reason unknown", "DTLS-Retransmit-Fudge":"Test failure - reason unknown",
"DTLS-Retransmit-Fragmented":"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" : { "ErrorMap" : {
":UNEXPECTED_MESSAGE:":"unexpected message", ":UNEXPECTED_MESSAGE:":"unexpected message",