1. 26 Jan, 2017 1 commit
    • Andy Polyakov's avatar
      crypto/evp: harden RC4_MD5 cipher. · 51d00904
      Andy Polyakov authored
      
      
      Originally a crash in 32-bit build was reported CHACHA20-POLY1305
      cipher. The crash is triggered by truncated packet and is result
      of excessive hashing to the edge of accessible memory (or bogus
      MAC value is produced if x86 MD5 assembly module is involved). Since
      hash operation is read-only it is not considered to be exploitable
      beyond a DoS condition.
      
      Thanks to Robert Święcki for report.
      
      CVE-2017-3731
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      51d00904
  2. 24 Jan, 2017 2 commits
  3. 23 Jan, 2017 1 commit
    • Matt Caswell's avatar
      Fix SSL_VERIFY_CLIENT_ONCE · e203f493
      Matt Caswell authored
      
      
      The flag SSL_VERIFY_CLIENT_ONCE is documented as follows:
      
        B<Server mode:> only request a client certificate on the initial TLS/SSL
        handshake. Do not ask for a client certificate again in case of a
        renegotiation. This flag must be used together with SSL_VERIFY_PEER.
      
        B<Client mode:> ignored
      
      But the implementation actually did nothing. After the server sends its
      ServerKeyExchange message, the code was checking s->session->peer to see if
      it is NULL. If it was set then it did not ask for another client
      certificate. However s->session->peer will only be set in the event of a
      resumption, but a ServerKeyExchange message is only sent in the event of a
      full handshake (i.e. no resumption).
      
      The documentation suggests that the original intention was for this to
      have an effect on renegotiation, and resumption doesn't come into it.
      
      The fix is to properly check for renegotiation, not whether there is already
      a client certificate in the session.
      
      As far as I can tell this has been broken for a *long* time.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/1984)
      e203f493
  4. 20 Jan, 2017 2 commits
  5. 18 Jan, 2017 1 commit
  6. 11 Jan, 2017 1 commit
  7. 10 Jan, 2017 1 commit
  8. 09 Jan, 2017 1 commit
  9. 29 Dec, 2016 1 commit
  10. 20 Dec, 2016 2 commits
  11. 18 Dec, 2016 1 commit
  12. 14 Dec, 2016 3 commits
  13. 13 Dec, 2016 1 commit
  14. 12 Dec, 2016 1 commit
    • Andy Polyakov's avatar
      perlasm/x86_64-xlate.pl: refine sign extension in ea package. · 7624a318
      Andy Polyakov authored
      
      
      $1<<32>>32 worked fine with either 32- or 64-bit perl for a good while,
      relying on quirk that [pure] 32-bit perl performed it as $1<<0>>0. But
      this apparently changed in some version past minimally required 5.10,
      and operation result became 0. Yet, it went unnoticed for another while,
      because most perl package providers configure their packages with
      -Duse64bitint option.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit 82e08930)
      7624a318
  15. 10 Dec, 2016 3 commits
  16. 08 Dec, 2016 2 commits
  17. 29 Nov, 2016 1 commit
  18. 27 Nov, 2016 1 commit
  19. 26 Nov, 2016 1 commit
  20. 25 Nov, 2016 1 commit
  21. 22 Nov, 2016 1 commit
  22. 21 Nov, 2016 1 commit
  23. 18 Nov, 2016 1 commit
  24. 16 Nov, 2016 6 commits
  25. 13 Nov, 2016 1 commit
  26. 10 Nov, 2016 2 commits