GitLab

Use SSL_session_reused to check when a session was reused am: efd7f14d am: 570b68b1 am: 79263dbf am: 37a87dd8  -s ours am: 97adf6ee
am: f4119242

* commit 'f4119242':
  Use SSL_session_reused to check when a session was reused

Change-Id: I954fd0dd7f704154757dd6d330356aad8b5004af

am: a2e751b4

* commit 'a2e751b4':
  Use SSL_session_reused to check when a session was reused

Change-Id: If3ba7b806a4a67247146b89fb1073e353d80ef3f

Use SSL_session_reused to check when a session was reused am: efd7f14d am: 570b68b1 am: 79263dbf am: 37a87dd8  -s ours
am: 97adf6ee

* commit '97adf6ee':
  Use SSL_session_reused to check when a session was reused

Change-Id: Ia45b3883b12a1e6961aae04c790379f22a34dcbe

am: 0b905f8e

* commit '0b905f8e':
  Use SSL_session_reused to check when a session was reused

Change-Id: I86105390b7f9f0af8e2293bd4032fe4fe9b2a471

Use SSL_session_reused to check when a session was reused am: efd7f14d am: 570b68b1 am: 79263dbf
am: 37a87dd8  -s ours

* commit '37a87dd8':
  Use SSL_session_reused to check when a session was reused

Change-Id: Iddfaf5121a109704cce8df7ca00fe1113f99514b

am: 79263dbf

* commit '79263dbf':
  Use SSL_session_reused to check when a session was reused

Change-Id: I7ef24f8b661f8ebbbaa7e5bc15046de469718a8e

am: 570b68b1

* commit '570b68b1':
  Use SSL_session_reused to check when a session was reused

Change-Id: Iec88b79b6ad31dcdd1c4e9f64b3a7fca1d384285

am: efd7f14d

* commit 'efd7f14d':
  Use SSL_session_reused to check when a session was reused

Change-Id: I5575ba2da8aa4acebd6e11a4089b5f152073bcd8

The returned session_id could be exactly the same in the case of TLS
session tickets, so use the SSL_session_reused API to determine exactly
when a session was reused.

(cherry picked from commit 1115fa0f)

Bug: 28751153
Change-Id: Ie82e4d1bb326d7e7deb7981a1e57df393f6c0e1f

The returned session_id could be exactly the same in the case of TLS
session tickets, so use the SSL_session_reused API to determine exactly
when a session was reused.

(cherry picked from commit 1115fa0f)

Bug: 28751153
Change-Id: Ie82e4d1bb326d7e7deb7981a1e57df393f6c0e1f

Due to AAD data not being reset when a Cipher instance was re-used, this
bug was never uncovered by tests that actually exercise this case.

(cherry picked from commit 95cf7b9b)

Bug: 27696681
Bug: 27324690
Change-Id: Iae9b5794f212a8fc4eeff2a651332e7490f5cada

Do to a missing assignment statement, only the first call to updateAAD
was honored and the rest were discarded.

(cherry picked from commit a23b05b3)

Bug: 27371173
Change-Id: I77ad7800b0905f72d5abe76b56352a94056ceb9c

AAD was not being reset correctly during init or doFinal calls thus
leading to incorrect output.

(cherry picked from commit 0bab7f3b)

Bug: 27324690
Change-Id: If7806a9d7847814b60719637abceb94d8fbc8831

Prevent duplicate certificates in TrustedCertificateIndex am: 4c9f9c22 am: 1a86d309 am: 825390d5
am: 360cc576

* commit '360cc576':
  Prevent duplicate certificates in TrustedCertificateIndex

am: 7e3bc71b

* commit '7e3bc71b':
  Cache intermediate CA separately

am: 825390d5

* commit '825390d5':
  Prevent duplicate certificates in TrustedCertificateIndex

am: edac1314

* commit 'edac1314':
  Cache intermediate CA separately

am: 1a86d309

* commit '1a86d309':
  Prevent duplicate certificates in TrustedCertificateIndex

am: 2138a380

* commit '2138a380':
  Cache intermediate CA separately

am: 4c9f9c22

* commit '4c9f9c22':
  Prevent duplicate certificates in TrustedCertificateIndex

am: c4ab1b95

* commit 'c4ab1b95':
  Cache intermediate CA separately

With the separate caching of intermediate certificates in
TrustManagerImpl a given intermediate may be passed into .index multiple
times. Avoid adding the certificate to the list each time.

(cherry-picked from commit d080e064)
Bug: 26232830
Change-Id: I6bed2c65d9e42e052b9b1b129200a997e7dca745

Intermediate CAs are cached in order to support servers that fail to
sent a complete chain to a root. These certificates should be cached to
support these servers but these certificates must not be trusted as
trust anchors. Store them separately to prevent confusion between
trusted roots and cached intermediates.

(cherry-picked from commit 198aca1f)
Bug: 26232830
Change-Id: I520f50729b55fc7412c7d133335bc9e3c190bbf6

BoringSSL disables server-initiated renegotiations by default. However,
it's unclear what the impact of this will be. On the other hand,
rejecting renegotiations certainly makes things simplier.

(cherry picked from commit ed628f94)

Bug: 23189319
Change-Id: I0cd3f04838c0afea665a88d4f0cd0a16c1e811de

Test both client and server. Also we expect a SSLHandshakeException
instead of an SSLProtocolException in one case.

Bug: 21207627
(cherry picked from commit 5429f72d)

Change-Id: If895b03e2cece3a1a8d2f074a557c68f55a7021e

BoringSSL will push the BAD_SIGNATURE error onto the stack for every
signature error. In Java it just returns false from the Signature#verify
call when the signature is incorrect.  However, we still want to throw
an exception for raw RSA when the number of signature bytes is larger
than the modulus can express.

Bug: 21209646
(cherry picked from commit 089b4018)

Change-Id: I96ada8762817a99df11da2f7e7b7310bb31d5cba

SSL_OP_NO_SSLv2 is not a flag anymore (defined as 0 in ssh.h)

Bug: 21875962
(cherry picked from commit 97e54bdd)

Change-Id: I52004b893768b087577c078dcd1ba0ae1bdea911

NativeCrypto.SSL_set_cipher_lists can accept the empty list as
per c/154191

Bug: 21816861

(cherry picked from commit c0010ca5)

Change-Id: I6cf7563417d8b6fb9edbeade0947726275a76c18

(cherry picked from commit d9a48aa4)

Bug: 21034231
Change-Id: I1efd062a6608111e6ab468f4e362291895dd166d

When an error condition is encountered in BoringSSL, sometimes it
deliberately does not put something on the ERR stack to prevent abuse of
that knowledge. Instead we need to throw an exception explicitly when no
error is pushed onto the stack.

(cherry picked from commit 79f05f46)

Bug: 21034231
Change-Id: Ia06347c5653672c982ecff2c26be9b091d03009f

(cherry picked from commit edc4f273)

Bug: 21762837
Change-Id: I11042be8fe1e046ac96759b4554ce9229e1cf6f3

- Consider the |final| buffer when computing the expected length
- Should not expect an extra block when using padding in decrypting
mode

Bug: 19186852
Change-Id: I8c51b309ca98030ab1eda5b2a0201a97a5758072

(cherry-pick from 8fa4acdc)