Opened 4 years ago

Last modified 19 months ago

#1977 new enhancement

Implement TLS 1.3 random record padding to mitigate BREACH

Reported by: Craig Andrews Owned by:
Priority: minor Milestone:
Component: nginx-module Version: 1.19.x
Keywords: Cc:
uname -a: Linux irrational 5.4.32-gentoo-x86_64 #2 SMP Thu Apr 16 10:45:23 EDT 2020 x86_64 Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz GenuineIntel GNU/Linux
nginx -V: nginx version: nginx/1.17.10

Description (last modified by 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

Change History (7)

comment:1 by Craig Andrews, 4 years ago

Description: modified (diff)

comment:2 by Maxim Dounin, 4 years ago

Priority: majorminor

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.

comment:3 by Seirdy, 2 years ago

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.

comment:4 by Maxim Dounin, 20 months ago

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.

comment:5 by Seirdy, 19 months ago

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.

comment:6 by Seirdy, 19 months ago

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.

comment:7 by Maxim Dounin, 19 months ago

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.

Note: See TracTickets for help on using tickets.