Opened 7 years ago

Last modified 3 years ago

#9493 new enhancement

Implement an option to pad HTTPS requests against traffic analysis

Reported by: pde Owned by: pde
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: micahlee, mikeperry, arma, zyan, lisacyao, agl@…, schoen, g.koppen@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


One of the tools that dragnet surveillance actors have against both HTTPS and Tor is message length analysis. In general message lengths can be used to determine which paths on a give HTTPS domain a browser might be requesting (summed, but probably extractably so, with the lengths of messages the client might be POSTing to the server), and to perform end-to-end traffic analysis of Tor circuits.

HTTPS Everywhere is in a position to pad requests to servers to some round number of bytes (N byte blocks, powers of two, floors of powers of some number lower than two). We could do this by sticking in a new X-Padding: HTTP header. We could also write an RFC specifying that servers should pad their responses in a similar way if they see the X-Padding header. Perhaps we could persuade some servers to respect this.

Would this be valuable? What padding scheme would we want? Powers of two seems too costly for long messages, maybe we could have a hybrid that used 512 byte blocks for short messages and powers of 1.3 (15% overhead) or something for long messages. Perhaps we could even collaborate with some academics to figure out a good padding scheme based on message length spectra for gmail, wikipedia, or other major sites.

Child Tickets

Change History (3)

comment:1 Changed 7 years ago by pde

Cc: schoen added

comment:2 Changed 7 years ago by gk

Cc: g.koppen@… added

comment:3 Changed 3 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.