1. 27 6月, 2018 3 次提交
  2. 23 5月, 2018 2 次提交
  3. 22 5月, 2018 1 次提交
  4. 21 5月, 2018 1 次提交
    • M
      Don't cache stateless tickets in TLSv1.3 · ee94ec2e
      Matt Caswell 提交于
      In TLSv1.2 and below we always cache new sessions by default on the server
      side in the internal cache (even when we're using session tickets). This is
      in order to support resumption from a session id.
      
      In TLSv1.3 there is no session id. It is only possible to resume using the
      ticket. Therefore, in the default case,  there is no point in caching the
      session in the internal store.
      
      There is still a reason to call the external cache new session callback
      because applications may be using the callbacks just to know about when
      sessions are created (and not necessarily implementing a full cache). If
      the application also implements the remove session callback then we are
      forced to also store it in the internal cache so that we can create
      timeout events. Otherwise the external cache could just fill up
      indefinitely.
      
      This mostly addresses the issue described in #5628. That issue also proposes
      having an option to not create full stateless tickets when using the
      internal cache. That aspect hasn't been addressed yet.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/6293)
      ee94ec2e
  5. 17 5月, 2018 2 次提交
  6. 15 5月, 2018 1 次提交
  7. 11 5月, 2018 6 次提交
  8. 10 5月, 2018 1 次提交
  9. 03 5月, 2018 1 次提交
  10. 20 4月, 2018 2 次提交
  11. 19 4月, 2018 1 次提交
  12. 18 4月, 2018 5 次提交
  13. 17 4月, 2018 1 次提交
  14. 13 4月, 2018 1 次提交
  15. 04 4月, 2018 1 次提交
  16. 20 3月, 2018 1 次提交
  17. 19 3月, 2018 3 次提交
  18. 15 3月, 2018 1 次提交
  19. 14 3月, 2018 1 次提交
    • M
      Split configuration of TLSv1.3 ciphers from older ciphers · f865b081
      Matt Caswell 提交于
      With the current mechanism, old cipher strings that used to work in 1.1.0,
      may inadvertently disable all TLSv1.3 ciphersuites causing connections to
      fail. This is confusing for users.
      
      In reality TLSv1.3 are quite different to older ciphers. They are much
      simpler and there are only a small number of them so, arguably, they don't
      need the same level of control that the older ciphers have.
      
      This change splits the configuration of TLSv1.3 ciphers from older ones.
      By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable
      them through your existing config.
      
      Fixes #5359
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5392)
      f865b081
  20. 13 3月, 2018 1 次提交
  21. 09 3月, 2018 2 次提交
  22. 01 3月, 2018 1 次提交
    • B
      Do not set a nonzero default max_early_data · c39e4048
      Benjamin Kaduk 提交于
      When early data support was first added, this seemed like a good
      idea, as it would allow applications to just add SSL_read_early_data()
      calls as needed and have things "Just Work".  However, for applications
      that do not use TLS 1.3 early data, there is a negative side effect.
      Having a nonzero max_early_data in a SSL_CTX (and thus, SSL objects
      derived from it) means that when generating a session ticket,
      tls_construct_stoc_early_data() will indicate to the client that
      the server supports early data.  This is true, in that the implementation
      of TLS 1.3 (i.e., OpenSSL) does support early data, but does not
      necessarily indicate that the server application supports early data,
      when the default value is nonzero.  In this case a well-intentioned
      client would send early data along with its resumption attempt, which
      would then be ignored by the server application, a waste of network
      bandwidth.
      
      Since, in order to successfully use TLS 1.3 early data, the application
      must introduce calls to SSL_read_early_data(), it is not much additional
      burden to require that the application also calls
      SSL_{CTX_,}set_max_early_data() in order to enable the feature; doing
      so closes this scenario where early data packets would be sent on
      the wire but ignored.
      
      Update SSL_read_early_data.pod accordingly, and make s_server and
      our test programs into applications that are compliant with the new
      requirements on applications that use early data.
      
      Fixes #4725
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5483)
      c39e4048
  23. 27 2月, 2018 1 次提交