1. 10 11月, 2016 1 次提交
  2. 04 11月, 2016 10 次提交
  3. 02 11月, 2016 3 次提交
  4. 21 9月, 2016 1 次提交
  5. 18 9月, 2016 1 次提交
  6. 24 8月, 2016 1 次提交
  7. 18 8月, 2016 1 次提交
  8. 16 8月, 2016 1 次提交
  9. 05 8月, 2016 1 次提交
  10. 29 7月, 2016 2 次提交
    • M
      Simplify and rename SSL_set_rbio() and SSL_set_wbio() · 65e2d672
      Matt Caswell 提交于
      SSL_set_rbio() and SSL_set_wbio() are new functions in 1.1.0 and really
      should be called SSL_set0_rbio() and SSL_set0_wbio(). The old
      implementation was not consistent with what "set0" means though as there
      were special cases around what happens if the rbio and wbio are the same.
      We were only ever taking one reference on the BIO, and checking everywhere
      whether the rbio and wbio are the same so as not to double free.
      
      A better approach is to rename the functions to SSL_set0_rbio() and
      SSL_set0_wbio(). If an existing BIO is present it is *always* freed
      regardless of whether the rbio and wbio are the same or not. It is
      therefore the callers responsibility to ensure that a reference is taken
      for *each* usage, i.e. one for the rbio and one for the wbio.
      
      The legacy function SSL_set_bio() takes both the rbio and wbio in one go
      and sets them both. We can wrap up the old behaviour in the implementation
      of that function, i.e. previously if the rbio and wbio are the same in the
      call to this function then the caller only needed to ensure one reference
      was passed. This behaviour is retained by internally upping the ref count.
      
      This commit was inspired by BoringSSL commit f715c423224.
      
      RT#4572
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      65e2d672
    • M
      Don't double free the write bio · 8e3854ac
      Matt Caswell 提交于
      When setting the read bio we free up any old existing one. However this can
      lead to a double free if the existing one is the same as the write bio.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      8e3854ac
  11. 20 7月, 2016 2 次提交
    • M
      Never expose ssl->bbio in the public API. · 2e7dc7cd
      Matt Caswell 提交于
      This is adapted from BoringSSL commit 2f87112b963.
      
      This fixes a number of bugs where the existence of bbio was leaked in the
      public API and broke things.
      
      - SSL_get_wbio returned the bbio during the handshake. It must always return
        the BIO the consumer configured. In doing so, some internal accesses of
        SSL_get_wbio should be switched to ssl->wbio since those want to see bbio.
      
      - The logic in SSL_set_rfd, etc. (which I doubt is quite right since
        SSL_set_bio's lifetime is unclear) would get confused once wbio got
        wrapped. Those want to compare to SSL_get_wbio.
      
      - If SSL_set_bio was called mid-handshake, bbio would get disconnected and
        lose state. It forgets to reattach the bbio afterwards. Unfortunately,
        Conscrypt does this a lot. It just never ended up calling it at a point
        where the bbio would cause problems.
      
      - Make more explicit the invariant that any bbio's which exist are always
        attached. Simplify a few things as part of that.
      
      RT#4572
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      2e7dc7cd
    • F
      Fix a few if(, for(, while( inside code. · e8aa8b6c
      FdaSilvaYY 提交于
      Fix some indentation at the same time
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/1292)
      e8aa8b6c
  12. 12 7月, 2016 1 次提交
    • V
      Perform DANE-EE(3) name checks by default · 5ae4ceb9
      Viktor Dukhovni 提交于
      In light of potential UKS (unknown key share) attacks on some
      applications, primarily browsers, despite RFC761, name checks are
      by default applied with DANE-EE(3) TLSA records.  Applications for
      which UKS is not a problem can optionally disable DANE-EE(3) name
      checks via the new SSL_CTX_dane_set_flags() and friends.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      5ae4ceb9
  13. 22 6月, 2016 1 次提交
  14. 11 6月, 2016 1 次提交
  15. 08 6月, 2016 2 次提交
  16. 31 5月, 2016 1 次提交
  17. 20 5月, 2016 1 次提交
    • M
      Simplify SSL BIO buffering logic · 46417569
      Matt Caswell 提交于
      The write BIO for handshake messages is bufferred so that we only write
      out to the network when we have a complete flight. There was some
      complexity in the buffering logic so that we switched buffering on and
      off at various points through out the handshake. The only real reason to
      do this was historically it complicated the state machine when you wanted
      to flush because you had to traverse through the "flush" state (in order
      to cope with NBIO). Where we knew up front that there was only going to
      be one message in the flight we switched off buffering to avoid that.
      
      In the new state machine there is no longer a need for a flush state so
      it is simpler just to have buffering on for the whole handshake. This
      also gives us the added benefit that we can simply call flush after every
      flight even if it only has one message in it. This means that BIO authors
      can implement their own buffering strategies and not have to be aware of
      the state of the SSL object (previously they would have to switch off
      their own buffering during the handshake because they could not rely on
      a flush being received when they really needed to write data out). This
      last point addresses GitHub Issue #322.
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      46417569
  18. 19 5月, 2016 1 次提交
    • V
      When strict SCT fails record verification failure · f75b34c8
      Viktor Dukhovni 提交于
      Since with SSL_VERIFY_NONE, the connection may continue and the
      session may even be cached, we should save some evidence that the
      chain was not sufficiently verified and would have been rejected
      with SSL_VERIFY_PEER.  To that end when a CT callback returs failure
      we set the verify result to X509_V_ERR_NO_VALID_SCTS.
      
      Note: We only run the CT callback in the first place if the verify
      result is still X509_V_OK prior to start of the callback.
      
      RT #4502
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      f75b34c8
  19. 18 5月, 2016 1 次提交
  20. 17 5月, 2016 1 次提交
  21. 16 5月, 2016 3 次提交
  22. 09 5月, 2016 1 次提交
  23. 06 5月, 2016 1 次提交
    • M
      Handle no async jobs in libssl · fc7f190c
      Matt Caswell 提交于
      If the application has limited the size of the async pool using
      ASYNC_init_thread() then we could run out of jobs while trying to start a
      libssl io operation. However libssl was failing to handle this and treating
      it like a fatal error. It should not be fatal...we just need to retry when
      there are jobs available again.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      fc7f190c
  24. 29 4月, 2016 1 次提交