| commit | 70d1e737f43f3d4efde8928316f3762d7c169b2a | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Mon Oct 07 13:34:57 2024 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Oct 21 21:20:00 2024 +0000 |
| tree | 849babfe126b5027e9ac298a0ef81dae1b4b2534 | |
| parent | ee3f9468584b6607f944b885ad50db35a70daf8d [diff] |
Store DTLS epoch state separately This wraps DTLS per-epoch state into DTLSReadEpoch and DTLSWriteEpoch structures. For now, we only keep one DTLSReadEpoch though we will need to keep two in DTLS 1.3. In preparation for that, I've reworked the DTLS record parser to resolve the DTLSReadEpoch at the same time, even though there's currently only one of them. On the write side, this removes the special-cased initial write epoch and just stores an array of the last few epochs. Some things this does not yet do, but that we ideally would do as follow-ups: 1. Move RecordNumberEncrypter out of SSLAEADContext, now that we have a DTLS-specific struct for it. 2. Pass just a byte secret into set_read_state / set_write_state and let the transport-aware code construct the SSLAEADContext. 3. Don't construct the SSLAEADContext at all for QUIC. 4. Don't save the read and write traffic secrets in QUIC at all. 5. KeyUpdate should be part of the SSL_PROTOCOL_METHOD interface to accomodate DTLS driving KeyUpdate by ACK. Update-Note: As part of rearranging the record parser, when the DTLS 1.2 implementation encounters a DTLS 1.3 record, it will now discard just that record and continue parsing records out of the packet, rather than discarding the whole packet. This isn't expected to make any difference. Bug: 371998381 Change-Id: Ie2ae657d41e33152208a001df177630398798394 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72128 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Nick Harper <nharper@chromium.org>
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:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: