1. 05 4月, 2016 2 次提交
  2. 30 3月, 2016 1 次提交
  3. 28 3月, 2016 1 次提交
  4. 22 3月, 2016 2 次提交
  5. 21 3月, 2016 1 次提交
  6. 18 3月, 2016 1 次提交
  7. 17 3月, 2016 1 次提交
  8. 11 3月, 2016 1 次提交
  9. 10 3月, 2016 4 次提交
  10. 09 3月, 2016 1 次提交
  11. 08 3月, 2016 5 次提交
    • T
      Add cipher query functions · 3ec13237
      Todd Short 提交于
      Add functions to determine authentication, key-exchange, FIPS and AEAD.
      Reviewed-by: NEmilia Käsper <emilia@openssl.org>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      3ec13237
    • T
      GH787: Fix ALPN · 817cd0d5
      Todd Short 提交于
      * Perform ALPN after the SNI callback; the SSL_CTX may change due to
        that processing
      * Add flags to indicate that we actually sent ALPN, to properly error
        out if unexpectedly received.
      * clean up ssl3_free() no need to explicitly clear when doing memset
      * document ALPN functions
      Signed-off-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NEmilia Käsper <emilia@openssl.org>
      817cd0d5
    • 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
      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
  12. 04 3月, 2016 1 次提交
  13. 03 3月, 2016 2 次提交
    • E
      Refactor ClientHello extension parsing · 06217867
      Emilia Kasper 提交于
      1) Simplify code with better PACKET methods.
      
      2) Make broken SNI parsing explicit. SNI was intended to be extensible
      to new name types but RFC 4366 defined the syntax inextensibly, and
      OpenSSL has never parsed SNI in a way that would allow adding a new name
      type. RFC 6066 fixed the definition but due to broken implementations
      being widespread, it appears impossible to ever extend SNI.
      
      3) Annotate resumption behaviour. OpenSSL doesn't currently handle all
      extensions correctly upon resumption. Annotate for further clean-up.
      
      4) Send an alert on ALPN protocol mismatch.
      Reviewed-by: NKurt Roeckx <kurt@openssl.org>
      06217867
    • C
      Provide getters for default_passwd_cb and userdata · 0c452abc
      Christian Heimes 提交于
      This patch provides getters for default_passwd_cb and userdata for SSL
      and SSL_CTX. The getter functions are required to port Python's ssl module
      to OpenSSL 1.1.0.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      0c452abc
  14. 29 2月, 2016 2 次提交
    • M
      Refactor the async wait fd logic · ff75a257
      Matt Caswell 提交于
      Implementation experience has shown that the original plan for async wait
      fds was too simplistic. Originally the async logic created a pipe internally
      and user/engine code could then get access to it via API calls. It is more
      flexible if the engine is able to create its own fd and provide it to the
      async code.
      
      Another issue is that there can be a lot of churn in the fd value within
      the context of (say) a single SSL connection leading to continually adding
      and removing fds from (say) epoll. It is better if we can provide some
      stability of the fd value across a whole SSL connection. This is
      problematic because an engine has no concept of an SSL connection.
      
      This commit refactors things to introduce an ASYNC_WAIT_CTX which acts as a
      proxy for an SSL connection down at the engine layer.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      ff75a257
    • M
      Workaround for VisualStudio 2015 bug · b32166b4
      Matt Caswell 提交于
      VisualStudio 2015 has a bug where an internal compiler error was occurring.
      By reordering the DEFINE_STACK_OF declarations for SSL_CIPHER and SSL_COMP
      until after the ssl3.h include everything seems ok again.
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      b32166b4
  15. 25 2月, 2016 1 次提交
  16. 20 2月, 2016 1 次提交
    • E
      TLS: reject duplicate extensions · aa474d1f
      Emilia Kasper 提交于
      Adapted from BoringSSL. Added a test.
      
      The extension parsing code is already attempting to already handle this for
      some individual extensions, but it is doing so inconsistently. Duplicate
      efforts in individual extension parsing will be cleaned up in a follow-up.
      Reviewed-by: NStephen Henson <steve@openssl.org>
      aa474d1f
  17. 13 2月, 2016 1 次提交
  18. 12 2月, 2016 1 次提交
  19. 11 2月, 2016 3 次提交
  20. 10 2月, 2016 1 次提交
  21. 09 2月, 2016 3 次提交
  22. 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
  23. 07 2月, 2016 1 次提交
  24. 06 2月, 2016 1 次提交
  25. 01 2月, 2016 1 次提交