1. 24 11月, 2016 2 次提交
  2. 23 11月, 2016 6 次提交
  3. 17 11月, 2016 1 次提交
  4. 16 11月, 2016 4 次提交
    • M
      Fixed various style issues in the key_share code · 94ed2c67
      Matt Caswell 提交于
      Numerous style issues as well as references to TLS1_3_VERSION instead of
      SSL_IS_TLS13(s)
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      94ed2c67
    • M
      ef7daaf9
    • M
      Start using the key_share data to derive the PMS · 0f1e51ea
      Matt Caswell 提交于
      The previous commits put in place the logic to exchange key_share data. We
      now need to do something with that information. In <= TLSv1.2 the equivalent
      of the key_share extension is the ServerKeyExchange and ClientKeyExchange
      messages. With key_share those two messages are no longer necessary.
      
      The commit removes the SKE and CKE messages from the TLSv1.3 state machine.
      TLSv1.3 is completely different to TLSv1.2 in the messages that it sends
      and the transitions that are allowed. Therefore, rather than extend the
      existing <=TLS1.2 state transition functions, we create a whole new set for
      TLSv1.3. Intially these are still based on the TLSv1.2 ones, but over time
      they will be amended.
      
      The new TLSv1.3 transitions remove SKE and CKE completely. There's also some
      cleanup for some stuff which is not relevant to TLSv1.3 and is easy to
      remove, e.g. the DTLS support (we're not doing DTLSv1.3 yet) and NPN.
      
      I also disable EXTMS for TLSv1.3. Using it was causing some added
      complexity, so rather than fix it I removed it, since eventually it will not
      be needed anyway.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      0f1e51ea
    • M
      Add the key_share processing to the server side · b1834ad7
      Matt Caswell 提交于
      At the moment the server doesn't yet do anything with this information.
      We still need to send the server's key_share info back to the client. That
      will happen in subsequent commits.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      b1834ad7
  5. 14 11月, 2016 1 次提交
  6. 10 11月, 2016 9 次提交
  7. 09 11月, 2016 13 次提交
  8. 08 11月, 2016 1 次提交
    • M
      Partial revert of "Fix client verify mode to check SSL_VERIFY_PEER" · c8e2f98c
      Matt Caswell 提交于
      This partially reverts commit c636c1c4. It also tweaks the documentation
      and comments in this area. On the client side the documented interface for
      SSL_CTX_set_verify()/SSL_set_verify() is that setting the flag
      SSL_VERIFY_PEER causes verfication of the server certificate to take place.
      Previously what was implemented was that if *any* flag was set then
      verification would take place. The above commit improved the semantics to
      be as per the documented interface.
      
      However, we have had a report of at least one application where an
      application was incorrectly using the interface and used *only*
      SSL_VERIFY_FAIL_IF_NO_PEER_CERT on the client side. In OpenSSL prior to
      the above commit this still caused verification of the server certificate
      to take place. After this commit the application silently failed to verify
      the server certificate.
      
      Ideally SSL_CTX_set_verify()/SSL_set_verify() could be modified to indicate
      if invalid flags were being used. However these are void functions!
      
      The simplest short term solution is to revert to the previous behaviour
      which at least means we "fail closed" rather than "fail open".
      
      Thanks to Cory Benfield for reporting this issue.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      c8e2f98c
  9. 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
  10. 04 11月, 2016 2 次提交