33dad1b7a1
We broke this to varying degrees ages ago. This is the logic to implement the variations of rules in TLS to discard sessions after a failed connection, where a failed connection could be one of: - A connection that was not cleanly shut down. - A connection that received a fatal alert. The first one is nonsense since close_notify does not actually work in the real world. The second is a vaguely more plausible but... - A stateless ticket-based server can't drop sessions anyway. - In TLS 1.3, a client may receive many tickets over the lifetime of a single connection. With an external session cache like ours which may, in theory, but multithreaded, this will be a huge hassle to track. - A client may well attempt to establish a connection and reuse the session before we receive the fatal alert, so any application state we hope to manage won't really work. - An attacker can always close the connection before the fatal alert, so whatever security policy clearing the session gave is easily bypassable. Implementation-wise, this has basically never worked. The ssl_clear_bad_session logic called into SSL_CTX_remove_session which relied on the internal session cache. (Sessions not in the internal session cache don't get removed.) The internal session cache was only useful for a server, where tickets prevent this mechanism from doing anything. For a client, we since removed the internal session cache, so nothing got removed. The API for a client also did not work as it gave the SSL_SESSION, not the SSL, so a consumer would not know the key to invalidate anyway. The recent session state splitting change further broke this. Moreover, calling into SSL_CTX_remove_session logic like that is extremely dubious because it mutates the not_resumable flag on the SSL_SESSION which isn't thread-safe. Spec-wise, TLS 1.3 has downgraded the MUST to a SHOULD. Given all that mess, just remove this code. It is no longer necessary to call SSL_shutdown just to make session caching work. Change-Id: Ib601937bfc5f6b40436941e1c86566906bb3165d Reviewed-on: https://boringssl-review.googlesource.com/9091 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> |
||
|---|---|---|
| .github | ||
| crypto | ||
| decrepit | ||
| fuzz | ||
| include/openssl | ||
| infra/config | ||
| ssl | ||
| third_party/android-cmake | ||
| tool | ||
| util | ||
| .clang-format | ||
| .gitignore | ||
| BUILDING.md | ||
| CMakeLists.txt | ||
| codereview.settings | ||
| CONTRIBUTING.md | ||
| FUZZING.md | ||
| INCORPORATING.md | ||
| LICENSE | ||
| PORTING.md | ||
| README.md | ||
| STYLE.md | ||
BoringSSL
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:
- PORTING.md: how to port OpenSSL-using code to BoringSSL.
- BUILDING.md: how to build BoringSSL
- INCORPORATING.md: how to incorporate BoringSSL into a project.
- STYLE.md: rules and guidelines for coding style.
- include/openssl: public headers with API documentation in comments. Also available online.
- FUZZING.md: information about fuzzing BoringSSL.
- CONTRIBUTING.md: how to contribute to BoringSSL.