0

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.

2

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
1
  • 1
    Honestly, just disabling HTTP compression on sites containing a secret is enough. Static assets or sites without user-supplied data can be sent compressed. – MechMK1 May 14 '20 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.