1. 29 6月, 2017 1 次提交
  2. 28 6月, 2017 1 次提交
  3. 27 6月, 2017 1 次提交
    • R
      util/mkerr.pl: allow module names prefixed with OSSL_ or OPENSSL_ · 4b2799c1
      Richard Levitte 提交于
      To make sure that our symbols don't clash with other libraries, we
      claim the namespaces OSSL and OPENSSL.  Because C doesn't provide
      namespaces, the only solution is to have them as prefixes on symbols,
      thus we allow OSSL_ and OPENSSL_ as prefixes.
      
      These namespace prefixes are optional for the foreseeable future, and
      will only be used for new modules as needed on a case by case basis,
      until further notice.
      
      For extra safety, there's an added requirement that module names -
      apart from the namespace prefix - be at least 2 characters long.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3781)
      4b2799c1
  4. 19 6月, 2017 1 次提交
  5. 16 6月, 2017 1 次提交
  6. 09 6月, 2017 1 次提交
  7. 02 6月, 2017 1 次提交
  8. 01 6月, 2017 1 次提交
  9. 25 5月, 2017 1 次提交
  10. 17 5月, 2017 1 次提交
    • M
      Don't allow fragmented alerts · bd990e25
      Matt Caswell 提交于
      An alert message is 2 bytes long. In theory it is permissible in SSLv3 -
      TLSv1.2 to fragment such alerts across multiple records (some of which
      could be empty). In practice it make no sense to send an empty alert
      record, or to fragment one. TLSv1.3 prohibts this altogether and other
      libraries (BoringSSL, NSS) do not support this at all. Supporting it adds
      significant complexity to the record layer, and its removal is unlikely
      to cause inter-operability issues.
      
      The DTLS code for this never worked anyway and it is not supported at a
      protocol level for DTLS. Similarly fragmented DTLS handshake records only
      work at a protocol level where at least the handshake message header
      exists within the record. DTLS code existed for trying to handle fragmented
      handshake records smaller than this size. This code didn't work either so
      has also been removed.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3476)
      bd990e25
  11. 27 4月, 2017 1 次提交
  12. 21 4月, 2017 1 次提交
  13. 10 4月, 2017 1 次提交
  14. 08 4月, 2017 1 次提交
  15. 31 3月, 2017 1 次提交
  16. 29 3月, 2017 3 次提交
  17. 15 3月, 2017 1 次提交
  18. 14 3月, 2017 1 次提交
  19. 13 3月, 2017 1 次提交
  20. 02 3月, 2017 1 次提交
  21. 01 3月, 2017 1 次提交
  22. 28 2月, 2017 1 次提交
  23. 25 2月, 2017 1 次提交
  24. 16 2月, 2017 1 次提交
  25. 02 2月, 2017 1 次提交
  26. 26 1月, 2017 1 次提交
  27. 28 11月, 2016 1 次提交
    • E
      Test mac-then-encrypt · b3618f44
      Emilia Kasper 提交于
      Verify that the encrypt-then-mac negotiation is handled
      correctly. Additionally, when compiled with no-asm, this test ensures
      coverage for the constant-time MAC copying code in
      ssl3_cbc_copy_mac. The proxy-based CBC padding test covers that as
      well but it's nevertheless better to have an explicit handshake test
      for mac-then-encrypt.
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      b3618f44
  28. 14 11月, 2016 1 次提交
  29. 10 11月, 2016 1 次提交
  30. 03 11月, 2016 1 次提交
  31. 01 11月, 2016 2 次提交
  32. 26 10月, 2016 1 次提交
  33. 13 10月, 2016 1 次提交
  34. 26 9月, 2016 1 次提交
  35. 22 9月, 2016 1 次提交
  36. 15 9月, 2016 1 次提交
  37. 26 8月, 2016 1 次提交