Calling VFY_VerifyDigestDirect causes the provided SECKEYPublicKey to be
reimported to the softoken regardless of if it already exists on it. EC keys
must be verified upon import (to see if the point is on the curve to avoid some
small subgroup attacks), and so repeatedly doing this with a static key (say,
for example, a key corresponding to a built-in certificate transparency log) is
inefficient. This patch alters the certificate transparency implementation to
import these keys each once and then use PK11_Verify for ECDSA signature
verification, which doesn't have the same drawback.
Since this change causes CertVerifier to hold an NSS resource (via its
MultiLogCTVerifier having a list of CTLogVerifier, each of which now has a
SECKEYPublicKey), nsNSSComponent has to make sure it goes away before shutting
down NSS. This patch ensures this happens in nsNSSComponent::ShutdownNSS().
MozReview-Commit-ID: 6VSmz7S53y2
--HG--
extra : rebase_source : 4994db9de80a6c1aec3d7e322ff30d040140ce92
The default OCSP timeout for soft-fail DV is still 2 seconds. This patch makes
it configurable on the interval (0, 5] seconds.
The default OCSP timeout for EV and hard-fail DV is still 10 seconds. This patch
makes it configurable on the interval (0, 20] seconds.
MozReview-Commit-ID: CPd8pwYrJhj
--HG--
extra : rebase_source : 45bd7d06ea013f0a776ea18be9408dedb18271d8
(adapted from bug 1349762 comment 0)
Google Trust Services (GTS) recently purchased two roots from GlobalSign that
are both enabled for EV treatment: "GlobalSign Root CA - R2" and "GlobalSign ECC
Root CA - R4".
However, GTS does not have an EV audit, so we are going to turn off EV treatment
for both of those root certificates.
But "GlobalSign Root CA - R2" has intermediate cert "GlobalSign Extended
Validation CA - SHA256 - G2" that continues to be controlled by GlobalSign, to
be used to migrate their customers off dependence on that root.
This patch removes EV treatment for "GlobalSign ECC Root CA - R4". It also
removes EV treatment for all chains rooted in "GlobalSign Root CA - R2" unless
the "GlobalSign Extended Validation CA - SHA256 - G2" intermediate is in the
chain.
MozReview-Commit-ID: Ej9L9zTwoPN
--HG--
extra : rebase_source : 575f1a48646cf728d879d0cf53c888654e4a32ad
The NSS Base64 functions are less safe and convenient to use than the XPCOM ones.
They're also an unnecessary dependency on NSS.
The NSS Base64 functions behave slightly differently than the XPCOM ones:
1. ATOB_ConvertAsciiToItem() / NSSBase64_DecodeBuffer() silently ignore invalid
characters like CRLF, space and so on. Base64Decode() will return an error
if these characters are encountered.
2. BTOA_DataToAscii() will produce output that has CRLF inserted every 64
characters. Base64Encode() doesn't do this.
For the reasons listed below, no unexpected compatibility issues should arise:
1. AppSignatureVerification.cpp already filters out CRLF and spaces for Manifest
and Signature values before decoding.
2. ExtendedValidation.cpp is only given what should be valid hard-coded input to
decode.
3. ContentSignatureVerifier.cpp already splits on CRLF for when it needs to
decode PEM certs. Spaces shouldn't be likely.
For Content-Signature header verification, examination of real input to a
running instance of Firefox suggests CRLF and spaces will not be present in
the header to decode.
4. nsCryptoHash.cpp encode is affected, but we actually don't want the CRLF
behaviour.
5. nsDataSignatureVerifier.cpp decode is affected, but we add whitespace
stripping to maintain backwards compatibility.
6. nsKeygenHandler.cpp encode is affected, but the previous CRLF behaviour was
arguably a bug, since neither WHATWG or W3C specs specified this.
MozReview-Commit-ID: IWMFxqVZMeX
--HG--
extra : rebase_source : 4863b2e5eabef0555e8e1ebe39216d0d9393f3e9
The only unhandled call updates nsHTTPListener::mHttpResponseContentType, but
nothing actually uses the value of mHttpResponseContentType.
MozReview-Commit-ID: FQXESvoO2ZN
--HG--
extra : rebase_source : 547158311de136054acff2539ea6a8bdbfb8227b
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
mozilla::TimeStamp is generally superior to PRIntervalTime, and switching lets
us get rid of yet another NSPR dependency.
This patch also:
1. Gets rid of code in nsNSSHttpRequestSession::createFcn() that limits the
max OCSP timeout. This is a relic from when NSS was used for OCSP requests,
and is no longer necessary.
2. Converts all uses of PR_NOT_REACHED() to MFBT asserts while we're nearby.
MozReview-Commit-ID: KvgOWWhP8Km
--HG--
extra : rebase_source : ea832a1acc4423cf6cfc98862af6b1c29a83ce56
Unfortunately, this doesn't cover delegated OCSP responder certificates. While
gathering telemetry on the use of SHA-1, we encountered bug 1183822 (basically,
that the method of gathering telemetry was causing OCSP verification failures
due to delegated responders signed with SHA-1). As a temporary solution, we
changed the verifier to always allow SHA-1 for OCSP certificates when verifying
an OCSP response. Consequently, we now have no idea what the compatibility
impact of disabling SHA-1 in OCSP responder certificates will be, so it's
probably not a good idea to do that right now.
Even if someone does manage to forge an OCSP responder certificate using a SHA-1
collision, they will have about as much power as an active network attacker
blocking OCSP requests or injecting bad stapled OCSP responses, so this isn't a
disaster.
MozReview-Commit-ID: 10r23W1APiR
--HG--
extra : rebase_source : dc003c4812677c40882506b1b6b1e1f68d7e6e92
PR_ASSERT() is an unnecessary dependency on NSPR.
We can use MOZ_ASSERT() instead, which accomplishes the same task but doesn't
depend on NSPR.
MozReview-Commit-ID: 9gyWUkv3KxQ
--HG--
extra : rebase_source : 313ce6c8de3db3ce72635e37f09d28316ae02c51
(Note that content signature verification does not use the unified certificate
verifier and thus will still consult OneCRL.)
MozReview-Commit-ID: 6KvHOngpabT
--HG--
extra : rebase_source : 601f4d8d1c66befb77d0c07a2d84f3f04416f996
The PR_SetError() + PR_GetError() pattern is error prone and unnecessary.
Also fixes Bug 1254403.
MozReview-Commit-ID: DRI69xY4vxC
--HG--
extra : rebase_source : aa07c0dfb5cc2a203e772b415b7a75b27d9bad3c
Crash reports indicate LoadExtendedValidationInfo is failing. This adds
annotated crashes that should point us at exactly what is failing. (Note that
because Nightly builds aren't built with DEBUG defined, the majority of
LoadExtendedValidationInfo isn't even run, so we can ignore that code.)
--HG--
extra : amend_source : 0940efc65bb706b572f0699ab5c66b82d6591d30
