1. 22 Feb, 2017 1 commit
  2. 21 Feb, 2017 4 commits
  3. 17 Feb, 2017 2 commits
  4. 16 Feb, 2017 1 commit
  5. 15 Feb, 2017 3 commits
  6. 14 Feb, 2017 3 commits
  7. 13 Feb, 2017 2 commits
  8. 09 Feb, 2017 3 commits
  9. 08 Feb, 2017 1 commit
    • Todd Short's avatar
      Fix session ticket and SNI · dbdb9661
      Todd Short authored
      
      
      When session tickets are used, it's possible that SNI might swtich the
      SSL_CTX on an SSL. Normally, this is not a problem, because the
      initial_ctx/session_ctx are used for all session ticket/id processes.
      
      However, when the SNI callback occurs, it's possible that the callback
      may update the options in the SSL from the SSL_CTX, and this could
      cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things
      can happen:
      
      1. The session ticket TLSEXT may not be written when the ticket expected
      flag is set. The state machine transistions to writing the ticket, and
      the client responds with an error as its not expecting a ticket.
      2. When creating the session ticket, if the ticket key cb returns 0
      the crypto/hmac contexts are not initialized, and the code crashes when
      trying to encrypt the session ticket.
      
      To fix 1, if the ticket TLSEXT is not written out, clear the expected
      ticket flag.
      To fix 2, consider a return of 0 from the ticket key cb a recoverable
      error, and write a 0 length ticket and continue. The client-side code
      can explicitly handle this case.
      
      Fix these two cases, and add unit test code to validate ticket behavior.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/1065)
      dbdb9661
  10. 07 Feb, 2017 4 commits
  11. 06 Feb, 2017 1 commit
    • Bernd Edlinger's avatar
      Combined patch for the more or less obvious issues · 748cb9a1
      Bernd Edlinger authored
      Fixed a memory leak in ASN1_digest and ASN1_item_digest.
      
      asn1_template_noexp_d2i call ASN1_item_ex_free(&skfield,...) on error.
      
      Reworked error handling in asn1_item_ex_combine_new:
      - call ASN1_item_ex_free and return the correct error code if ASN1_template_new failed.
      - dont call ASN1_item_ex_free if ASN1_OP_NEW_PRE failed.
      
      Reworked error handing in x509_name_ex_d2i and x509_name_encode.
      
      Fixed error handling in int_ctx_new and EVP_PKEY_CTX_dup.
      
      Fixed a memory leak in def_get_class if lh_EX_CLASS_ITEM_insert fails due to OOM:
      - to figure out if the insertion succeeded, use lh_EX_CLASS_ITEM_retrieve again.
      - on error, p will be NULL, and gen needs to be cleaned up again.
      
      int_free_ex_data needs to have a fallback solution if unable to allocate "storage":
      - if free_func is non-zero this must be called to clean up all memory.
      
      Fixed error handling in pkey_hmac_copy.
      
      Fixed error handling in ssleay_rand_add and ssleay_rand_bytes.
      
      Fixed error handling in ...
      748cb9a1
  12. 05 Feb, 2017 1 commit
  13. 31 Jan, 2017 1 commit
  14. 27 Jan, 2017 1 commit
  15. 26 Jan, 2017 7 commits
  16. 24 Jan, 2017 2 commits
  17. 23 Jan, 2017 1 commit
    • Matt Caswell's avatar
      Fix SSL_VERIFY_CLIENT_ONCE · e203f493
      Matt Caswell authored
      
      
      The flag SSL_VERIFY_CLIENT_ONCE is documented as follows:
      
        B<Server mode:> only request a client certificate on the initial TLS/SSL
        handshake. Do not ask for a client certificate again in case of a
        renegotiation. This flag must be used together with SSL_VERIFY_PEER.
      
        B<Client mode:> ignored
      
      But the implementation actually did nothing. After the server sends its
      ServerKeyExchange message, the code was checking s->session->peer to see if
      it is NULL. If it was set then it did not ask for another client
      certificate. However s->session->peer will only be set in the event of a
      resumption, but a ServerKeyExchange message is only sent in the event of a
      full handshake (i.e. no resumption).
      
      The documentation suggests that the original intention was for this to
      have an effect on renegotiation, and resumption doesn't come into it.
      
      The fix is to properly check for renegotiation, not whether there is already
      a client certificate in the session.
      
      As far as I can tell this has been broken for a *long* time.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/1984)
      e203f493
  18. 20 Jan, 2017 2 commits