Tests fail in 2019-11-25

[bmwiedemann]

While working towards openSUSE reproducible builds, I found that mbedtls does not build in 2020

Description

• Type: Bug
• Priority: Minor

---

Bug

mbed TLS build:
Version: 2.14.1
OS version: any

Expected behavior
software should build anytime anywhere

Actual behavior
FAILED (486 / 518 tests (86 skipped))
See full log in
https://bugzilla.opensuse.org/show_bug.cgi?id=1081871#c6

Steps to reproduce
build mbedtls in 2020 and run its testsuite
e.g. on openSUSE or Debian
have a free openSUSE account,
have kvm, osc and build or obs-build packages installed. Then run

osc checkout openSUSE:Factory/mbedtls && cd $_
osc build --vm-type=kvm --build-opt=--vm-custom-opt="-rtc base=2020-03-01T01:01:01" --noservice

Could probably be solved similarly to https://dev.gnupg.org/T3815
with a cert that never expires (or only in the year 2999)

[hanno-becker]

Hi @bmwiedemann,

thank you for the report and for making us aware that the expiry date of the test certificates is so close. 👍 We'll look into it (before 2020).

Kind Regards,
Hanno

[bmwiedemann]

I looked at the .crt file from "Certificate verification #5" and expiry is later.

# openssl x509 -text -in ./tests/data_files/test-ca.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3 (0x3)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=NL, O=PolarSSL, CN=PolarSSL Test CA
        Validity
            Not Before: Feb 12 14:44:00 2011 GMT
            Not After : Feb 12 14:44:00 2021 GMT

Maybe SHA1 is deprecated after 2019-11-25? Or some extra cert is involved?

[RonEld]

have you defined MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES in your configuration?
By default it is undefined, for security reasons.

[bmwiedemann]

No, we have not defined that and it is also default-off in our 2.16.0 package.
But why would a test succeed then on 2019-11-24 but not 2019-11-26 ?
Also, can you reproduce the test failures when you adjust your clock before running tests?

[RonEld]

Thank you for the information.
Looking a bit further at this issue, it is because the following:
The log indicate that the negative path fails, because the expected flags are not equal to the returned flags.
If you look at the crl used in these failed tests, using openssl crl -in crl.pem -noout -text, you will see

Certificate Revocation List (CRL):
        Version 1 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: /C=NL/O=PolarSSL/CN=PolarSSL Test CA
        Last Update: Feb 20 10:22:59 2011 GMT
        Next Update: Nov 25 10:22:59 2019 GMT
Revoked Certificates:
    Serial Number: 01
        Revocation Date: Feb 12 14:44:07 2011 GMT
    Serial Number: 03
        Revocation Date: Feb 12 14:44:07 2011 GMT
    Signature Algorithm: sha1WithRSAEncryption
         96:2e:59:d2:8f:75:b9:4c:55:60:a7:c6:93:27:72:1b:8b:76:
         a5:b3:2b:60:40:d1:17:a5:09:a1:a3:a7:1b:b0:5f:73:66:2c:
         39:be:e6:12:a3:6b:f0:c9:c5:a4:6a:4c:e7:f8:45:20:b7:91:
         c5:fc:09:d2:25:76:c2:ce:f7:a7:73:ff:fc:00:41:d1:4f:0e:
         1c:ba:00:54:f9:bc:a4:ce:f0:8b:4f:1c:36:fb:a8:53:aa:16:
         aa:5e:26:2e:57:37:5c:a8:64:64:c1:d5:e8:b4:9a:00:f7:c4:
         16:8a:6e:9e:94:c8:23:99:25:22:05:a2:6b:7b:a6:24:f8:19:
         c8:16:54:72:d4:9a:9c:87:0c:37:a8:74:d8:58:3e:b3:74:8d:
         fd:a6:af:e1:02:77:d7:d0:25:87:73:d6:a9:b4:5f:1f:90:35:
         b2:97:0e:23:d1:98:f5:f4:a9:59:5e:09:94:9e:4a:9d:49:02:
         65:38:1a:80:8e:fb:de:aa:41:4a:63:82:59:7e:eb:15:b2:6b:
         75:0d:8f:ad:5f:f6:c8:74:67:3a:fb:e6:e8:36:2d:9a:39:b8:
         13:3f:2e:93:51:d4:ad:d3:2f:13:42:72:0e:ee:50:f4:e7:f6:
         bd:78:dd:de:e2:bc:98:4f:97:7b:44:26:7e:0f:5e:3b:fa:9a:
         52:e8:3a:05

This is why the crl is expired after November 25th 2019
I believe the flags result is MBEDTLS_X509_BADCRL_EXPIRED | MBEDTLS_X509_BADCERT_REVOKED as opposed to MBEDTLS_X509_BADCERT_REVOKED which is the expected flags in the failed tests.

A suggested fix is either to update the crl, or to change the test to check if the expected flag exists using a bitwise & rather than checking if the flags are exactly the same as the expected, assuming this will not entirely change the purpose of the test ( need to think this through).

I haven't tried to reproduce this yet, as it requires to setup a VM, etc.., but I am quite positive this is the root cause for your failure.

I will double confirm once I setup a VM environment. (I prefer not to skew my local machine clock at the moment)

[bmwiedemann]

If setting up a VM is too much effort, maybe libfaketime could also help.
You use it like faketime -f '+1y' date

That CRL indeed looks like the culprit.

[ciarmcom]

ARM Internal Ref: IOTSSL-2734

[RonEld]

@bmwiedemann Thank you for the faketime tip!

Indeed, the reason for failure is the CRL expiration.
Either tests fail because they expect verification to succeed, and in that case, the verification fails, due to expired CRL or, if the tests expect the verification to fail, but compares to a specific flag, and the verification flags have in their bitmask MBEDTLS_X509_BADCRL_EXPIRED

We will look into it.

[RonEld]

I believe that #2417 fixes this issue.