| commit | 060cfb091194edf7341d91009764c64096a87157 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Thu May 12 00:43:05 2016 -0400 |
| committer | David Benjamin <davidben@google.com> | Fri May 13 20:06:24 2016 +0000 |
| tree | 62573149cd380ddf3f0d8b6a2153ae36bfb69a97 | |
| parent | 4e7a1ff055b987c9f900a2279380290cb8d9e939 [diff] |
Simplify handshake message size limits. A handshake message can go up to 2^24 bytes = 16MB which is a little large for the peer to force us to buffer. Accordingly, we bound the size of a handshake message. Rather than have a global limit, the existing logic uses a different limit at each state in the handshake state machine and, for certificates, allows configuring the maximum certificate size. This is nice in that we engage larger limits iff the relevant state is reachable from the handshake. Servers without client auth get a tighter limit "for free". However, this doesn't work for DTLS due to out-of-order messages and we use a simpler scheme for DTLS. This scheme also is tricky on optional messages and makes the handshake <-> message layer communication complex. Apart from an ignored 20,000 byte limit on ServerHello, the largest non-certificate limit is the common 16k limit on ClientHello. So this complexity wasn't buying us anything. Unify everything on the DTLS scheme except, so as not to regress bounds on client-auth-less servers, also correctly check for whether client auth is configured. The value of 16k was chosen based on this value. (The 20,000 byte ServerHello limit makes no sense. We can easily bound the ServerHello because servers may not send extensions we don't implement. But it gets overshadowed by the certificate anyway.) Change-Id: I00309b16d809a3c2a1543f99fd29c4163e3add81 Reviewed-on: https://boringssl-review.googlesource.com/7941 Reviewed-by: David Benjamin <davidben@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: