Tighten SSL_OP_LEGACY_SERVER_CONNECT to align with RFC 5746.

RFC 5746 forbids a server from downgrading or upgrading
renegotiation_info support. Even with SSL_OP_LEGACY_SERVER_CONNECT set
(the default), we can still enforce a few things.

I do not believe this has practical consequences. The attack variant
where the server half is prefixed does not involve a renegotiation on
the client. The converse where the client sees the renegotiation and
prefix does, but we only support renego for the mid-stream HTTP/1.1
client auth hack, which doesn't do this. (And with triple-handshake,
HTTPS clients should be requiring the certificate be unchanged across
renego which makes this moot.)

Ultimately, an application which makes the mistake of using
renegotiation needs to be aware of what exactly that means and how to
handle connection state changing mid-stream. We make renego opt-in now,
so this is a tenable requirement.

(Also the legacy -> secure direction would have been caught by the
server anyway since we send a non-empty RI extension.)

Change-Id: I915965c342f8a9cf3a4b6b32f0a87a00c3df3559
Reviewed-on: https://boringssl-review.googlesource.com/6559
Reviewed-by: Adam Langley <agl@google.com>
6 files changed
tree: 6f62aad5bdf80b83e724487dbfacd173a8d10ca2
  1. .clang-format
  2. .gitignore
  3. BUILDING.md
  4. CMakeLists.txt
  5. FUZZING.md
  6. LICENSE
  7. PORTING.md
  8. README.md
  9. STYLE.md
  10. codereview.settings
  11. crypto/
  12. decrepit/
  13. fuzz/
  14. include/
  15. ssl/
  16. tool/
  17. util/
README.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
  • 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.