1. 02 May, 2019 1 commit
  2. 23 Mar, 2019 1 commit
  3. 21 Feb, 2019 1 commit
  4. 20 Feb, 2019 1 commit
    • Martin Thomson's avatar
      Bug 1471126 - Fix return codes from SSL_ForceHandshake and SSL_RecordLayerData, r=ekr · f353fbee
      Martin Thomson authored
      Summary:
      Turns out that there were two errors that made my life using SSL_RecordLayerData hard:
      
      * SSL_ForceHandshake was returning SECFailure/PR_WOULD_BLOCK_ERROR when the record layer was replaced, even when the handshake was complete.  This was being obscured in the tests by the fact that we mark sockets as complete through both the callback and SSL_ForceHandshake.  I didn't change that aspect of the tests because different tests rely on that being the case.  I don't have a good strategy for dealing with that, but I will continue to think on it.
      
      * SSL_RecordLayerData was returning SECFailure/PR_WOULD_BLOCK_ERROR when it succeeded, but the AuthCertificate callback blocked.  The contract for SSL_RecordLayerData is that it returns SECSuccess always.  I had explicitly ignored this error in tests, which was just a mistake.
      
      Reviewers: ekr
      
      Tags: #secure-revision
      
      Bug #: 1471126
      
      Differential Revision: https://phabricator.services.mozilla.com/D20528
      
      --HG--
      extra : rebase_source : a5296d4a0bb93b77e5340b13801ec7eb280c2934
      extra : amend_source : 5bf0d8e33c6509229de467343cdd9fdef5144f52
      f353fbee
  5. 23 Oct, 2018 1 commit
    • Martin Thomson's avatar
      Bug 1471126 - Provide extra information needed to use record layer separation, r=ekr · c88db179
      Martin Thomson authored
      This started as an attempt to remove the cipher spec update callback we use for
      testing.  Using the new, public secrets interface should be better for that.
      
      In doing so, it became apparent that we needed more interfaces to NSS to support
      the use of these secrets.  In particular:
      
      1. We need to know what the KDF hash function is for a given cipher suite.  This
         allows users of the secret to use the right hash function.
      
      2. We need to know what cipher spec was picked when sending 0-RTT.  NSS
         currently doesn't expose that information.  (When receiving 0-RTT you can
         safely assume that the negotiated cipher suite is good to use.)
      
      3. We need to know what epoch NSS is currently using.  Otherwise, we can't be
         sure which epoch to feed it.  Data from a good epoch is saved, whereas data
         from a bad epoch is lost, so applications need to know.
      
      So this patch adds these functions to the appropriate info functions and uses
      that information in tests to remove and re-add protection.
      
      The test changes are considerable.  The main effect of the changes is to rely on
      the new functions for managing secrets, rather than the old interface.  But with
      the changes in the other CLs for this bug, secrets appear before they are used,
      which complicates things considerably.  For that, I've moved more logic into the
      TlsCipherSpec class, which now tracks per-epoch state, like sequence numbers and
      record drops.
      
      Trial decryption (yep) is used to identify the right cipher spec every time when
      decrypting, so tests are no longer tolerant of failures to decrypt.  It's no
      longer possible to have a test enable decryption and pass when decryption fails;
      this is particularly true for some parameterized tests that assumed it was OK to
      enable decryption even for TLS 1.2 and earlier.
      
      --HG--
      extra : rebase_source : 4d5a752d0b9837db2ddee9cef481ed7fb588b62d
      extra : amend_source : 2559f37290e31c70a4591b11f30b84f5640c86e7
      extra : source : 6d5ddd89089058ed7be42a17d92e195a31aec46e
      extra : histedit_source : aa847484ab6b1826d1494052b20f29a2136a3644
      c88db179
  6. 17 Feb, 2019 2 commits