Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
10 个月 前同步成功

通知 8
Star 18
Fork 1
T
Third Party Openssl

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 26 4月, 2017 2 次提交
  3. 10 4月, 2017 1 次提交
    • B
      Allow an ALPN callback to pretend to not exist · 8313a787
      由 Benjamin Kaduk 提交于 
      RFC 7301 mandates that the server SHALL respond with a fatal
"no_application_protocol" alert when there is no overlap between
the client's supplied list and the server's list of supported protocols.
In commit 06217867 we changed from
ignoring non-success returns from the supplied alpn_select_cb() to
treating such non-success returns as indicative of non-overlap and
sending the fatal alert.

In effect, this is using the presence of an alpn_select_cb() as a proxy
to attempt to determine whether the application has configured a list
of supported protocols.  However, there may be cases in which an
application's architecture leads it to supply an alpn_select_cb() but
have that callback be configured to take no action on connections that
do not have ALPN configured; returning SSL_TLSEXT_ERR_NOACK from
the callback would be the natural way to do so.  Unfortunately, the
aforementioned behavior change also treated SSL_TLSEXT_ERR_NOACK as
indicative of no overlap and terminated the connection; this change
supplies special handling for SSL_TLSEXT_ERR_NOACK returns from the
callback.  In effect, it provides a way for a callback to obtain the
behavior that would have occurred if no callback was registered at
all, which was not possible prior to this change.
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2570)
      8313a787
  5. 07 4月, 2017 3 次提交
  7. 04 4月, 2017 2 次提交
  9. 29 3月, 2017 1 次提交
  11. 21 3月, 2017 1 次提交
    • M
      Fix resumption after HRR · 77815a02
      由 Matt Caswell 提交于 
      Commit 6b1bb98f moved the processing of ClientHello extensions into the
state machine post-processing stage. After processing s->init_num is reset
to 0, so by post-processing we cannot rely on its value. Unfortunately we
were using it to handle the PSK extension. This causes the handshake to
fail.

We were using init_num to figure out the length of ClientHello2 so we can
remove it from the handshake_buffer. The handshake_buffer holds the
transcript of all the messages sent so far. For PSK processing though we
only want to add in a partial ClientHello2. This commit changes things so
we just work out where ClientHello2 starts, working forward from the
beginning of handshake_buffer.

Fixes #2983
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2996)
      77815a02
  13. 18 3月, 2017 2 次提交
  15. 16 3月, 2017 2 次提交
  17. 15 3月, 2017 1 次提交
  19. 10 3月, 2017 1 次提交
  21. 05 3月, 2017 2 次提交
  23. 03 3月, 2017 8 次提交
  25. 24 2月, 2017 1 次提交
  27. 16 2月, 2017 1 次提交
    • M
      Don't change the state of the ETM flags until CCS processing · 28a31a0a
      由 Matt Caswell 提交于 
      In 1.1.0 changing the ciphersuite during a renegotiation can result in
a crash leading to a DoS attack. In master this does not occur with TLS
(instead you get an internal error, which is still wrong but not a security
issue) - but the problem still exists in the DTLS code.

The problem is caused by changing the flag indicating whether to use ETM
or not immediately on negotiation of ETM, rather than at CCS. Therefore,
during a renegotiation, if the ETM state is changing (usually due to a
change of ciphersuite), then an error/crash will occur.

Due to the fact that there are separate CCS messages for read and write
we actually now need two flags to determine whether to use ETM or not.

CVE-2017-3733
Reviewed-by: NRichard Levitte <levitte@openssl.org>
      28a31a0a
  29. 15 2月, 2017 1 次提交
  31. 14 2月, 2017 6 次提交
  33. 01 2月, 2017 1 次提交
  35. 30 1月, 2017 4 次提交