This is just the API and documentation, to see if this makes sense before expending the effort on an implementation.
This should satisfy @hlandau's request for GREASE in the Certificate Compression PR, and also the additional testing of Certificate Compression by @beldmit.

A full implementation would store the grease values in an SSL_CTX. Then the (appropriate) extensions would be modified to include the given values. This would probably need to be done in the extension CTOS/STOC functions such that the values are included in the handshake hashes. I'm leaning toward having the greased values be first in any given extension/list.

The intent is that a connection can succeed with GREASED values. A crash or connection failure would be considered a failure (apologies for redundancy there).

The final PR would include tests of the generic APIs, along with sufficient values for testing Certificate Compression, especially around the use of 1-byte vs. 2-byte valued compression IDs.

OK... how is this a FIPS change? I updated a minimal set of files; is the FIPS scope too broad?

It's ssl.h.in causing the FIPS related flag to be set.
I suspect it's a case of things being too broad.

Nice to see people working on this.

It's probably a bit overkill to expose a new public API to add arbitrary GREASE. I'd expect we'd want to generate random GREASE internally in an automatic fashion. The only public API we'd need is a simple on/off, or maybe individual on/off for the different circumstances GREASE can be used. A set of flags would work well for this.

My guess is we'd want to merge this default-off initially, then turn it on by default in some later release when we have more confidence it won't break things.

It's ssl.h.in causing the FIPS related flag to be set.
I suspect it's a case of things being too broad.

We did not have ssl.h.in inside the FIPS sources. Something has broken it. I'll investigate.

Nice to see people working on this.

It's probably a bit overkill to expose a new public API to add arbitrary GREASE. I'd expect we'd want to generate random GREASE internally in an automatic fashion. The only public API we'd need is a simple on/off, or maybe individual on/off for the different circumstances GREASE can be used. A set of flags would work well for this.

My guess is we'd want to merge this default-off initially, then turn it on by default in some later release when we have more confidence it won't break things.

The problem with random is with testing. You want consistent tests in order to reproduce problems. In the case of a recent CertificateCompression bug (where one byte was read vs two), most of the values would not cause issues, only those where the value had a byte with 0x01, 0x02 or 0x03 in it would cause an issue (I'm not going to do the math right now, but its probably in the area of 3/256 odds of hitting the bug randomly).

This could be an internal API, with a wrapper around it to make it public and random. But exposing the API makes the OpenSSL toolkit more valuable as a test tool.

References:
#18186 (comment)
#19600 (comment)

Nice to see people working on this.
It's probably a bit overkill to expose a new public API to add arbitrary GREASE. I'd expect we'd want to generate random GREASE internally in an automatic fashion. The only public API we'd need is a simple on/off, or maybe individual on/off for the different circumstances GREASE can be used. A set of flags would work well for this.
My guess is we'd want to merge this default-off initially, then turn it on by default in some later release when we have more confidence it won't break things.

The problem with random is with testing. You want consistent tests in order to reproduce problems. In the case of a recent CertificateCompression bug (where one byte was read vs two), most of the values would not cause issues, only those where the value had a byte with 0x01, 0x02 or 0x03 in it would cause an issue (I'm not going to do the math right now, but its probably in the area of 3/256 odds of hitting the bug randomly).

This could be an internal API, with a wrapper around it to make it public and random. But exposing the API makes the OpenSSL toolkit more valuable as a test tool.

I wonder if a good API for this would just be to have calls to get and set a random seed, e.g. on a SSL_CTX. 64 bits would be enough. The random seed would be used to derive other randomness deterministically. A random value could be used by default and if you hit an error, you could use the accessor to get the seed which was used and reproduce the issue.

I wonder if a good API for this would just be to have calls to get and set a random seed, e.g. on a SSL_CTX. 64 bits would be enough. The random seed would be used to derive other randomness deterministically. A random value could be used by default and if you hit an error, you could use the accessor to get the seed which was used and reproduce the issue.

I don't think random-only with a seed is very useful. It makes it harder to get specific values that you might want to use for GREASE. e.g. get 0x0101/0x0202/0x0303 for use in the recent compression fix. And not everyone is able to remember to get a random value for a given error.

If someone really wanted a random value, it's easy enough to use the RAND API for inputs.

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

ping @openssl/committers ?

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

This PR is in a state where it requires action by @openssl/otc but the last update was 154 days ago

This PR is in a state where it requires action by @openssl/otc but the last update was 185 days ago

This PR is in a state where it requires action by @openssl/otc but the last update was 216 days ago

This PR is in a state where it requires action by @openssl/otc but the last update was 247 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 61 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 92 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 123 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 154 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 185 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 216 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 247 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 278 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 309 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 340 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 371 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 402 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 433 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 464 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 495 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 526 days ago