Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
大约 1 年 前同步成功

通知 9
Star 18
Fork 1
T
Third Party Openssl

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 19 2月, 2018 2 次提交
  3. 15 2月, 2018 1 次提交
  5. 14 2月, 2018 2 次提交
    • R
      VMS: for testutil, make sure to use BIO_f_linebuffer · f11a023a
      由 Richard Levitte 提交于 
      Without that, output comes one character per line.  It's the same
issue as has been observed before, this happens when using write()
on a record oriented stream (possibly unbuffered too).

This also uncovered a bug in BIO_f_linebuffer, where this would cause
an error:

    BIO_write(bio, "1\n", 1);

I.e. there's a \n just after the part of the string that we currently
ask to get written.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5352)
      f11a023a
    • D
      DRBG: make the derivation function the default for ctr_drbg · 8164d91d
      由 Dr. Matthias St. Pierre 提交于 
      The NIST standard presents two alternative ways for seeding the
CTR DRBG, depending on whether a derivation function is used or not.
In Section 10.2.1 of NIST SP800-90Ar1 the following is assessed:

  The use of the derivation function is optional if either an
  approved RBG or an entropy source provides full entropy output
  when entropy input is requested by the DRBG mechanism.
  Otherwise, the derivation function shall be used.

Since the OpenSSL DRBG supports being reseeded from low entropy random
sources (using RAND_POOL), the use of a derivation function is mandatory.
For that reason we change the default and replace the opt-in flag
RAND_DRBG_FLAG_CTR_USE_DF with an opt-out flag RAND_DRBG_FLAG_CTR_NO_DF.
This change simplifies the RAND_DRBG_new() calls.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5294)
      8164d91d
  7. 13 2月, 2018 1 次提交
  9. 10 2月, 2018 1 次提交
  11. 09 2月, 2018 1 次提交
  13. 08 2月, 2018 4 次提交
  15. 07 2月, 2018 3 次提交
  17. 03 2月, 2018 1 次提交
  19. 02 2月, 2018 1 次提交
    • T
      Add TLSv1.3 post-handshake authentication (PHA) · 9d75dce3
      由 Todd Short 提交于 
      Add SSL_verify_client_post_handshake() for servers to initiate PHA

Add SSL_force_post_handshake_auth() for clients that don't have certificates
initially configured, but use a certificate callback.

Update SSL_CTX_set_verify()/SSL_set_verify() mode:

* Add SSL_VERIFY_POST_HANDSHAKE to postpone client authentication until after
the initial handshake.

* Update SSL_VERIFY_CLIENT_ONCE now only sends out one CertRequest regardless
of when the certificate authentication takes place; either initial handshake,
re-negotiation, or post-handshake authentication.

Add 'RequestPostHandshake' and 'RequirePostHandshake' SSL_CONF options that
add the SSL_VERIFY_POST_HANDSHAKE to the 'Request' and 'Require' options

Add support to s_client:
* Enabled automatically when cert is configured
* Can be forced enabled via -force_pha

Add support to s_server:
* Use 'c' to invoke PHA in s_server
* Remove some dead code

Update documentation

Update unit tests:
* Illegal use of PHA extension
* TLSv1.3 certificate tests

DTLS and TLS behave ever-so-slightly differently. So, when DTLS1.3 is
implemented, it's PHA support state machine may need to be different.
Add a TODO and a #error

Update handshake context to deal with PHA.

The handshake context for TLSv1.3 post-handshake auth is up through the
ClientFinish message, plus the CertificateRequest message. Subsequent
Certificate, CertificateVerify, and Finish messages are based on this
handshake context (not the Certificate message per se, but it's included
after the hash). KeyUpdate, NewSessionTicket, and prior Certificate
Request messages are not included in post-handshake authentication.

After the ClientFinished message is processed, save off the digest state
for future post-handshake authentication. When post-handshake auth occurs,
copy over the saved handshake context into the "main" handshake digest.
This effectively discards the any KeyUpdate or NewSessionTicket messages
and any prior post-handshake authentication.

This, of course, assumes that the ID-22 did not mean to include any
previous post-handshake authentication into the new handshake transcript.
This is implied by section 4.4.1 that lists messages only up to the
first ClientFinished.
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4964)
      9d75dce3
  21. 01 2月, 2018 3 次提交
  23. 29 1月, 2018 1 次提交
  25. 28 1月, 2018 1 次提交
  27. 26 1月, 2018 3 次提交
  29. 25 1月, 2018 2 次提交
  31. 24 1月, 2018 2 次提交
  33. 23 1月, 2018 1 次提交
  35. 22 1月, 2018 1 次提交
  37. 20 1月, 2018 1 次提交
  39. 19 1月, 2018 1 次提交
  41. 09 1月, 2018 1 次提交
  43. 06 1月, 2018 1 次提交
  45. 04 1月, 2018 1 次提交
    • D
      crypto/rand: restore the generic DRBG implementation · 8212d505
      由 Dr. Matthias St. Pierre 提交于 
      The DRGB concept described in NIST SP 800-90A provides for having different
algorithms to generate random output. In fact, the FIPS object module used to
implement three of them, CTR DRBG, HASH DRBG and HMAC DRBG.

When the FIPS code was ported to master in #4019, two of the three algorithms
were dropped, and together with those the entire code that made RAND_DRBG
generic was removed, since only one concrete implementation was left.

This commit restores the original generic implementation of the DRBG, making it
possible again to add additional implementations using different algorithms
(like RAND_DRBG_CHACHA20) in the future.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4998)
      8212d505
  47. 03 1月, 2018 1 次提交
  49. 02 1月, 2018 1 次提交
  51. 27 12月, 2017 1 次提交
  53. 18 12月, 2017 1 次提交