1. 12 8月, 2015 1 次提交
  2. 11 8月, 2015 1 次提交
  3. 05 8月, 2015 2 次提交
  4. 04 8月, 2015 4 次提交
  5. 03 8月, 2015 6 次提交
    • M
      Fix make errors for the CCS changes · 496dbe18
      Matt Caswell 提交于
      The move of CCS into the state machine was causing make errors to fail. This
      fixes it.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      496dbe18
    • M
      Fix ssl3_read_bytes handshake fragment bug · e9f6b9a1
      Matt Caswell 提交于
      The move of CCS into the state machine introduced a bug in ssl3_read_bytes.
      The value of |recvd_type| was not being set if we are satisfying the request
      from handshake fragment storage. This can occur, for example, with
      renegotiation and causes the handshake to fail.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      e9f6b9a1
    • M
      Move DTLS CCS processing into the state machine · c69f2adf
      Matt Caswell 提交于
      Continuing on from the previous commit this moves the processing of DTLS
      CCS messages out of the record layer and into the state machine.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      c69f2adf
    • M
      Move TLS CCS processing into the state machine · 657da85e
      Matt Caswell 提交于
      The handling of incoming CCS records is a little strange. Since CCS is not
      a handshake message it is handled differently to normal handshake messages.
      Unfortunately whilst technically it is not a handhshake message the reality
      is that it must be processed in accordance with the state of the handshake.
      Currently CCS records are processed entirely within the record layer. In
      order to ensure that it is handled in accordance with the handshake state
      a flag is used to indicate that it is an acceptable time to receive a CCS.
      
      Previously this flag did not exist (see CVE-2014-0224), but the flag should
      only really be considered a workaround for the problem that CCS is not
      visible to the state machine.
      
      Outgoing CCS messages are already handled within the state machine.
      
      This patch makes CCS visible to the TLS state machine. A separate commit
      will handle DTLS.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      657da85e
    • M
      PACKETise ClientHello processing · 9ceb2426
      Matt Caswell 提交于
      Uses the new PACKET code to process the incoming ClientHello including all
      extensions etc.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      9ceb2426
    • M
      Add initial packet parsing code · 7e729bb5
      Matt Caswell 提交于
      Provide more robust (inline) functions to replace n2s, n2l, etc. These
      functions do the same thing as the previous macros, but also keep track
      of the amount of data remaining and return an error if we try to read more
      data than we've got.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      7e729bb5
  6. 02 8月, 2015 1 次提交
  7. 01 8月, 2015 1 次提交
    • M
      Remove erroneous server_random filling · e1e088ec
      Matt Caswell 提交于
      Commit e481f9b9 removed OPENSSL_NO_TLSEXT from the code.
      
      Previously if OPENSSL_NO_TLSEXT *was not* defined then the server random was
      filled during getting of the ClientHello. If it *was* defined then the
      server random would be filled in ssl3_send_server_hello(). Unfortunately in
      commit e481f9b9 the OPENSSL_NO_TLSEXT guards were removed but *both*
      server random fillings were left in. This could cause problems for session
      ticket callbacks.
      Reviewed-by: NStephen Henson <steve@openssl.org>
      e1e088ec
  8. 30 7月, 2015 20 次提交
  9. 28 7月, 2015 1 次提交
  10. 27 7月, 2015 1 次提交
    • M
      Remove support for SSL3_FLAGS_DELAY_CLIENT_FINISHED · 57787ac8
      Matt Caswell 提交于
      This flag was not set anywhere within the codebase (only read). It could
      only be set by an app reaching directly into s->s3->flags and setting it
      directly. However that method became impossible when libssl was opaquified.
      
      Even in 1.0.2/1.0.1 if an app set the flag directly it is only relevant to
      ssl3_connect(), which calls SSL_clear() during initialisation that clears
      any flag settings. Therefore it could take effect if the app set the flag
      after the handshake has started but before it completed. It seems quite
      unlikely that any apps really do this (especially as it is completely
      undocumented).
      
      The purpose of the flag is suppress flushing of the write bio on the client
      side at the end of the handshake after the client has written the Finished
      message whilst resuming a session. This enables the client to send
      application data as part of the same flight as the Finished message.
      
      This flag also controls the setting of a second flag SSL3_FLAGS_POP_BUFFER.
      There is an interesting comment in the code about this second flag in the
      implementation of ssl3_write:
      
      	/* This is an experimental flag that sends the
      	 * last handshake message in the same packet as the first
      	 * use data - used to see if it helps the TCP protocol during
      	 * session-id reuse */
      
      It seems the experiment did not work because as far as I can tell nothing
      is using this code. The above comment has been in the code since SSLeay.
      
      This commit removes support for SSL3_FLAGS_DELAY_CLIENT_FINISHED, as well
      as the associated SSL3_FLAGS_POP_BUFFER.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      57787ac8
  11. 21 7月, 2015 2 次提交