| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
DONTBUILD
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This retains the ability to negotiate draft versions of DTLS 1.3, but uses the
final RFC version for TLS 1.3.
This also refactors the handling of the downgrade sentinel. As we've discovered
- to our dismay - some MitM boxes forward handshake messages when they
shouldn't. This could result in triggering the downgrade sentinel. I've done
two things here:
- The server always sets the sentinel. It reduces the assumed version if it
only supports a draft version though on the basis that the client might
expect the full version.
- The client has a new option SSL_ENABLE_HELLO_DOWNGRADE_CHECK which is disabled
by default. The client will reject a handshake that appears to be a downgrade
only when this is explicitly enabled. The client will allow an apparent
downgrade to TLS 1.2 if it is running a draft version of TLS 1.3.
The allowance for a draft version is now only effective for DTLS 1.3.
Tests for version downgrade have been updated and enabled. These were rotten in
a few ways, but nothing dramatic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: In TLS 1.3, upon receiving a malformed ticket, server doesn't immediately abort the connection, but rejects client's resumption attempt.
Reviewers: ekr
Reviewed By: ekr
Subscribers: mt, ekr, kaie, ueno, rrelyea, HubertKario
Tags: #secure-revision, PHID-PROJ-ffhf7tdvqze7zrdn6dh3
Bug #: 1471967
Differential Revision: https://phabricator.services.mozilla.com/D3620
|
| |
|
|
|
|
|
|
|
| |
This adds nss-cipher as argument to the nss_bogo_shim to support tls-interop ciphersuite tests.
Note that this is different from the cipher argument that bogo uses to avoid test failures (NSS doesn't understand the OpenSSL cipher strings that bogo uses).
Differential Revision: https://phabricator.services.mozilla.com/D2510
|
| |
|
| |
|
| |
|
|
|
|
| |
r=franziskus
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mt, ekr
Reviewed By: mt
Subscribers: mt, ekr, kaie, ueno, rrelyea, HubertKario
Bug #: 1481275
Differential Revision: https://phabricator.services.mozilla.com/D3425
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes the corner cases where incorrect alert is sent (or even no
alert is sent):
- when the client's CertificateVerify is signed with rsa_pss_pss_*,
while the certificate is RSA
- when the client's CertificateVerify is signed with rsa_pss_rsae_*,
while the certificate is RSA-PSS
- when ServerKeyExchange is signed with an inconsistent signature
scheme with the server certificate
Reviewers: mt
Reviewed By: mt
Bug #: 1414931
Differential Revision: https://phabricator.services.mozilla.com/D3321
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D2854
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a couple of issues in signature_algorithms extension handling:
- MAX_SIGNATURE_SCHEMES is out of sync with ssl_IsSupportedSignatureScheme()
- when the extension consists of many bogus/duplicate entries followed by a valid signature scheme, ssl_ParseSignatureSchemes() gives up too early
Reviewers: mt
Reviewed By: mt
Subscribers: HubertKario
Bug #: 1481873
Differential Revision: https://phabricator.services.mozilla.com/D3014
|
| |
|
|
|
|
|
|
|
|
|
| |
declaration, r=emaldona,franziscus
- Explictly cast away the const when calling SetPIN
- Fixes: this error:
- passing argument 7 of ‘fwSession->mdSession->SetPIN’
- discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
|
|
|
|
| |
declaration, r=emaldona,franziscus
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpi_arm.c. r=fkiefer
While bug 1477929 fixed the obvious build failure, it still allowed the
compiler to break things when it inlines the mpi_arm.c functions into
its callers via LTO.
The problem is that all those assembly blocks take a length as input in
a register, and decrement that register. They also update both registers
they're passed in with pointers, via post-indexed offsets on ldr and str.
But the constraints are not explicit about those writes to the
registers, so the compiler may decide to reuse them as if they had their
original value in code following the inlined code. It actually happily
does so, which leads to interesting crashes.
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1346
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D2183
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: franziskus
Bug #: 1476672
Differential Revision: https://phabricator.services.mozilla.com/D2223
|
|
|
|
| |
_SGN_VerifyPKCS1DigestInfo, based on a patch contributed by David Benjamin (davidben@google.com), r=fkiefer
|
|
|
|
| |
getDefaultRSAPublicKeyWrong in rsaperf, r=franziskus
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=fkiefer
libfreebl3.so fails to build on arm with LTO enabled with the following
error:
INFO - <inline asm>:2:9: error: operand must be a register in range [r0, r7]
INFO - cbz r10, 2f
INFO - ^
INFO - LLVM ERROR: Error parsing inline asm
It's not clear from the ARM documentation for CBZ whether that's a
problem with llvm or a limitation of the CBZ instruction, but at least
the version of LLVM we use insists that CBZ is used with a core register
(between r0 and r7, included).
That instruction comes from inline asm blocks, and in normal builds, it
just happens to work because the variable that is passed to CBZ is a
function argument, one of the four first arguments, such that it is
register allocated. The compiler just decides to use that register
directly.
With LTO, the function actually ends up inlined in its caller, and the
register allocated to the variable can end up outside the core register
range.
The GCC documentation for machine-constraints indicates the `l`
constraint exists to limit the possible registers:
"In Thumb State the core registers r0-r7. In ARM state this is an alias
for the r constraint."
(CBZ being only used on thumb)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch allows client applications to specify tokens unambiguously with PKCS #11 URI, instead of token name. It also includes a minor fixes to PKCS #11 URI handling that previously treated the scheme case sensitively.
Reviewers: kaie, rrelyea
Bug #: 1475274
Differential Revision: https://phabricator.services.mozilla.com/D2099
|
|
|
|
| |
when we unload nssckbi r=franziskus,dmajor
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change makes it possible to remove orphaned private key with the `-F` command. Similarly to `-R` (bug 430198), it reads a key ID from `-k`.
Reviewers: kaie
Reviewed By: kaie
Bug #: 291383
Differential Revision: https://phabricator.services.mozilla.com/D2094
|
|
|
|
| |
for errors, r=rrelyea
|
|
|
|
| |
Remove the first two lines of abidiff output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=rrelyea,fkiefer
Summary:
In bug 1413596, we changed SECKEY_GetPrivateKeyType() to return
rsaPssKey, if the private key is restricted to RSA-PSS when importing.
Although the intention of this change was to extend the certutil
output to provide more information about key types, it introduced
inconsistency with the existing code, as SECKEY_GetPublicKeyType()
still returns rsaKey.
This patch partially revert the change and determine the actual
(restricted) key type in a different way, using CERT_GetCertKeyType()
and PK11_GetCertFromPrivateKey().
Reviewers: rrelyea, franziskus
Reviewed By: franziskus
Subscribers: franziskus
Bug #: 1471985
Differential Revision: https://phabricator.services.mozilla.com/D1911
|
| |
|
| |
|