1. 09 12月, 2016 2 次提交
  2. 24 11月, 2016 1 次提交
  3. 23 11月, 2016 2 次提交
    • M
      Ensure the end of first server flight processing is done · 7776a36c
      Matt Caswell 提交于
      There is a set of miscellaneous processing for OCSP, CT etc at the end of
      the ServerDone processing. In TLS1.3 we don't have a ServerDone, so this
      needs to move elsewhere.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      7776a36c
    • M
      Update state machine to be closer to TLS1.3 · 92760c21
      Matt Caswell 提交于
      This is a major overhaul of the TLSv1.3 state machine. Currently it still
      looks like TLSv1.2. This commit changes things around so that it starts
      to look a bit less like TLSv1.2 and bit more like TLSv1.3.
      
      After this commit we have:
      
      ClientHello
      + key_share          ---->
                                 ServerHello
                                 +key_share
                                 {CertificateRequest*}
                                 {Certificate*}
                                 {CertificateStatus*}
                           <---- {Finished}
      {Certificate*}
      {CertificateVerify*}
      {Finished}           ---->
      [ApplicationData]    <---> [Application Data]
      
      Key differences between this intermediate position and the final TLSv1.3
      position are:
      - No EncryptedExtensions message yet
      - No server side CertificateVerify message yet
      - CertificateStatus still exists as a separate message
      - A number of the messages are still in the TLSv1.2 format
      - Still running on the TLSv1.2 record layer
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      92760c21
  4. 10 11月, 2016 8 次提交
  5. 09 11月, 2016 6 次提交
  6. 07 11月, 2016 1 次提交
    • M
      Always ensure that init_msg is initialised for a CCS · c4377574
      Matt Caswell 提交于
      We read it later in grow_init_buf(). If CCS is the first thing received in
      a flight, then it will use the init_msg from the last flight we received. If
      the init_buf has been grown in the meantime then it will point to some
      arbitrary other memory location. This is likely to result in grow_init_buf()
      attempting to grow to some excessively large amount which is likely to
      fail. In practice this should never happen because the only time we receive
      a CCS as the first thing in a flight is in an abbreviated handshake. None
      of the preceding messages from the server flight would be large enough to
      trigger this.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      c4377574
  7. 04 11月, 2016 6 次提交
  8. 02 11月, 2016 1 次提交
  9. 03 10月, 2016 5 次提交
  10. 22 9月, 2016 1 次提交
    • M
      Excessive allocation of memory in tls_get_message_header() · c1ef7c97
      Matt Caswell 提交于
      A TLS message includes 3 bytes for its length in the header for the message.
      This would allow for messages up to 16Mb in length. Messages of this length
      are excessive and OpenSSL includes a check to ensure that a peer is sending
      reasonably sized messages in order to avoid too much memory being consumed
      to service a connection. A flaw in the logic of version 1.1.0 means that
      memory for the message is allocated too early, prior to the excessive
      message length check. Due to way memory is allocated in OpenSSL this could
      mean an attacker could force up to 21Mb to be allocated to service a
      connection. This could lead to a Denial of Service through memory
      exhaustion. However, the excessive message length check still takes place,
      and this would cause the connection to immediately fail. Assuming that the
      application calls SSL_free() on the failed conneciton in a timely manner
      then the 21Mb of allocated memory will then be immediately freed again.
      Therefore the excessive memory allocation will be transitory in nature.
      This then means that there is only a security impact if:
      
      1) The application does not call SSL_free() in a timely manner in the
      event that the connection fails
      or
      2) The application is working in a constrained environment where there
      is very little free memory
      or
      3) The attacker initiates multiple connection attempts such that there
      are multiple connections in a state where memory has been allocated for
      the connection; SSL_free() has not yet been called; and there is
      insufficient memory to service the multiple requests.
      
      Except in the instance of (1) above any Denial Of Service is likely to
      be transitory because as soon as the connection fails the memory is
      subsequently freed again in the SSL_free() call. However there is an
      increased risk during this period of application crashes due to the lack
      of memory - which would then mean a more serious Denial of Service.
      
      This issue does not affect DTLS users.
      
      Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
      
      CVE-2016-6307
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      c1ef7c97
  11. 21 9月, 2016 1 次提交
  12. 20 9月, 2016 4 次提交
  13. 14 9月, 2016 1 次提交
  14. 13 9月, 2016 1 次提交