2020-10-26 Robert Relyea <rrelyea@redhat.com>
* lib/libpkix/pkix_pl_nss/pki/pkix_pl_ocspresponse.c,
tests/ssl/ssl.sh:
Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs
when SHA1 signatures are disabled. r=mt
When libpkix is checking an OCSP cert, it can't use the passed in
set of trust anchors as a base because only the single root that
signed the leaf can sign the OCSP request. As a result it actually
checks the signature of the self-signed root when processing an OCSP
request. This fails of the root cert signature is invalid for any
reason (including it's a sha1 self-signed root cert and we've
disabled sha1 signatures (say, by policy)).
Further investigation indicates the difference between our classic
code and the current code is the classic code only checks OCSP
responses on leaf certs. In the real world, those responses are
signed by intermediate certificates (who won't have sha1 signed
certificates anymore), so our signature processing works just fine.
pkix checks OCSP on the intermediate certificates as well, which are
signed by the root cert. In this case the root cert is a chain of 1,
and is effectively a leaf. This patch updates the OCSP response code
to not check the signatures on the single cert if that cert is a
selfsigned root cert. This requires bug 391476 so we still do the
other validation checking on the certs (making sure it's trusted as
a CA).
[035110dfa0b9] [tip]
2020-10-23 Robert Relyea <rrelyea@redhat.com>
* lib/certhigh/certvfypkix.c,
lib/libpkix/pkix_pl_nss/module/pkix_pl_nsscontext.c,
lib/libpkix/pkix_pl_nss/module/pkix_pl_nsscontext.h,
lib/libpkix/pkix_pl_nss/pki/pkix_pl_cert.c,
lib/libpkix/pkix_pl_nss/pki/pkix_pl_ocspresponse.c,
tests/ssl/ssl.sh:
Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs
when SHA1 signatures are disabled.
When libpkix is checking an OCSP cert, it can't use the passed in
set of trust anchors as a base because only the single root that
signed the leaf can sign the OCSP request. As a result it actually
checks the signature of the self-signed root when processing an OCSP
request. This fails of the root cert signature is invalid for any
reason (including it's a sha1 self-signed root cert and we've
disabled sha1 signatures (say, by policy)).
Further investigation indicates the difference between our classic
code and the current code is the classic code only checks OCSP
responses on leaf certs. In the real world, those responses are
signed by intermediate certificates (who won't have sha1 signed
certificates anymore), so our signature processing works just fine.
pkix checks OCSP on the intermediate certificates as well, which are
signed by the root cert. In this case the root cert is a chain of 1,
and is effectively a leaf. This patch updates the OCSP response code
to not check the signatures on the single cert if that cert is a
selfsigned root cert. This requires bug 391476 so we still do the
other validation checking on the certs (making sure it's trusted as
a CA).
[97f69f7a89a1]
2020-10-26 Kevin Jacobs <kjacobs@mozilla.com>
* gtests/ssl_gtest/tls_filter.cc:
Bug 1644209 - Fix broken SelectedCipherSuiteReplacer filter. r=mt
This patch corrects the `SelectedCipherSuiteReplacer`filter to
always parse the `session_id` variable (`legacy_session_id` for TLS
1.3+). The previous code attempted to skip it in 1.3+ but did not
account for DTLS wire versions, resulting in intermittent failures.
[a79d14b06b4a]
2020-10-26 Daiki Ueno <dueno@redhat.com>
* gtests/ssl_gtest/ssl_tls13compat_unittest.cc, lib/ssl/ssl3con.c,
lib/ssl/sslimpl.h:
Bug 1672703, always tolerate the first CCS in TLS 1.3, r=mt
Summary: This flips the meaning of the flag for checking excessive
CCS messages, so it only rejects multiple CCS messages while the
first CCS message is always accepted.
Reviewers: mt
Reviewed By: mt
Bug #: 1672703
[b03a4fc5b902]
2020-10-23 Robert Relyea <rrelyea@redhat.com>
* automation/abi-check/expected-report-libnssutil3.so.txt,
gtests/mozpkix_gtest/pkixcert_signature_algorithm_tests.cpp,
lib/nss/nss.h, lib/ssl/ssl3con.c, lib/util/SECerrs.h,
lib/util/nssutil.def, lib/util/secerr.h, tests/policy/policy.sh:
Bug 1670835 Crypto Policy Support needs to be updated with
disable/enable support
Policy update
Current state of the nss policy system:
The initial policy patch focused on getting policy working well in
handling ssl. The policy infrastructure used two existing NSS
infrastructure: 1) Algorithm policies tied the OIDS and 2) the ssl
policy constraints first created to handle export policy
restrictions. To make loadable policies work, we added a couple of
new things: 1) a policy parser to the secmod infrastructure which
allows us to set algorithm policies based on a config file. This
file had two sections: disallow= and allow=. Disallow turned off
policy bits, and allow turned them on. Disallow was always parsed
first, so you could very strictly control your policy map by saying
disallow=all allow={exclusive list of allowed algorithms} 2) a new
NSS_Option() value that allowed the policy parser to set integer
values (like minimum tls version) based on the data in the policy
parser. 3) SSL code which is run at ssl_init time that reads the
algorithm policies and maps the results to SSL policies.
The resulting loaded policy code, in general, sets the boundaries of
what it possible, actually enable/disable of ssl cipher suites are
still under program control, and the builtin NSS default values. The
only consession to configuration is if a cipher is disallowed by
policy, it is also disabled. Allowing a cipher suite by policy that
wasn't already enabled, however, doesn't enable that policy by
default. Inside the policy restrictions, applications can still make
their own decisions on configuration and preference.
At the time the policy system was designed, there were 3 additional
features, which were designed, but not specified: disable, enable,
and lock.
disable and enable work just like disallow and allow, except the
specify what the default settings are. This would allow the policy
file to change the underlying default in the case where the
application doesn't try to configure ssl on it's own.
lock would make either the policy or configuration 'locked' meaning
once the lock has been executed, no further changes to those
configurations would be allowed.
What is needed:
We have a need for the following additional features:
1) we want to turn more of the sha-1 hash function off by default.
We still need sha-1 digest because it's used in many non-secure
cases, but we do want to disable more sha-1 signature usage.
Currently only CERT-SIGNATURE and various hmac usages in SSL ciphers
can be controlled by policy. We want to disallow a greater range of
signature (that is signature use in general).
2) we want to disable more ciphers by default, but need a way to
have certain policies (like LEGACY) turn them back on, so that our
shipped system is more secure by default.
What this patch provides:
1) A new policy flag NSS_USE_ALG_IN_ANY_SIGNATURE was added. The
cryptohi code which exports the NSS sign/verify high level code now
checks the hash and signing algorithm against this new policy flag
and fails if the policy isn't available. New key words were added to
the policy parser for 'all-signature', which implies all signature
flags at once, and 'signature', which maps to NSS_USE_ANY_SIGNATURE.
NOTE: disable=all/signature and disable=all/all-signature are
effective equivalent because cert-signatures eventually call the low
level signature functions, but disable=all allow=rsa-pss/all-
signature and disable=all allow=rsa-pss/signature are different in
that the latter allows all rsa-pss signature and the latter allows
rsa-pss signatures, but no on certificates (or on smime in the
future) Also new keywords were added for rsa-pkcs, rsa-pss, and
ecdsa for signature algorithms (along with dsa).
2) This patch implements disable and enable. These functions only
work on SSL configuration. In the future SMIME/CMS configuration
could also be added. Because the policy system is parsed and handled
by NSS, and SSL configuration is handled in SSL, we use the same
Apply code we used to apply ssl policy to set the inital
configuration. The configured enable/disable state is configured in
the ALGORTHIM policy system, where one bit says the enable/disable
value is active and another bit which gives it's state.
3) two locks have been implented, policy-lock and ssl-lock. These
are specified in the parser as flags (flags=policy-lock,ssl-lock).
The policy locks all the policy changes: ssl_policy, algorithm
policy, and options. It is implemented by two new exported
functions: NSS_IsPolicyLocked() and NSS_LockPolicy(). The first
allows applications to test if the policy is locked without having
to try changing the policy. The various policy set functions check
the NSS_IsPolicyLocked() function and returns SEC_ERROR_POLICY_LOCK
if it's true. The ssl-lock changes the state of the policy to
locked, and the state cannot be changed back without shutting down
NSS. The second is implemented by setting a new Option called
NSS_DEFAULT_LOCKS and the NSS_DEFAULT_SSL_LOCK flag. The idea is we
can add an SMIME lock in the future. SSL checks the
NSS_DEFAULT_SSL_LOCK flag before trying to set the cipher suite
value, and blocks the change if it's set.
4) sslpolicy tests were updated to test the enable, disable, flags
=policy-lock, flags=ssl-lock and the new signature primitives.
5) policy tests were updated to be able to run standalone (like all
the other all.sh tests), as well as new tests to detect when no
signing algorithms have been enabled.
What is not in the patch
1) S/MIME signature policy has been defined for a while, but never
hooked up. 2) S/MIME export policy needs to be connected back to the
algorithm policy system just like the ssl cipher suites already are.
3) S/MIME default configuration needs to be connected back to the
policy system. 4) ECC Curve policy needs to be hooked up with the
signature policy (probably should create a generic 'key meets
policy' function and have every call it).
[6f79a7695812]
* automation/abi-check/expected-report-libnss3.so.txt,
gtests/pk11_gtest/pk11_rsaoaep_unittest.cc, lib/nss/nss.def,
lib/pk11wrap/pk11pub.h, lib/pk11wrap/pk11skey.c:
Bug 1666891 - Add PK11_Pub{Wrap,Unwrap}SymKeyWithMechanism
r=mt,rrelyea
Summary
This is useful for RSA-OAEP support.
The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
be present for PKCS#11 calls. This provides required context for
OAEP. However, PK11_PubWrapSymKey lacks a way of providing this
context and historically silently converted CKM_RSA_PKCS_OAEP to
CKM_RSA_PKCS when a RSA key is provided. Introducing a new call will
let us indicate parameters and potentially support other mechanisms
in the future. This call mirrors the earlier calls introduced for
RSA-PSS: PK11_SignWithMechanism and PK11_VerifyWithMechanism.
The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
be present for PKCS#11 calls. This provides required context for
OAEP. However, PK11_PubUnwrapSymKey lacks a way of providing this
context, and additionally lacked a way of indicating which mechanism
type to use for the unwrap operation (instead detecting it by key
type). Introducing a new call will let us indicate parameters and
potentially support other mechanisms in the future.
Signed-off-by: Alexander Scheel <ascheel@redhat.com>
[33f920fcd175]
2020-10-23 Petr Sumbera <petr.sumbera@oracle.com>
* coreconf/config.gypi:
Bug 1667989 - coreconf/config.gypi should allow correct linking on
Solaris r=kjacobs,bbeurdouche
[e3bd9c2f9259]
2020-10-23 Kevin Jacobs <kjacobs@mozilla.com>
* automation/abi-check/expected-report-libnss3.so.txt,
gtests/pk11_gtest/pk11_find_certs_unittest.cc, lib/nss/nss.def:
Bug 1668123 - Export CERT_AddCertToListHeadWithData and
CERT_AddCertToListTailWithData. r=jcj
[0f15b05daeed]
2020-07-30 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/ckfw/builtins/certdata.txt:
Bug 1634584 - Set CKA_NSS_SERVER_DISTRUST_AFTER for Trustis FPS Root
CA. r=kjacobs
[7076e78ddafe]
2020-10-14 J.C. Jones <jjones@mozilla.com>
* lib/util/secasn1d.c:
Bug 1663091 - Remove unnecessary assertions in the streaming ASN.1
decoder r=kjacobs
The streaming ASN.1 decoder had assertions that, on debug builds,
blocked embedding indefinite-length fields inside of definite-length
fields/contexts, however that behavior does work correctly, and is
valid ASN.1: it tends to happen when wrapping a signature around
existing ASN.1-encoded data, if that already-encoded data had an
indefinite length.
Really these two assertion were just overzealous. The conditional
after the asserts handle the case well, and memory sanitizers have
not found issue here either.
[d0153cc0c464]
Differential Revision: https://phabricator.services.mozilla.com/D95093
b838f38de2