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

[Artur Barashev]

On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force cache limit per compression algorithm

> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> 
> On Tue, Jan 27, 2026 at 9:27?AM Artur Barashev <abarashev at openjdk.org> wrote:
> 
> > 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.
> 
> Once there is a need to support more algorithms, this API may not be applicable for some cases especially when there are compatibility impact. It might be good to consider the API to support multiple algorithms from day zero.
> 
> Just my $0.02.
> 
> Thanks, Xuelei
> 
> > 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.
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/7e41c352/attachment.htm>

I know original design had callback functions for custom deflators/inflators, but it was decided to support only internally implemented ZLIB for now. We may add callbacks at the later time if there is a demand for it. Current API only enables/disables the certificate compression overall, there shouldn't be any compatibly issues with future callback function mechanism if we decide to support it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28682#issuecomment-3812904883