Implement TLS 1.3 random record padding to mitigate BREACH

[Craig Andrews]

The TLS specification (RFC 8446) section 5.4 defines optional Record Padding: ​https://tools.ietf.org/html/rfc8446#section-5.4

As a security improvement, I suggest that nginx implement random record padding.

Random record padding would mitigate the BREACH attack (and other similar) vulnerabilities.

In OpenSSL, this is done using SSL_CTX_set_record_padding_callback: ​https://www.openssl.org/docs/man1.1.1/man3/SSL_set_block_padding.html

[Maxim Dounin]

I believe it was demonstrated more than once that padding cannot prevent the BREACH attack. The random padding at most slows down the attack, while padding to some known block length can be bypassed by adding some extra bytes. Solutions that known to work for sure include compression of valuable data independently from user-controllable fields (for example, this is how CRIME was mitigated in SPDY) and random masking of valuable data.

Further, the ​pull request to add SSL_CTX_set_record_padding_callback() seems to suggests that the main goal is probably to confuse traffic analysis rather than to fight attacks like BREACH.

As such, I'm highly sceptical about this feature.

[Seirdy]

Padding isn't particularly useful for mitigating BREACH, but it is very useful for privacy in that it makes traffic analysis difficult. With encrypted DNS + OCSP Must-Staple + random record padding, the only easily-found information leakage for HTTPS connections will then be the hostname from SNI and dest IP; eavesdroppers will struggle to glean information more granular than that.

Combined with #2275, all an attacker will be left with is dest IP.

[Maxim Dounin]

Given introduction of ​ssl_conf_command in nginx 1.19.4 a while ago, padding to a fixed block size as supported by OpenSSL can be configured with something like:

ssl_conf_command RecordPadding 1024;

This is probably good enough to confuse traffic analysis. Not sure we still need this ticket open.

[Seirdy]

Is it possible to do this with BoringSSL? BoringSSL does support record padding but I don't think it works with ssl_conf_command directives.

[Seirdy]

Moreover, the OpenSSL command seems to support padding to match a desired multiple of bytes; it doesn't support more advanced forms of padding, e.g. random padding.

[Maxim Dounin]

Is it possible to do this with BoringSSL? BoringSSL does support record padding but I don't think it works with ssl_conf_command directives.

Sure it doesn't, as BoringSSL does not provide SSL_CONF_cmd() functionality.

Moreover, the OpenSSL command seems to support padding to match a desired multiple of bytes; it doesn't support more advanced forms of padding, e.g. random padding.

This suggests these forms are not needed, at least as seen by the authors of the padding implementation in OpenSSL. I wouldn't expect nginx will implement "more advanced forms of padding" unless there are good reasons to.

Either way, given that ssl_conf_command RecordPadding 1024; is available for almost two years now, and also padding can be configured manually via openssl.cnf since introduction of TLSv1.3 padding support in OpenSSL, yet never seen to be used in practice, I very much doubt it's something needed.