Users can override the new default behavior in the usual way. The
expectation is that the build of BoringSSL they provide the feature set
implemented by the patch.
Per BoringSSL's FIPS policy, its `main` branch is the "update branch"
for FedRAMP compliance's purposes.
This means that we can stop using a specific BoringSSL branch when
enabling FIPS, as well as a number of hacks that allowed us to build
more recent BoringSSL versions with an older pre-compiled FIPS modules.
This also required slightly updating the main BoringSSL submodule, as
the previous version had an issue when building with the FIPS option
enabled. This is turn required some changes to the PQ patch as well as
some APIs that don't seem to be exposed publicly, as well as changing
some paths in the other patches.
In order to allow a smooth upgrade of internal projects, the `fips-compat`
feature is reduced in scope and renamed to `legacy-compat-deprecated` so
that we can incrementally upgrade internal BoringSSL forks. In practice
this shouldn't really be something anyone else would need, since in
order to work it requires a specific mix of BoringSSL version and
backported patches.
Newer versions of FIPS don't need any special casing in our bindings,
unlike the submoduled boringssl-fips. In addition, many users currently
use FIPS by precompiling BoringSSL with the proper build tools and
passing that in to the bindings.
Until we adopt the Update Stream pattern for FIPS, there are two main
use cases:
1. Passing an unmodified, precompiled FIPS validated version of
boringssl (fips-precompiled)
2. Passing a custom source directory of boringssl meant to be linked
with a FIPS validated bcm.o. This is mainly useful if you carry
custom patches but still want to use a FIPS validated BoringCrypto.
(fips-link-precompiled)
This commit introduces the `fips-precompiled` feature and removes the
`fips-no-compat` feature.
Modify the "fips" feature so that it no longer implies "fips-compat".
The latter is no longer needed for recent builds of boringSSL; users who
need older builds will need to enable "fips-compat" explicitly.
Also, remove the "fipps-no-compat" feature, as it's now equivalent to
"fips".
As of boringSSL commit a430310d6563c0734ddafca7731570dfb683dc19, we no
longer need to make exceptions for the types of BufLen, ProtosLen, and
ValueLen, which means the "fips-compat" feature is no longer needed for
"fips" users.
Currently "fips" implies "fips-compat". To allow users to upgrade
without breaking API compatibility with boring version 4, add a new
feature, "fips-no-compat", that does not imply "fips-compat".
In boring 5, we should remove "fips-no-compat" and decouple
"fips-compat" from "fips".
Closes#294. Requires breaking changes. The default v0 is changed in
favor of v1, but v0 is still kept available, just in a forced module
path. It enables dependency de-duplication when consuming it.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
When establishing new TLS sessions, servers may send multiple session
tickets (RFC8446 4.6.1). hyper-boring caches tickets without placing a
limit on how many tickets are cached. This leads to unbounded growth of
hyper-boring's cache and leaves clients vulnerable to malicious servers
who might send many session tickets to exhaust a client's available
memory.
This change bounds the cache to a default of 8 tickets.
This was an accidental regression in
d1ee9bfd86 which leads to pulling in the
full featureset of tokio and hyper for all dependents of tokio-boring
and hyper-boring.
Fixes#179.
Feature no-patches is ever only useful when setting other env variables
BORING_BSSL{,_FIPS}{,_SOURCE}_PATH, and it has no impact on the APIs
provided by any of the boring crates, so we may as well make it an env
variable itself so downstream users have less features to propagate
across their own crate graph.
Feature rpk in boring doesn't do anything unless you
explicitly use `SslAcceptor::rpk` or `SslContext::rpk_builder`,
and neither of these types are directly reachable if the
user depends only on tokio-boring or hyper-boring, which
means you still need to explicitly depend on the boring crate
to use RPK, in which case you can enable the feature there.
Builds using feature fips or fips-link-precompiled now
read variables prefixed by BORING_BSSL_FIPS_ instead of
BORING_BSSL_. This helps complex builds where build dependencies
also use boring, where we may not want to use fips there.
Without those separate variables, the boring build for the
build dependencies end up relying on e.g. BORING_BSSL_PATH,
causing errors if this path is a boring checkout intended for
fips builds, while the fips feature isn't enabled for
the build dependency.
Sometimes google replies with 302 to redirect to another Google website
with a country-specific TLD. We don't actually care which status code
is returned, just that we successfully connect to google.com with
the HTTPS connector.
* Add rerun-if-env-changed instructions for BORING_* variables
* Use X509_get0_notBefore() and X509_get0_notAfter() instead of X509_getm_notBefore() and X509_getm_notAfter().
According to
https://www.openssl.org/docs/man1.1.0/man3/X509_getm_notBefore.html,
"X509_getm_notBefore() and X509_getm_notAfter() are similar to
X509_get0_notBefore() and X509_get0_notAfter() except they return
non-constant mutable references to the associated date field of the
certificate".
* Only update boringssl submodule if BORING_BSSL_PATH not provided
* Allow BORING_BSSL_LIB_PATH to control link search
* Add fips feature
* Use X509_set_notAfter unconditionally for FIPS compatibility
This is equivalent according to
https://boringssl.googlesource.com/boringssl/+/c947efabcbc38dcf93e8ad0e6a76206cf0ec8072
The version of boringssl that's FIPS-certified doesn't have `X509_set1_notAfter`.
The only difference between that and `X509_set_notAfter` is whether they're const-correct,
which doesn't seem worth having two different code-paths.
* Check out fips commit automatically
* Verify the version of the compiler used for building boringssl
NIST specifies that it needs to be 7.0.1; I originally tried building with clang 10 and it failed.
Theoretically this should check the versions of Go and Ninja too, but they haven't given me trouble in practice.
Example error:
```
Compiling boring-sys v1.1.1 (/home/jnelson/work/boring/boring-sys)
error: failed to run custom build command for `boring-sys v1.1.1 (/home/jnelson/work/boring/boring-sys)`
Caused by:
process didn't exit successfully: `/home/jnelson/work/boring/target/debug/build/boring-sys-31b8ce53031cfd83/build-script-build` (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=BORING_BSSL_PATH
--- stderr
warning: missing clang-7, trying other compilers: Permission denied (os error 13)
warning: FIPS requires clang version 7.0.1, skipping incompatible version "clang version 10.0.0-4ubuntu1 "
thread 'main' panicked at 'unsupported clang version "cc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0": FIPS requires clang 7.0.1', boring-sys/build.rs:216:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
* Add Github actions workflow testing FIPS
Co-authored-by: Joshua Nelson <jnelson@cloudflare.com>
- Major version for boring-sys: `PasswordCallback` was removed
- Major version for boring: the public `*Ref` types were removed and `foreign-types` appears in our public api and had a major version bump
- Patch version for tokio-boring: the only API change was removing the `S: Debug` bound
- Patch version for hyper-boring: no API changes, only removed dependencies
