| commit | 2a0b391ac99161ead697c9c30de3d7720d08fc9b | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@chromium.org> | Fri Dec 18 01:01:21 2015 -0500 |
| committer | Adam Langley <agl@google.com> | Tue Dec 22 17:23:58 2015 +0000 |
| tree | c4c0771e2fe93968cb73d8b711f77c8b6c910b4c | |
| parent | d16bf3421c67c5989aca3db4b3d69bc9a84836be [diff] |
Rewrite ssl3_send_server_key_exchange to use CBB. There is some messiness around saving and restoring the CBB, but this is still significantly clearer. Note that the BUF_MEM_grow line is gone in favor of a fixed CBB like the other functions ported thus far. This line was never necessary as init_buf is initialized to 16k and none of our key exchanges get that large. (The largest one can get is DHE_RSA. Even so, it'd take a roughly 30k-bit DH group with a 30k-bit RSA key.) Having such limits and tight assumptions on init_buf's initial size is poor (but on par for the old code which usually just blindly assumed the message would not get too large) and the size of the certificate chain is much less obviously bounded, so those BUF_MEM_grows can't easily go. My current plan is convert everything but those which legitimately need BUF_MEM_grow to CBB, then atomically convert the rest, remove init_buf, and switch everything to non-fixed CBBs. This will hopefully also simplify async resumption. In the meantime, having a story for resumption means the future atomic change is smaller and, more importantly, relieves some complexity budget in the ServerKeyExchange code for adding Curve25519. Change-Id: I1de6af9856caaed353453d92a502ba461a938fbd Reviewed-on: https://boringssl-review.googlesource.com/6770 Reviewed-by: Adam Langley <agl@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
There are other files in this directory which might be helpful: