1. 12 2月, 2016 1 次提交
  2. 11 2月, 2016 2 次提交
  3. 08 2月, 2016 1 次提交
    • M
      Handle SSL_shutdown while in init more appropriately #2 · 64f9f406
      Matt Caswell 提交于
      Previous commit 7bb196a7 attempted to "fix" a problem with the way
      SSL_shutdown() behaved whilst in mid-handshake. The original behaviour had
      SSL_shutdown() return immediately having taken no action if called mid-
      handshake with a return value of 1 (meaning everything was shutdown
      successfully). In fact the shutdown has not been successful.
      
      Commit 7bb196a7 changed that to send a close_notify anyway and then
      return. This seems to be causing some problems for some applications so
      perhaps a better (much simpler) approach is revert to the previous
      behaviour (no attempt at a shutdown), but return -1 (meaning the shutdown
      was not successful).
      
      This also fixes a bug where SSL_shutdown always returns 0 when shutdown
      *very* early in the handshake (i.e. we are still using SSLv23_method).
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      64f9f406
  4. 06 2月, 2016 1 次提交
  5. 27 1月, 2016 1 次提交
    • R
      Remove /* foo.c */ comments · 34980760
      Rich Salz 提交于
      This was done by the following
              find . -name '*.[ch]' | /tmp/pl
      where /tmp/pl is the following three-line script:
              print unless $. == 1 && m@/\* .*\.[ch] \*/@;
              close ARGV if eof; # Close file to reset $.
      
      And then some hand-editing of other files.
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      34980760
  6. 20 1月, 2016 1 次提交
    • M
      Handle SSL_shutdown while in init more appropriately · 7bb196a7
      Matt Caswell 提交于
      Calling SSL_shutdown while in init previously gave a "1" response, meaning
      everything was successfully closed down (even though it wasn't). Better is
      to send our close_notify, but fail when trying to receive one.
      
      The problem with doing a shutdown while in the middle of a handshake is
      that once our close_notify is sent we shouldn't really do anything else
      (including process handshake/CCS messages) until we've received a
      close_notify back from the peer. However the peer might send a CCS before
      acting on our close_notify - so we won't be able to read it because we're
      not acting on CCS messages!
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      7bb196a7
  7. 11 1月, 2016 1 次提交
  8. 08 1月, 2016 1 次提交
    • R
      mem functions cleanup · bbd86bf5
      Rich Salz 提交于
      Only two macros CRYPTO_MDEBUG and CRYPTO_MDEBUG_ABORT to control this.
      If CRYPTO_MDEBUG is not set, #ifdef out the whole debug machinery.
              (Thanks to Jakob Bohm for the suggestion!)
      Make the "change wrapper functions" be the only paradigm.
      Wrote documentation!
      Format the 'set func' functions so their paramlists are legible.
      Format some multi-line comments.
      Remove ability to get/set the "memory debug" functions at runtme.
      Remove MemCheck_* and CRYPTO_malloc_debug_init macros.
      Add CRYPTO_mem_debug(int flag) function.
      Add test/memleaktest.
      Rename CRYPTO_malloc_init to OPENSSL_malloc_init; remove needless calls.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      bbd86bf5
  9. 06 1月, 2016 1 次提交
  10. 02 1月, 2016 1 次提交
    • V
      Protocol version selection and negotiation rewrite · 4fa52141
      Viktor Dukhovni 提交于
      The protocol selection code is now consolidated in a few consecutive
      short functions in a single file and is table driven.  Protocol-specific
      constraints that influence negotiation are moved into the flags
      field of the method structure.  The same protocol version constraints
      are now applied in all code paths.  It is now much easier to add
      new protocol versions without reworking the protocol selection
      logic.
      
      In the presence of "holes" in the list of enabled client protocols
      we no longer select client protocols below the hole based on a
      subset of the constraints and then fail shortly after when it is
      found that these don't meet the remaining constraints (suiteb, FIPS,
      security level, ...).  Ideally, with the new min/max controls users
      will be less likely to create "holes" in the first place.
      Reviewed-by: NKurt Roeckx <kurt@openssl.org>
      4fa52141
  11. 23 12月, 2015 1 次提交
  12. 22 12月, 2015 1 次提交
  13. 09 12月, 2015 1 次提交
  14. 06 12月, 2015 1 次提交
  15. 28 11月, 2015 1 次提交
  16. 21 11月, 2015 3 次提交
  17. 20 11月, 2015 1 次提交
  18. 05 11月, 2015 1 次提交
  19. 30 10月, 2015 9 次提交
  20. 08 10月, 2015 1 次提交
  21. 23 9月, 2015 1 次提交
    • M
      DTLSv1_listen rewrite · e3d0dae7
      Matt Caswell 提交于
      The existing implementation of DTLSv1_listen() is fundamentally flawed. This
      function is used in DTLS solutions to listen for new incoming connections
      from DTLS clients. A client will send an initial ClientHello. The server
      will respond with a HelloVerifyRequest containing a unique cookie. The
      client the responds with a second ClientHello - which this time contains the
      cookie.
      
      Once the cookie has been verified then DTLSv1_listen() returns to user code,
      which is typically expected to continue the handshake with a call to (for
      example) SSL_accept().
      
      Whilst listening for incoming ClientHellos, the underlying BIO is usually in
      an unconnected state. Therefore ClientHellos can come in from *any* peer.
      The arrival of the first ClientHello without the cookie, and the second one
      with it, could be interspersed with other intervening messages from
      different clients.
      
      The whole purpose of this mechanism is as a defence against DoS attacks. The
      idea is to avoid allocating state on the server until the client has
      verified that it is capable of receiving messages at the address it claims
      to come from. However the existing DTLSv1_listen() implementation completely
      fails to do this. It attempts to super-impose itself on the standard state
      machine and reuses all of this code. However the standard state machine
      expects to operate in a stateful manner with a single client, and this can
      cause various problems.
      
      A second more minor issue is that the return codes from this function are
      quite confused, with no distinction made between fatal and non-fatal errors.
      Most user code treats all errors as non-fatal, and simply retries the call
      to DTLSv1_listen().
      
      This commit completely rewrites the implementation of DTLSv1_listen() and
      provides a stand alone implementation that does not rely on the existing
      state machine. It also provides more consistent return codes.
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      e3d0dae7
  22. 12 8月, 2015 2 次提交
  23. 03 8月, 2015 1 次提交
    • M
      Move TLS CCS processing into the state machine · 657da85e
      Matt Caswell 提交于
      The handling of incoming CCS records is a little strange. Since CCS is not
      a handshake message it is handled differently to normal handshake messages.
      Unfortunately whilst technically it is not a handhshake message the reality
      is that it must be processed in accordance with the state of the handshake.
      Currently CCS records are processed entirely within the record layer. In
      order to ensure that it is handled in accordance with the handshake state
      a flag is used to indicate that it is an acceptable time to receive a CCS.
      
      Previously this flag did not exist (see CVE-2014-0224), but the flag should
      only really be considered a workaround for the problem that CCS is not
      visible to the state machine.
      
      Outgoing CCS messages are already handled within the state machine.
      
      This patch makes CCS visible to the TLS state machine. A separate commit
      will handle DTLS.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      657da85e
  24. 02 6月, 2015 1 次提交
  25. 16 5月, 2015 1 次提交
  26. 13 5月, 2015 1 次提交
  27. 09 5月, 2015 1 次提交
  28. 22 4月, 2015 1 次提交
    • E
      Repair EAP-FAST session resumption · 6e3d0153
      Emilia Kasper 提交于
      EAP-FAST session resumption relies on handshake message lookahead
      to determine server intentions. Commits
      980bc1ec
      and
      7b3ba508
      removed the lookahead so broke session resumption.
      
      This change partially reverts the commits and brings the lookahead back
      in reduced capacity for TLS + EAP-FAST only. Since EAP-FAST does not
      support regular session tickets, the lookahead now only checks for a
      Finished message.
      
      Regular handshakes are unaffected by this change.
      Reviewed-by: NDavid Benjamin <davidben@chromium.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      6e3d0153