1. 08 6月, 2016 3 次提交
  2. 27 5月, 2016 1 次提交
  3. 18 5月, 2016 1 次提交
  4. 02 5月, 2016 2 次提交
  5. 29 4月, 2016 1 次提交
  6. 05 4月, 2016 2 次提交
  7. 01 4月, 2016 1 次提交
  8. 08 3月, 2016 7 次提交
    • M
      Fix building without multiblock support · fa22f98f
      Matt Caswell 提交于
      Not all platforms support multiblock. Building without it fails prior to
      this fix.
      
      RT#4396
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      fa22f98f
    • M
      Remove the wrec record layer field · f482740f
      Matt Caswell 提交于
      We used to use the wrec field in the record layer for keeping track of the
      current record that we are writing out. As part of the pipelining changes
      this has been moved to stack allocated variables to do the same thing,
      therefore the field is no longer needed.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      f482740f
    • M
      Add an SSL_has_pending() function · 49580f25
      Matt Caswell 提交于
      This is similar to SSL_pending() but just returns a 1 if there is data
      pending in the internal OpenSSL buffers or 0 otherwise (as opposed to
      SSL_pending() which returns the number of bytes available). Unlike
      SSL_pending() this will work even if "read_ahead" is set (which is the
      case if you are using read pipelining, or if you are doing DTLS). A 1
      return value means that we have unprocessed data. It does *not* necessarily
      indicate that there will be application data returned from a call to
      SSL_read(). The unprocessed data may not be application data or there
      could be errors when we attempt to parse the records.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      49580f25
    • M
      Add an ability to set the SSL read buffer size · dad78fb1
      Matt Caswell 提交于
      This capability is required for read pipelining. We will only read in as
      many records as will fit in the read buffer (and the network can provide
      in one go). The bigger the buffer the more records we can process in
      parallel.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      dad78fb1
    • M
      Lazily initialise the compression buffer · 0220fee4
      Matt Caswell 提交于
      With read pipelining we use multiple SSL3_RECORD structures for reading.
      There are SSL_MAX_PIPELINES (32) of them defined (typically not all of these
      would be used). Each one has a 16k compression buffer allocated! This
      results in a significant amount of memory being consumed which, most of the
      time, is not needed.  This change swaps the allocation of the compression
      buffer to be lazy so that it is only done immediately before it is actually
      used.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      0220fee4
    • M
      Implement read pipeline support in libssl · 94777c9c
      Matt Caswell 提交于
      Read pipelining is controlled in a slightly different way than with write
      pipelining. While reading we are constrained by the number of records that
      the peer (and the network) can provide to us in one go. The more records
      we can get in one go the more opportunity we have to parallelise the
      processing.
      
      There are two parameters that affect this:
      * The number of pipelines that we are willing to process in one go. This is
      controlled by max_pipelines (as for write pipelining)
      * The size of our read buffer. A subsequent commit will provide an API for
      adjusting the size of the buffer.
      
      Another requirement for this to work is that "read_ahead" must be set. The
      read_ahead parameter will attempt to read as much data into our read buffer
      as the network can provide. Without this set, data is read into the read
      buffer on demand. Setting the max_pipelines parameter to a value greater
      than 1 will automatically also turn read_ahead on.
      
      Finally, the read pipelining as currently implemented will only parallelise
      the processing of application data records. This would only make a
      difference for renegotiation so is unlikely to have a significant impact.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      94777c9c
    • M
      Implement write pipeline support in libssl · d102d9df
      Matt Caswell 提交于
      Use the new pipeline cipher capability to encrypt multiple records being
      written out all in one go. Two new SSL/SSL_CTX parameters can be used to
      control how this works: max_pipelines and split_send_fragment.
      
      max_pipelines defines the maximum number of pipelines that can ever be used
      in one go for a single connection. It must always be less than or equal to
      SSL_MAX_PIPELINES (currently defined to be 32). By default only one
      pipeline will be used (i.e. normal non-parallel operation).
      
      split_send_fragment defines how data is split up into pipelines. The number
      of pipelines used will be determined by the amount of data provided to the
      SSL_write call divided by split_send_fragment. For example if
      split_send_fragment is set to 2000 and max_pipelines is 4 then:
      SSL_write called with 0-2000 bytes == 1 pipeline used
      SSL_write called with 2001-4000 bytes == 2 pipelines used
      SSL_write called with 4001-6000 bytes == 3 pipelines used
      SSL_write_called with 6001+ bytes == 4 pipelines used
      
      split_send_fragment must always be less than or equal to max_send_fragment.
      By default it is set to be equal to max_send_fragment. This will mean that
      the same number of records will always be created as would have been
      created in the non-parallel case, although the data will be apportioned
      differently. In the parallel case data will be spread equally between the
      pipelines.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      d102d9df
  9. 12 2月, 2016 1 次提交
  10. 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
  11. 12 1月, 2016 1 次提交
  12. 06 1月, 2016 1 次提交
  13. 10 11月, 2015 1 次提交
  14. 02 11月, 2015 1 次提交
    • M
      Remove a reachable assert from ssl3_write_bytes · 1c2e5d56
      Matt Caswell 提交于
      A buggy application that call SSL_write with a different length after a
      NBIO event could cause an OPENSSL_assert to be reached. The assert is not
      actually necessary because there was an explicit check a little further
      down that would catch this scenario. Therefore remove the assert an move
      the check a little higher up.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      1c2e5d56
  15. 30 10月, 2015 4 次提交
  16. 06 10月, 2015 1 次提交
  17. 26 8月, 2015 1 次提交
  18. 14 8月, 2015 1 次提交
  19. 03 8月, 2015 2 次提交
    • M
      Fix ssl3_read_bytes handshake fragment bug · e9f6b9a1
      Matt Caswell 提交于
      The move of CCS into the state machine introduced a bug in ssl3_read_bytes.
      The value of |recvd_type| was not being set if we are satisfying the request
      from handshake fragment storage. This can occur, for example, with
      renegotiation and causes the handshake to fail.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      e9f6b9a1
    • 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
  20. 30 7月, 2015 1 次提交
    • M
      Fix write failure handling in DTLS1.2 · 5e8b24db
      Matt Caswell 提交于
      The DTLS code is supposed to drop packets if we try to write them out but
      the underlying BIO write buffers are full. ssl3_write_pending() contains
      an incorrect test for DTLS that controls this. The test only checks for
      DTLS1 so DTLS1.2 does not correctly clear the internal OpenSSL buffer which
      can later cause an assert to be hit. This commit changes the test to cover
      all DTLS versions.
      
      RT#3967
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      5e8b24db
  21. 10 6月, 2015 1 次提交
  22. 22 5月, 2015 1 次提交
    • M
      Fix a memory leak in compression · 6b41b3f5
      Matt Caswell 提交于
      The function RECORD_LAYER_clear() is supposed to clear the contents of the
      RECORD_LAYER structure, but retain certain data such as buffers that are
      allocated. Unfortunately one buffer (for compression) got missed and was
      inadvertently being wiped, thus causing a memory leak.
      
      In part this is due to the fact that RECORD_LAYER_clear() was reaching
      inside SSL3_BUFFERs and SSL3_RECORDs, which it really shouldn't. So, I've
      rewritten it to only clear the data it knows about, and to defer clearing
      of SSL3_RECORD and SSL3_BUFFER structures to SSL_RECORD_clear() and the
      new function SSL3_BUFFER_clear().
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      6b41b3f5
  23. 16 5月, 2015 3 次提交
    • 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
      Client side version negotiation rewrite · 13c9bb3e
      Matt Caswell 提交于
      Continuing from the previous commit this changes the way we do client side
      version negotiation. Similarly all of the s23* "up front" state machine code
      has been avoided and again things now work much the same way as they already
      did for DTLS, i.e. we just do most of the work in the
      ssl3_get_server_hello() function.
      Reviewed-by: NKurt Roeckx <kurt@openssl.org>
      13c9bb3e
    • 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
  24. 06 5月, 2015 1 次提交