When determining if a certificate error override is allowed for a host, we
consult nsISiteSecurityService::IsSecureURI to see if the host is HSTS/HPKP.
This API takes an nsIURI, but the calling code only has a hostname as an
nsCString. Calling NS_NewURI works in all situations we will encounter except
when the hostname is an IPv6 address. Since IP addresses are never HSTS/HPKP
anyway, we can skip the NS_NewURI / IsSecureURI calls in those cases as a
workaround.
MozReview-Commit-ID: JXa8cGvqqTA
--HG--
extra : rebase_source : b8dcd2cb4211af230f867ce3954d5333b7a49684
MozReview-Commit-ID: 5bUTLz6mGKC
In general, it is possible to create a new nsNSSShutDownObject after
nsNSSShutDownList::shutdown() had been called. Before this patch, at that point,
isAlreadyShutDown() would incorrectly return false, which could lead to code
calling NSS functions, which would probably lead to a crash (because NSS could
be uninitialized at that point). This change merges
nsNSSShutDownList::shutdown() with evaporateAllNSSResources() into
evaporateAllNSSResourcesAndShutDown() for simplicity and makes it so
isAlreadyShutDown() returns true if called after that point.
--HG--
extra : rebase_source : badab89a9e197f18fcd943f16cc77c6aa6664f0d
Removed the probe in Histogram.json and the code related to it in nsKeygenHandler.cpp
MozReview-Commit-ID: E8lGbx19e2C
--HG--
extra : rebase_source : ef958749e6ad2e2b617fd1efdd09cdd3185bef18
pkixocsp_VerifyEncodedResponse_GetCertTrust has a field trustDomain that
deliberately shadows the field it inherits from so that code doesn't use it by
accident.
MozReview-Commit-ID: 1Y4W6sA7lHD
--HG--
extra : rebase_source : d2d3180e6c65ea49255545216230525b96af010d
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
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
The equivalent base 64 digests for the existing test cases were obtained using:
> python2
> import binascii
> binascii.b2a_base64(binascii.unhexlify(<input hex>))
The large input hash digest was obtained like so:
> python2
> import hashlib
> hashlib.md5(" " * 4100).hexdigest()
The large input HMAC digest was obtained like so:
> python2
> import hashlib
> import hmac
> hmac.new("test", " " * 4100, hashlib.md5).hexdigest()
MozReview-Commit-ID: K0BxZdNemu6
--HG--
extra : rebase_source : e8fc9cb9c6b1d70c9162c6ed9fd49e6945dc57f4
There are several reasons for doing this:
1. Nothing appears to be using MD2 with nsICryptoHMAC.
2. There don't seem to be any test vectors available.
3. Bug 160161 suggests the MD2 case doesn't work anyways.
MozReview-Commit-ID: CW1PX7z09kB
--HG--
extra : rebase_source : de8b7e6f3fe03f5cd9d687fa7d410a2ca041b68e
These IDLs conceptually are PSM APIs, and are implemented in PSM as well.
nsICryptoFIPSInfo.idl is similar but is removed instead because:
1. It's unused even by addons.
2. The only thing it provides is also available through nsIPKCS11ModuleDB.idl.
MozReview-Commit-ID: K8R0wDAhjLq
--HG--
rename : netwerk/base/nsICryptoHMAC.idl => security/manager/ssl/nsICryptoHMAC.idl
rename : netwerk/base/nsICryptoHash.idl => security/manager/ssl/nsICryptoHash.idl
rename : netwerk/base/nsINSSErrorsService.idl => security/manager/ssl/nsINSSErrorsService.idl
extra : rebase_source : 3eca83901e14cea714d402046303790d283cff74
* Remove eslint rules for PSM which are redundant with toolkit/.eslintrc.js
* Fix missing plugins block in mochitest.eslintrc.js
* Disable brace-style checking in mixed-content mochitests which use boilerplate where calls to runTest and afterNavigationTest all use opening brace on newline. I've left this for a follow-up.
* Fix lint errors resulting from new rules defined by toolkit's eslintrc.js
MozReview-Commit-ID: EepCLrzAsdM
--HG--
extra : rebase_source : e74e008403d9cd70703d60cf829af01dbede0353
This change includes the FIDO "App ID" as part of the function used to generate
the wrapping key used in the NSS-based U2F soft token, cryptographically binding
the "Key Handle" to the site that Key Handle is intended for.
This is a breaking change with existing registered U2F keys, but since our soft
token is hidden behind a pref, it does not attempt to be backward-compatible.
- Updated for rbarnes' and qdot's reviews comments. Thanks!
- Made more strict in size restrictions, and added a version field
to help us be this strict.
- Bugfix for an early unprotected buffer use (Thanks again rbarnes!)
- Fix a sneaky memory leak re: CryptoBuffer.ToSECItem
MozReview-Commit-ID: Jf6gNPauT4Y
--HG--
extra : rebase_source : 4ff5898e93e4a0a75576e5e54035a1cb6dd952d7
Instead of initializing DataStorage objects on demand in the content
process, we initialize them at content process startup by getting the
parent to send down the information about the existing DataStorages at
child process startup. After that point, the dynamic change
notifications added in bug 1215723 will take care of keeping the
information in sync.
The only unhandled call updates nsHTTPListener::mHttpResponseContentType, but
nothing actually uses the value of mHttpResponseContentType.
MozReview-Commit-ID: FQXESvoO2ZN
--HG--
extra : rebase_source : 547158311de136054acff2539ea6a8bdbfb8227b
Hiding cipher suites behind fallback to measure the impact of DHE removal. This patch itself will not improve security because MITM can trigger the fallback.
Unlike the previous attempt, this patch will not affect WebRTC because it does not touch default cipher prefs.
MozReview-Commit-ID: 82paUEuPu99
--HG--
extra : rebase_source : dd08b00ca0d618d0e2ac9c79ae8f32610e724dbd
Smart string classes like nsCString are safer to use than raw |char*| strings,
and are typically easier to deal with as well.
MozReview-Commit-ID: 18C293zWrJw
--HG--
extra : rebase_source : 350191d4c3047fb38d18e8c6d9370cd059007861