Opened 5 years ago
Last modified 5 years 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 )
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 (2)
comment:1 by , 5 years ago
Description: | modified (diff) |
---|
comment:2 by , 5 years ago
Priority: | major → minor |
---|
Note:
See TracTickets
for help on using tickets.
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.