1. 28 Sep, 2016 1 commit
    • David Woodhouse's avatar
      Call ENGINE_init() before trying to use keys from engine · 4badd2b3
      David Woodhouse authored
      Things like 'openssl s_client' only ever worked with keys from an engine
      which provided a default generic method for some key type — because it
      called ENGINE_set_default() and that ended up being an implicit
      initialisation and functional refcount.
      
      But an engine which doesn't provide generic methods doesn't get
      initialised, and then when you try to use it you get an error:
      
      cannot load client certificate private key file from engine
      140688147056384:error:26096075:engine routines:ENGINE_load_private_key:not initialised:crypto/engine/eng_pkey.c:66:
      unable to load client certificate private key file
      
      cf. https://github.com/OpenSC/libp11/issues/107
      
       (in which we discover
      that engine_pkcs11 *used* to provide generic methods that OpenSSL would
      try to use for ephemeral DH keys when negotiating ECDHE cipher suites in
      TLS, and that didn't work out very well.)
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/1640)
      4badd2b3
  2. 26 Sep, 2016 5 commits
  3. 22 Sep, 2016 9 commits
  4. 21 Sep, 2016 9 commits
  5. 20 Sep, 2016 2 commits
  6. 15 Sep, 2016 11 commits
  7. 14 Sep, 2016 1 commit
    • Matt Caswell's avatar
      Add some sanity checks around usage of t_fromb64() · 68f11e82
      Matt Caswell authored
      
      
      The internal SRP function t_fromb64() converts from base64 to binary. It
      does not validate that the size of the destination is sufficiently large -
      that is up to the callers. In some places there was such a check, but not
      in others.
      
      Add an argument to t_fromb64() to provide the size of the destination
      buffer and validate that we don't write too much data. Also add some sanity
      checks to the callers where appropriate.
      
      With thanks to Shi Lei for reporting this issue.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (cherry picked from commit 73f0df83)
      68f11e82
  8. 13 Sep, 2016 1 commit
    • Matt Caswell's avatar
      Abort on unrecognised warning alerts · 15d81749
      Matt Caswell authored
      
      
      A peer continually sending unrecognised warning alerts could mean that we
      make no progress on a connection. We should abort rather than continuing if
      we receive an unrecognised warning alert.
      
      Thanks to Shi Lei for reporting this issue.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      15d81749
  9. 12 Sep, 2016 1 commit