1

Section 5.4 of the TLS 1.3 specification describes record padding.

One of the mitigations for BREACH is to add random padding.

Therefore, I'm wondering:

  1. Does TLS 1.3 require random record padding? I'm also unclear on if this padding is optional or required, and if it is always random.
  2. If TLS 1.3 random record padding is done, am I correct in thinking that it does mitigate BREACH?

Assuming both of those questions are answered affirmatively, I believe that would mean that any site that uses TLS 1.3 (and supports no earlier version of SSL/TLS) would not be vulnerable to BREACH.

Community
  • 1
candrews
  • 107
  • 1

1 Answers1

3

This article, under BREACH sums it up pretty well.

BREACH targets HTTP compression, not TLS compression

With that said, the random record padding can be done on a higher level of encapsulation and not on the TLS record itself. You do not want to be obscuring the length of the record but the whole response.

Here are the preventive measures mentioned in the post above,

  • Disable HTTP compression
  • Separate secrets from user input (these secrets can be taken as a CSRF token)
  • Randomize secrets per request
  • Mask secrets (effectively randomizing by XORing with a random secret per request)
  • Protect pages against CSRF
  • Hide the length (by adding random numbers of bytes to responses)
  • Limit the rate of requests
mallocation
  • 1,668
  • 5
  • 20
  • 2
    Honestly, just disabling HTTP compression on sites containing a secret is enough. Static assets or sites without user-supplied data can be sent compressed. –  May 14 '20 at 10:11