1. 30 1月, 2017 1 次提交
  2. 25 1月, 2017 1 次提交
  3. 11 1月, 2017 2 次提交
  4. 10 1月, 2017 1 次提交
  5. 12 12月, 2016 1 次提交
  6. 06 12月, 2016 5 次提交
  7. 22 11月, 2016 1 次提交
  8. 04 11月, 2016 9 次提交
  9. 03 11月, 2016 2 次提交
    • M
      Fail if an unrecognised record type is received · 436a2a01
      Matt Caswell 提交于
      TLS1.0 and TLS1.1 say you SHOULD ignore unrecognised record types, but
      TLS 1.2 says you MUST send an unexpected message alert. We swap to the
      TLS 1.2 behaviour for all protocol versions to prevent issues where no
      progress is being made and the peer continually sends unrecognised record
      types, using up resources processing them.
      
      Issue reported by 郭志攀
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      436a2a01
    • M
      Fix read_ahead · a7faa6da
      Matt Caswell 提交于
      The function ssl3_read_n() takes a parameter |clearold| which, if set,
      causes any old data in the read buffer to be forgotten, and any unread data
      to be moved to the start of the buffer. This is supposed to happen when we
      first read the record header.
      
      However, the data move was only taking place if there was not already
      sufficient data in the buffer to satisfy the request. If read_ahead is set
      then the record header could be in the buffer already from when we read the
      preceding record. So with read_ahead we can get into a situation where even
      though |clearold| is set, the data does not get moved to the start of the
      read buffer when we read the record header. This means there is insufficient
      room in the read buffer to consume the rest of the record body, resulting in
      an internal error.
      
      This commit moves the |clearold| processing to earlier in ssl3_read_n()
      to ensure that it always takes place.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      a7faa6da
  10. 28 10月, 2016 1 次提交
    • M
      A zero return from BIO_read()/BIO_write() could be retryable · 4880672a
      Matt Caswell 提交于
      A zero return from BIO_read()/BIO_write() could mean that an IO operation
      is retryable. A zero return from SSL_read()/SSL_write() means that the
      connection has been closed down (either cleanly or not). Therefore we
      should not propagate a zero return value from BIO_read()/BIO_write() back
      up the stack to SSL_read()/SSL_write(). This could result in a retryable
      failure being treated as fatal.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      4880672a
  11. 22 9月, 2016 2 次提交
    • M
      Fix a hang with SSL_peek() · b8d24395
      Matt Caswell 提交于
      If while calling SSL_peek() we read an empty record then we go into an
      infinite loop, continually trying to read data from the empty record and
      never making any progress. This could be exploited by a malicious peer in
      a Denial Of Service attack.
      
      CVE-2016-6305
      
      GitHub Issue #1563
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      b8d24395
    • M
      Don't allow too many consecutive warning alerts · af58be76
      Matt Caswell 提交于
      Certain warning alerts are ignored if they are received. This can mean that
      no progress will be made if one peer continually sends those warning alerts.
      Implement a count so that we abort the connection if we receive too many.
      
      Issue reported by Shi Lei.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      af58be76
  12. 16 9月, 2016 1 次提交
    • M
      Revert "Abort on unrecognised warning alerts" · 3c0c68ae
      Matt Caswell 提交于
      This reverts commit 77a6be4d.
      
      There were some unexpected side effects to this commit, e.g. in SSLv3 a
      warning alert gets sent "no_certificate" if a client does not send a
      Certificate during Client Auth. With the above commit this causes the
      connection to abort, which is incorrect. There may be some other edge cases
      like this so we need to have a rethink on this.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      3c0c68ae
  13. 13 9月, 2016 1 次提交
    • M
      Abort on unrecognised warning alerts · 77a6be4d
      Matt Caswell 提交于
      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: NRich Salz <rsalz@openssl.org>
      77a6be4d
  14. 24 8月, 2016 1 次提交
  15. 18 8月, 2016 1 次提交
  16. 16 8月, 2016 2 次提交
  17. 30 7月, 2016 1 次提交
    • M
      Fix crash as a result of MULTIBLOCK · 58c27c20
      Matt Caswell 提交于
      The MULTIBLOCK code uses a "jumbo" sized write buffer which it allocates
      and then frees later. Pipelining however introduced multiple pipelines. It
      keeps track of how many pipelines are initialised using numwpipes.
      Unfortunately the MULTIBLOCK code was not updating this when in deallocated
      its buffers, leading to a buffer being marked as initialised but set to
      NULL.
      
      RT#4618
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      58c27c20
  18. 20 7月, 2016 1 次提交
  19. 29 6月, 2016 1 次提交
  20. 27 6月, 2016 1 次提交
  21. 08 6月, 2016 3 次提交
  22. 27 5月, 2016 1 次提交