1. 14 Feb, 2020 1 commit
  2. 12 Feb, 2020 1 commit
  3. 16 Jan, 2020 1 commit
  4. 14 Jan, 2020 1 commit
  5. 13 Jan, 2020 1 commit
  6. 14 Jan, 2020 1 commit
  7. 06 Jan, 2020 2 commits
  8. 02 Jan, 2020 1 commit
  9. 20 Dec, 2019 1 commit
  10. 18 Dec, 2019 1 commit
  11. 12 Dec, 2019 1 commit
  12. 10 Dec, 2019 1 commit
  13. 11 Dec, 2019 1 commit
  14. 29 Nov, 2019 1 commit
    • Martin Thomson's avatar
      Bug 1600144 - Treat ClientHello with message_seq of 1 as a second ClientHello, r=kjacobs · 330d7efa
      Martin Thomson authored
      The logic that deals with stateless HelloRetryRequest in DTLS
      allows this one-off increment to the message_seq field in case the server was
      operating statelessly.  However, when it does, it should insist on the
      ClientHello carrying a cookie; concretely, it should set the flag that says that
      a HelloRetryRequest was sent, even if it doesn't currently remember that it sent
      one. That is the only way that this condition could be met.
      Differential Revision: https://phabricator.services.mozilla.com/D55210
      extra : rebase_source : 07acedf98f6619e53706a9c3a738a81198178747
      extra : amend_source : fb1f0cd771db8464901a9103f1b6989f94f71a20
  15. 11 Dec, 2019 2 commits
  16. 02 Dec, 2019 2 commits
  17. 09 Nov, 2019 1 commit
    • Dana Keeler's avatar
      bug 1593141 - add validity period beginning argument to... · cab26a43
      Dana Keeler authored
      bug 1593141 - add validity period beginning argument to 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
      extra : moz-landing-system : lando
  18. 12 Nov, 2019 1 commit
  19. 08 Nov, 2019 1 commit
  20. 06 Nov, 2019 2 commits
  21. 05 Nov, 2019 1 commit
  22. 01 Nov, 2019 2 commits
  23. 29 Oct, 2019 2 commits
  24. 28 Oct, 2019 2 commits
    • Martin Thomson's avatar
      Bug 1590970 - Stop using time() for ESNI tests, r=kjacobs · 5db5af3d
      Martin Thomson authored
      The ESNI tests were using time() rather than PR_Now(), so they slipped
      the net when I went looking for bad time functions.  Now they do the right thing
      What we were probably seeing in the intermittents was the case where we set the
      time for most of the SSL functions to PR_Now(), and that was just before a
      second rollover.  Then, when time() was called, it returned t+1 so the ESNI keys
      that were being generated in the ESNI tests were given a notBefore time that was
      in the future relative to the time being given to the TLS stack.  Had the ESNI
      keys generation been given time() - 1 for notBefore, as I have done here, this
      would never have turned up.
      Reviewers: kjacobs
      Tags: #secure-revision
      Bug #: 1590970
      Differential Revision: https://phabricator.services.mozilla.com/D50874
      extra : amend_source : 722fc4c36c48bceb2b5d319c35aa7396f8c05372
    • Kevin Jacobs's avatar
      Bug 1588244 - Store TLS 1.3 peerDelegCred, authKeyBits, and scheme in... · 116b452a
      Kevin Jacobs authored
      Bug 1588244 - Store TLS 1.3 peerDelegCred, authKeyBits, and scheme in SSLPreliminaryChannelInfo. r=mt
      This patch adjusts where we set `authKeyBits` (Et al.) for TLS 1.3, such that `CertVerifier` can check the strength of a delegated credential keypair.
      The corresponding PSM changeset is in D47181.
      Differential Revision: https://phabricator.services.mozilla.com/D47849
      extra : moz-landing-system : lando
  25. 22 Oct, 2019 1 commit
  26. 19 Oct, 2019 1 commit
  27. 17 Oct, 2019 2 commits
  28. 16 Oct, 2019 1 commit
  29. 11 Oct, 2019 1 commit
  30. 15 Oct, 2019 1 commit
    • Dana Keeler's avatar
      bug 1579060 - fix handling of issuerUniqueID and subjectUniqueID in mozilla::pkix::BackCert r=jcj · dde04123
      Dana Keeler authored
      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,
      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
      extra : moz-landing-system : lando
  31. 06 Sep, 2019 1 commit
    • Martin Thomson's avatar
      Bug 1549225 - Up front Signature Scheme validation, r=ueno · 0d386a8a
      Martin Thomson authored
      This patch started as an attempt to ensure that a DSA signature scheme would not
      be advertised if we weren't willing to negotiate versions less than TLS 1.3.
      Then I realized that we didn't do the same for PKCS#1 RSA.
      Then I realized that we were still willing to try to establish connections when
      we had a certificate that we couldn't use.
      Then I realized that ssl3_config_match_init() wasn't being run consistently.  On
      resumption, we only ran it when we were PARANOID.  That's silly because we
      weren't checking policies.
      Then I realized that we were allowing ECDSA certificates to be used when the
      named group in the certificate was disabled.  We weren't enforcing that
      consistently either.  However, I also discovered that the check we have wouldn't
      work without a tweak because in TLS 1.3 the named group is part of the signature
      scheme; the configured named groups are only used prior to TLS 1.3 when
      selecting ECDSA/ECDH certificates.
      So that sounds like a lot of changes but what it boils down to is more robust
      checking of the configuration prior to starting a connection.  As a result, we
      should be offering fewer options that we're unwilling or unable to follow
      through on.  A good number of tests needed tweaking as a result because we were
      relying on getting past the checks in those tests.  No real problems were found
      as a result; this just moves failures that might arise from misconfiguration a
      little earlier in the process.
      Differential Revision: https://phabricator.services.mozilla.com/D45966
      extra : rebase_source : 44632658baf414f035f13493d3f2f0ff5753ae9e
  32. 08 Oct, 2019 1 commit