You need to sign in or sign up before continuing.
  1. 24 11月, 2015 1 次提交
  2. 06 11月, 2015 2 次提交
  3. 30 10月, 2015 13 次提交
  4. 12 8月, 2015 1 次提交
  5. 03 8月, 2015 2 次提交
    • M
      Move DTLS CCS processing into the state machine · c69f2adf
      Matt Caswell 提交于
      Continuing on from the previous commit this moves the processing of DTLS
      CCS messages out of the record layer and into the state machine.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      c69f2adf
    • 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
  6. 16 5月, 2015 2 次提交
    • M
      Updates following review comments · d45ba43d
      Matt Caswell 提交于
      Miscellaneous updates following review comments on the version negotiation
      rewrite patches.
      Reviewed-by: NKurt Roeckx <kurt@openssl.org>
      d45ba43d
    • M
      Server side version negotiation rewrite · 32ec4153
      Matt Caswell 提交于
      This commit changes the way that we do server side protocol version
      negotiation. Previously we had a whole set of code that had an "up front"
      state machine dedicated to the negotiating the protocol version. This adds
      significant complexity to the state machine. Historically the justification
      for doing this was the support of SSLv2 which works quite differently to
      SSLv3+. However, we have now removed support for SSLv2 so there is little
      reason to maintain this complexity.
      
      The one slight difficulty is that, although we no longer support SSLv2, we
      do still support an SSLv3+ ClientHello in an SSLv2 backward compatible
      ClientHello format. This is generally only used by legacy clients. This
      commit adds support within the SSLv3 code for these legacy format
      ClientHellos.
      
      Server side version negotiation now works in much the same was as DTLS,
      i.e. we introduce the concept of TLS_ANY_VERSION. If s->version is set to
      that then when a ClientHello is received it will work out the most
      appropriate version to respond with. Also, SSLv23_method and
      SSLv23_server_method have been replaced with TLS_method and
      TLS_server_method respectively. The old SSLv23* names still exist as
      macros pointing at the new name, although they are deprecated.
      
      Subsequent commits will look at client side version negotiation, as well of
      removal of the old s23* code.
      Reviewed-by: NKurt Roeckx <kurt@openssl.org>
      32ec4153
  7. 01 5月, 2015 1 次提交
  8. 17 4月, 2015 1 次提交
  9. 26 3月, 2015 4 次提交
  10. 23 3月, 2015 1 次提交
  11. 28 1月, 2015 1 次提交
  12. 22 1月, 2015 2 次提交
  13. 13 1月, 2015 1 次提交
  14. 06 1月, 2015 1 次提交
  15. 03 1月, 2015 1 次提交
  16. 31 12月, 2014 1 次提交
  17. 29 11月, 2014 1 次提交
  18. 28 3月, 2014 1 次提交
    • D
      Security framework. · b362ccab
      Dr. Stephen Henson 提交于
      Security callback: selects which parameters are permitted including
      sensible defaults based on bits of security.
      
      The "parameters" which can be selected include: ciphersuites,
      curves, key sizes, certificate signature algorithms, supported
      signature algorithms, DH parameters, SSL/TLS version, session tickets
      and compression.
      
      In some cases prohibiting the use of a parameters will mean they are
      not advertised to the peer: for example cipher suites and ECC curves.
      In other cases it will abort the handshake: e.g DH parameters or the
      peer key size.
      
      Documentation to follow...
      b362ccab
  19. 07 1月, 2014 1 次提交
  20. 18 12月, 2013 1 次提交
  21. 18 3月, 2013 1 次提交
    • D
      DTLS revision. · 173e72e6
      Dr. Stephen Henson 提交于
      Revise DTLS code. There was a *lot* of code duplication in the
      DTLS code that generates records. This makes it harder to maintain and
      sometimes a TLS update is omitted by accident from the DTLS code.
      
      Specifically almost all of the record generation functions have code like
      this:
      
      some_pointer = buffer + HANDSHAKE_HEADER_LENGTH;
      ... Record creation stuff ...
      set_handshake_header(ssl, SSL_MT_SOMETHING, message_len);
      
      ...
      
      write_handshake_message(ssl);
      
      Where the "Record creation stuff" is identical between SSL/TLS and DTLS or
      in some cases has very minor differences.
      
      By adding a few fields to SSL3_ENC to include the header length, some flags
      and function pointers for handshake header setting and handshake writing the
      code can cope with both cases.
      
      Note: although this passes "make test" and some simple DTLS tests there may
      be some minor differences in the DTLS code that have to be accounted for.
      173e72e6