RFR: 8372526: Add support for ZLIB TLS Certificate Compression [v9]

Artur Barashev abarashev at openjdk.org
Tue Jan 27 17:27:43 UTC 2026


On Tue, 27 Jan 2026 16:54:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allocate 24 bits for input size in cache key. Add unit tests.
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:
> 
>> 980:             boolean enableCertificateCompression) {
>> 981:         this.enableCertificateCompression = enableCertificateCompression;
>> 982:     }
> 
> Is there a plan to support brotli compression algorithm in OpenJDK?  It is the only supported algorithm in browser Chrome.
> 
> If there is a need to support more than one compression algorithms in the future, it might be better to provide an option to customize the algorithms selection, including preferences.  The flexibility could provide better interoperability if a vendor does not support compression algorithm properly.

Yes, strangely Chrome supports only brotli although I didn't see any difference in compression ration between zlib and brotli when manually testing certificate compression. We may add support for more algorithms in the future, but for now it's zlib only.
Generally speaking, it's the certificate's metadata that is being compressed, the keys are high-entropy data difficult to compress. PQC certificates don’t compress well, most likely because of lower metadata to keys ratio.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2733079369


More information about the security-dev mailing list