Before this commit, certs.c had a copy of a different version of
tests/data_files/server2-sha256.crt (from the then development branch)
which was generated by cert_write. Update certs.c with the new
tests/data_files/server2-sha256.crt which is also generated by
cert_write.
The new copy has the same size as the old copy so there is no concern
about existing application binaries relying on the size. (The old
tests/data_files/server2-sha256.crt had a different size because it
had been generated by openssl and so had slightly different content.)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
I might be wrong, but lcc's optimizer is curious about this,
and I am too: shouldn't we free allocated stuff correctly
before exiting `dh_genprime` in this certain point of code?
Signed-off-by: makise-homura <akemi_homura@kurisa.ch>
server2-sha256.crt had the issuer ON and CN encoded as UTF8String, but the
corresponding CA certificate test-ca_cat12.crt had them encoded as
PrintableString. The strings matched, which is sufficient according to RFC
5280 §7.1 and RFC 4518 §2.1. However, GnuTLS 3.4.10 requires the strings to
have the same encoding, so it did not accept that the
UTF8String "PolarSSL Test CA" certificate was signed by the
PrintableString "PolarSSL Test CA" CA.
Since Mbed TLS 2.14 (specifically ebc1f40aa0
merged via https://github.com/ARMmbed/mbedtls/pull/1641), server2-sha256.crt
is generated by Mbed TLS's own cert_write program, which emits a
PrintableString. In older versions, this file was generated by OpenSSL,
which started emitting UTF8String at some point.
4f928c0f37 merged via
https://github.com/ARMmbed/mbedtls/pull/2418 fixed this for the SHA-1
certificate which was used at the time. The present commit applies the same
fix for the SHA-256 certificate that is now in use.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The test certificate used for clients in compat.sh, cert_sha256.crt,
had the issuer ON and CN encoded as UTF8String, but the corresponding
CA certificate test-ca_cat12.crt had them encoded as PrintableString.
The strings matched, which is sufficient according to RFC 5280 §7.1
and RFC 4518 §2.1. However, GnuTLS 3.4.10 requires the strings to have
the same encoding, so it did not accept that the certificate issued by
UTF8String "PolarSSL Test CA" was validly issued by the
PrintableString "PolarSSL Test CA" CA.
ebc1f40aa0, merged via
https://github.com/ARMmbed/mbedtls/pull/1641 and released in Mbed TLS
2.14, updated these certificates.
4f928c0f37 merged, via
https://github.com/ARMmbed/mbedtls/pull/2418 fixed this in the 2.7 LTS
branch for the SHA-1 certificate which was used at the time. The
present commit applies the same fix for the SHA-256 certificate that
is now in use.
For uniformity, this commit regenerates all the cert_*.crt.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For some reason, RIPEMD160, SHA224 and SHA384 were not supported.
This fixes the build recipes for tests/data_files/cert_sha224.crt and
tests/data_files/cert_sha384.crt .
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Replace server2.crt with server2-sha256.crt which, as the name implies, is
just the SHA-256 version of the same certificate.
Replace server1.crt with cert_sha256.crt which, as the name doesn't imply, is
associated with the same key and just have a slightly different Subject Name,
which doesn't matter in this instance.
The other certificates used in this script (server5.crt and server6.crt) are
already signed with SHA-256.
This change is motivated by the fact that recent versions of GnuTLS (or older
versions with the Debian patches) reject SHA-1 in certificates by default, as
they should. There are options to still accept it (%VERIFY_ALLOW_BROKEN and
%VERIFY_ALLOW_SIGN_WITH_SHA1) but:
- they're not available in all versions that reject SHA-1-signed certs;
- moving to SHA-2 just seems cleaner anyway.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Recent GnuTLS packages on Ubuntu 16.04 have them disabled.
From /usr/share/doc/libgnutls30/changelog.Debian.gz:
gnutls28 (3.4.10-4ubuntu1.5) xenial-security; urgency=medium
* SECURITY UPDATE: Lucky-13 issues
[...]
- debian/patches/CVE-2018-1084x-4.patch: hmac-sha384 and sha256
ciphersuites were removed from defaults in lib/gnutls_priority.c,
tests/priorities.c.
Since we do want to test the ciphersuites, explicitly re-enable them in the
server's priority string. (This is a no-op with versions of GnuTLS where those
are already enabled by default.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
As a result, the copyright of contributors other than Arm is now
acknowledged, and the years of publishing are no longer tracked in the
source files.
Also remove the now-redundant lines declaring that the files are part of
MbedTLS.
This commit was generated using the following script:
# ========================
#!/bin/sh
# Find files
find '(' -path './.git' -o -path './3rdparty' ')' -prune -o -type f -print | xargs sed -bi '
# Replace copyright attribution line
s/Copyright.*Arm.*/Copyright The Mbed TLS Contributors/I
# Remove redundant declaration and the preceding line
$!N
/This file is part of Mbed TLS/Id
P
D
'
# ========================
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
For explicit proxy commands (included with `-p "$P_PXY <args>` in the test
case), it's the test's writer responsibility to handle IPv6; only fix the
proxy command when we're auto-adding it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is a convenience for when we get log files from failed CI runs, or attach
them to bug reports, etc.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
A lot of DTLS test are timing-sensitive, especially those that contain
assertions about retransmission. Sometimes some DTLS test fails intermittently
on the CI with no clear apparent reason; we need more information in the log
to understand the cause of those failures.
Adding a proxy means we'll get timing information from the proxy logs.
An alternative would be to add timing information to the debug output of
ssl_server2 and ssl_client2. But that's more complex because getting
sub-second timing info is outside the scope of the C standard, and our current
timing module only provides a APi for sub-second intervals, not absolute time.
Using the proxy is easier as it's a single point that sees all messages, so
elapsed time is fine here, and it's already implemented in the proxy output.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In the entries (mbedtls_x509_crl_entry values) on the list constructed
by mbedtls_x509_crl_parse_der(), set entry->raw.tag to
(SEQUENCE | CONSTRUCTED) rather than to the tag of the first ASN.1
element of the entry (which happens to be the tag of the serial
number, so INTEGER or INTEGER | CONTEXT_SPECIFIC). This is doesn't
really matter in practice (and in particular the value is never used
in Mbed TLS itself), and isn't documented, but at least it's
consistent with how mbedtls_x509_buf is normally used.
The primary importance of this change is that the old code tried to
access the tag of the first element of the entry even when the entry
happened to be empty. If the entry was empty and not followed by
anything else in the CRL, this could cause a read 1 byte after the end
of the buffer containing the CRL.
The test case "X509 CRL ASN1 (TBSCertList, single empty entry at end)"
hit the problematic buffer overflow, which is detected with ASan.
Credit to OSS-Fuzz for detecting the problem.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a few more negative test cases for mbedtls_x509_crl_parse.
The test data is manually adapted from the existing positive test case
"X509 CRL ASN1 (TBSCertList, sig present)" which decomposes as
305c
3047 tbsCertList TBSCertList
020100 version INTEGER OPTIONAL
300d signatureAlgorithm AlgorithmIdentifier
06092a864886f70d01010e
0500
300f issuer Name
310d300b0603550403130441424344
170c303930313031303030303030 thisUpdate Time
3014 revokedCertificates
3012 entry 1
8202abcd userCertificate CertificateSerialNumber
170c303831323331323335393539 revocationDate Time
300d signatureAlgorithm AlgorithmIdentifier
06092a864886f70d01010e
0500
03020001 signatureValue BIT STRING
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
