| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
This is based on the patch developed by Leander in D157183, but is a
little more explicit.
Co-Authored-By: Leander Schwarz
Differential Revision: https://phabricator.services.mozilla.com/D176157
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support to mozilla::pkix for certificates signed with
RSA-PSS using one of the following parameters permitted by the CA/Browser
Forum Baseline Requirements 1.8.1:
* SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes
* SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes
* SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes
Differential Revision: https://phabricator.services.mozilla.com/D141539
|
| |
|
|
|
|
|
|
|
|
|
| |
The initial implementation of mozilla::pkix split signature verification into
two steps: digesting the data that had been signed and then verifying that
digest. This separation added complexity that was hidden by the VFY_* APIs.
However, those APIs are in need of improvements. This patch avoids the VFY_*
APIs as well as the additional complexity by removing the separate digest step
and using the PK11_Verify* APIs directly.
Differential Revision: https://phabricator.services.mozilla.com/D138605
|
| |
|
|
|
|
| |
responses r=jschanck,djackson
Differential Revision: https://phabricator.services.mozilla.com/D133706
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D114660
|
| |
|
|
|
|
|
|
|
| |
TestSuite r=bbeurdouche
grep -rl --exclude-dir=google_test INSTANTIATE_TEST_CASE_P gtests | xargs sed -i '' s/INSTANTIATE_TEST_CASE_P/INSTANTIATE_TEST_SUITE_P/g
grep -rl --exclude-dir=google_test SetUpTestCase gtests | xargs sed -i '' s/SetUpTestCase/SetUpTestSuite/g
Differential Revision: https://phabricator.services.mozilla.com/D98818
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
Differential Revision: https://phabricator.services.mozilla.com/D93697
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
present) in CheckRevocation r=jcj
This will allow Firefox to make decisions based on the earliest known time that
a certificate exists (with respect to certificate transparency) that a CA is
unlikely to back-date. In particular, this is essential for CRLite. Note that
if the SCT signature isn't validated, a CA could still make a certificate
appear to have existed for longer than it really has. However, this change is
not an attempt to catch malicious CAs. The aim is to avoid false positives in
CRLite resulting from CAs backdating the notBefore field on certificates they
issue.
Depends on D90595
Differential Revision: https://phabricator.services.mozilla.com/D90596
|
| |
|
|
|
|
|
|
|
|
|
| |
necessary r=jcj
Bug 1593141 added the certificate's notBefore field as an argument to
TrustDomain::CheckRevocation so that Firefox could use it with CRLite.
However, since CAs can backdate that field, we need to use the earliest
embedded SCT timestamp instead.
Differential Revision: https://phabricator.services.mozilla.com/D90595
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
mozilla::pkix::TrustDomain::CheckRevocation r=jcj
This allows TrustDomain implementations to make decisions based on when the
validity period of a certificate began. For instance, if an implementation has
revocation information that is valid and complete as of a particular time, but
a certificate's validity period begins after that time, the implementation may
decide to disregard this revocation information on the basis that the
information it has available cannot possibly apply to that certificate.
Differential Revision: https://phabricator.services.mozilla.com/D51485
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D49184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mozilla::pkix::BackCert r=jcj
According to RFC 5280, the definitions of issuerUniqueID and subjectUniqueID in
TBSCertificate are as follows:
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
where UniqueIdentifier is a BIT STRING.
IMPLICIT tags replace the tag of the underlying type. For these fields, there is
no specified class (just a tag number within the class), and the underlying type
of BIT STRING is "primitive" (i.e. not constructed). Thus, the tags should be of
the form CONTEXT SPECIFIC | [number in class], which comes out to 0x81 and 0x82,
respectively.
When originally implemented, mozilla::pkix incorrectly required that the
CONSTRUCTED bit also be set for these fields. Consequently, the library would
reject any certificate that actually contained these fields. Evidently such
certificates are rare.
Differential Revision: https://phabricator.services.mozilla.com/D49013
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This uses uintptr_t to avoid the worst. It still looks terrible and might trip
static analysis warnings, but the reinterpret_cast should hide that.
This assumes that sizeof(uintptr_t) == sizeof(void*), so I've added an assertion
so that we'll at least fail the test on those systems. (We could use
GTEST_SKIP instead, but we don't have that in the version of gtest that we use.)
Reviewers: keeler
Tags: #secure-revision
Bug #: 1578626
Differential Revision: https://phabricator.services.mozilla.com/D44937
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D41617
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
CID 1444897, 1444896, 1444894, 1444892, 1444891, 1444888, 1444885, 1444881
Not sure how to manage the creation of bugs for these.
Reviewers: jcj
Tags: #secure-revision
Differential Revision: https://phabricator.services.mozilla.com/D29611
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D2721
|
|
|
Differential Revision: https://phabricator.services.mozilla.com/D2719
Differential Revision: https://phabricator.services.mozilla.com/D2720
Differential Revision: https://phabricator.services.mozilla.com/D2861
|
