| commit | f9cc26f9c1c07668e29be71e08324f68d50d0942 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Feb 09 16:49:31 2020 -0500 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Thu Feb 13 19:30:40 2020 +0000 |
| tree | 636a226e768551dcf18948fe00cdb20c8cecd136 | |
| parent | 21a879a78a60c8667468a9eba994c8365eaf92ea [diff] |
Require handshake flights end at record boundaries. The TLS handshake runs over a sequence of messages, serialized onto a stream, which is then packetized into records, with no correlation to message boundaries. TLS messages may span records, so a TLS implementation will buffer up excess data in a record for the next message. If not checked, that next message may a round-trip or even a key change later. Carrying data across a key change has security consequences, so we reject any excess data across key changes (see ChangeCipherSpec synchronization tests and (d)tls_set_read_state). However, we do not currently check it across network round trips that do not change keys. For instance, a TLS 1.2 client may pack part of ClientKeyExchange (the first byte, at least, is deterministic) into the ClientHello record, before even receiving ServerHello. Most TLS implementations will accept this. However, the handback logic does *not* serialize excess data in hs_buf. There shouldn't be any, but if the peer is doing strange things as above, that data will get silently dropped. The way TLS 1.3 0-RTT handback logic works (the key isn't installed until after handback), this data is even silently dropped though there is a key change. To keep all our behavior consistent, check for unprocessed handshake data at the end of each flight and reject it. Add a bunch of tests. Update-Note: If the peer packs data across handshake flights, or packs HelloRequest into the same record as Finished, this will now be an error. (The former is pathologically odd behavior. The latter is also rejected by Schannel and also odd.) Change-Id: I9412bbdea09ee7fdcfeb78d3456329505a190641 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39987 Commit-Queue: David Benjamin <davidben@google.com> 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.
Project links:
There are other files in this directory which might be helpful: