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.
When passing BORING_BSSL_FIPS_PATH, you need to add /lib/ to the search
path, and when passing BORING_BSSL_PATH you need to add /crypto/ and
/ssl/ to the search path.
We need to add `/build/crypto` and `/build/ssl` to the library search
path to handle the case where we pass `BORING_BSSL_SOURCE_PATH` when
building without enabling any fips features. Otherwise, non bazel
commits will not work because `/build/` itself will not contain any
crypto libraries to link with
This feature expects a recent boringssl checkout (such as the one
found in boring-sys/deps/boringssl), so it should not be using
the same bindings as the fips feature, which are based on
boring-sys/deps/boringssl-fips, which is older and with a different
API.
It serves no purpose as there is no additional API in tokio-boring when
this feature is enabled, but there is a test gated by it and it can't
be conditionnally enabled only when boring's feature is enabled.
This helps drive async callbacks from outside tokio-boring, such as in quiche.
Not a breaking change because every public item in tokio-boring is preserved as is.
Setting callbacks multiple times on a SslContextBuilder causes the previous callback
installed to leak, using replace_ex_data internally prevents that.
We also start using it in tokio-boring in with_ex_data_future, my understanding
is that the futures currently in use are never installed twice by that function
but that could change in the future with the addition of more async callbacks.
Eric Rosenberg