As we accept EE certs that are explicitly trusted (in the list of trusted
roots) and usually look for parent by subject, and in the future we might want
to avoid checking the self-signature on trusted certs, there could a risk that we
incorrectly accept a cert that looks like a trusted root except it doesn't
have the same key. This test ensures this will never happen.
The tests cover chains of length 0, 1 and 2, with one error, located at any of
the available levels in the chain. This exercises all three call sites of
f_vrfy (two in verify_top, one in verify_child). Chains of greater length
would not cover any new code path or behaviour that I can see.
So far there was no test ensuring that the flags passed to the vrfy callback
are correct (ie the flags for the current certificate, not including those of
the parent).
Actual tests case making use of that test function will be added in the next
commit.
md() already checks for md_info == NULL. Also, in the future it might also
return other errors (eg hardware errors if acceleration is used), so it make
more sense to check its return value than to check for NULL ourselves and then
assume no other error can occur.
Also, currently, md_info == NULL can never happen except if the MD and OID modules
get out of sync, or if the user messes with members of the x509_crt structure
directly.
This commit does not change the current behaviour, which is to treat MD errors
the same way as a bad signature or no trusted root.
The fact that self-signed end-entity certs can be explicitly trusted by
putting them in the CA list even if they don't have the CA bit was not
documented though it's intentional, and tested by "Certificate verification #73
(selfsigned trusted without CA bit)" in test_suite_x509parse.data
It is unclear to me whether the restriction that explicitly trusted end-entity
certs must be self-signed is a good one. However, it seems intentional as it is
tested in tests #42 and #43, so I'm not touching it for now.
With cmake, CFLAGS has to be set when invoking cmake, not make (which totally
ignores the value of CFLAGS when it runs and only keeps the one from cmake).
Also, in that case the flags were either redundant (-Werror etc) or wrong
(-std=c99 -pedantic) as some parts of the library will not build with
-pedantic (see the other -pedantic tests, which are correct, for what needs to
be disabled).
This is step 1 of a plan to get rid once and for all of missing depends_on in
the X509 test suite (step 2 will be RSA/ECDSA, and step 0 was curves.pl).
We have code to skip them but didn't have explicit tests ensuring they are
(the corresponding branch was never taken).
While at it, remove extra copy of the chain in server10*.crt, which was
duplicated for no reason.
This shows inconsistencies in how flags are handled when callback fails:
- sometimes the flags set by the callback are transmitted, sometimes not
- when the cert if not trusted, sometimes BADCERT_NOT_TRUSTED is set,
sometimes not
This adds coverage for 9 lines and 9 branches. Now all lines related to
callback failure are covered.
Now all checks related to profile are covered in:
- verify_with_profile()
- verify_child()
- verify_top()
(that's 10 lines that were previously not covered)
Leaving aside profile enforcement in CRLs for now, as the focus is on
preparing to refactor cert verification.
Previously flags was left to whatever value it had before. It's cleaner to
make sure it has a definite value, and all bits set looks like the safest way
for when it went very wrong.
The change in the truncated HMAC extension aligns Mbed TLS with the
standard, but breaks interoperability with previous versions. Indicate
this in the ChangeLog, as well as how to restore the old behavior.
Add mbedTLS.vcxproj to the VS2010 application template so that the next
time we auto-generate the application project files, the
LinkLibraryDependencies for mbedTLS.vcxproj are maintained.
Fixes#1347
Extend the pkparse test suite with the newly created keys
encrypted using PKCS#8 with PKCS#5 v2.0 with PRF being
SHA224, 256, 384 and 512.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
We now have support for the entire SHA family to be used as
PRF in PKCS#5 v2.0, therefore we need to add new keys to test
these new functionalities.
This patch adds the new keys in `tests/data_files` and
commands to generate them in `tests/data_files/Makefile`.
Note that the pkcs8 command in OpenSSL 1.0 called with
the -v2 argument generates keys using PKCS#5 v2.0 with SHA1
as PRF by default.
(This behaviour has changed in OpenSSL 1.1, where the exact same
command instead uses PKCS#5 v2.0 with SHA256)
The new keys are generated by specifying different PRFs with
-v2prf.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Some unit tests for pbkdf2_hmac() have results longer than
99bytes when represented in hexadecimal form.
For this reason extend the result array to accommodate
longer strings.
At the same time make memset() parametric to avoid
bugs in the future.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Test vectors for SHA224,256,384 and 512 have been
generated using Python's hashlib module by the
following oneliner:
import binascii, hashlib
binascii.hexlify(hashlib.pbkdf2_hmac(ALGO, binascii.unhexlify('PASSWORD'), binascii.unhexlify('SALT'), ITER, KEYLEN)))
where ALGO was 'sha224', 'sha256', 'sha384' and 'sha512'
respectively.
Values for PASSWORD, SALT, ITER and KEYLEN were copied from the
existent test vectors for SHA1.
For SHA256 we also have two test vectors coming from RFC7914 Sec 11.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Currently only SHA1 is supported as PRF algorithm for PBKDF2
(PKCS#5 v2.0).
This means that keys encrypted and authenticated using
another algorithm of the SHA family cannot be decrypted.
This deficiency has become particularly incumbent now that
PKIs created with OpenSSL1.1 are encrypting keys using
hmacSHA256 by default (OpenSSL1.0 used PKCS#5 v1.0 by default
and even if v2 was forced, it would still use hmacSHA1).
Enable support for all the digest algorithms of the SHA
family for PKCS#5 v2.0.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
