If the top certificate occurs twice in trust_ca (for example) it would
not be good for the second instance to be checked with check_path_cnt
reduced twice!
The following did fail:
Test 1
foo:SOME_CONSTANT:"string"
Test 2
foo:OTHER_CONSTANT:"string"
due to the first string actually including the second "foo" up to (but no
including) the colon.
library/dhm.c: accept (and ignore) optional privateValueLength for
PKCS#3 DH parameters.
PKCS#3 defines the ASN.1 encoding of a DH parameter set like this:
----------------
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER, -- g
privateValueLength INTEGER OPTIONAL }
The fields of type DHParameter have the following meanings:
o prime is the prime p.
o base is the base g.
o privateValueLength is the optional private-value
length l.
----------------
See: ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc
This optional parameter was added in PKCS#3 version 1.4, released
November 1, 1993.
dhm.c currently doesn't cope well with PKCS#3 files that have this
optional final parameter included. i see errors like:
------------
dhm_parse_dhmfile returned -0x33E6
Last error was: -0x33E6 - DHM - The ASN.1 data is not formatted correctly : ASN1 - Actual length differs from expected lengt
------------
You can generate PKCS#3 files with this final parameter with recent
versions of certtool from GnuTLS:
certtool --generate-dh-params > dh.pem
The race was due to mpi_exp_mod storing a Montgomery coefficient in the
context (RM, RP, RQ).
The fix was verified with -fsanitize-thread using ssl_pthread_server and two
concurrent clients.
A more fine-grained fix should be possible, locking just enough time to check
if those values are OK and set them if not, rather than locking for the whole
mpi_exp_mod() operation, but it will be for later.
