10

On the answer to my previous question about RC4 vulnerabilities in TLS, Thomas Pornin gave a great answer, in which he said:

One way to "fix" RC4, which has been suggested many times, is to drop the first 256 (or 512 or 1536 or whatever) bytes of output, since these are the most biased of them (the graphics in the slides show that quite clearly). But this would not be compatible with RC4-as-we-know-it

Curious by this and a comment on HN which makes an interesting suggestion, I am wondering if the browser (or even a browser plugin) can pad HTTP requests, so that the first 256 bytes (or 512 or whatever) are just some useless header. e.g.

GET / HTTP/1.1
X-Padding-Header: <256 bytes of random text>
Accept: */*
...

As far as I'm aware unknown headers are ignored(?), and this would ensure the first bytes in the request are both useless (no value in guessing them) and random.

Is this a silly workaround that might create more harm than good? Or if browsers are going to fix it they might as well upgrade to TLS 1.2?

(p.s. of course if the URL itself contains sensitive information and is long enough, it will be present in the request before the header, so this "protection" might not help with this, but maybe just good enough to protect the cookies?)

Community
  • 1
Yoav Aner
  • 5,299
  • 3
  • 24
  • 37

2 Answers2

9

As @D.W. points out, this would work -- to protect the cookie. The path itself comes before the headers, and may also be at risk, if it contains sensitive data at a predictable place (this is not a common case nowadays, but URL rewriting for session management used to be popular).

A variant would look like this:

GET / HTTP/1.1
X-Header-Padding1: <X random padding bytes>
Accept: */*
Cookie: ...
...
X-Header-Padding2: <Y random padding bytes>

By choosing X and Y randomly, but such that X+Y is fixed, the emplacement of the cookie in the stream would change between requests, in a way which attackers cannot detect (since the total length of the headers is constant). While not as satisfying as simply dropping the first 256 bytes of the request, this ought to be enough to bring back the effort of bias-based attacks into the billions of requests, instead of millions, and it could be done with less than 256 extra bytes per request (having X+Y = 32 should do that).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
5

This would be safe against all attacks that I know of.

From a security perspective, it is not quite equivalent to dropping the first 256 or 512 bytes. With your proposal, the attacker has some known plaintext (e.g., from the GET line and the X-Padding-Header), whereas if you drop the first 256 bytes, the attacker doesn't get known plaintext in those positions. Theoretically, if knowledge of some of the first 256 bytes of output from RC4 allowed an attacker to recover the key, then your scheme would be insufficient. However, I'm not aware of any attack on RC4 of that form. In practice, all of the known attacks on RC4 say that one or two of the first bytes of output from RC4 are slightly biased, so they don't hide the plaintext quite as well as you'd want -- but this bias does not allow an attacker to deduce the RC4 key. So from a security perspective, in practice, your scheme is probably about as good as dropping the first 256 bytes of RC4 output.

However... from a performance perspective, you've just added 256 bytes to every request sent over SSL. That's very bad for performance. This performance problem is likely enough to kill this proposal; it's probably not a viable candidate for deployment.

If browsers want to fix it, it would be far better to simply update to TLS 1.2 and safer ciphersuites.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 3
    Note that this random padding has to be added only for the first request after the handshake. Most requests use connections which have been kept alive, thus farther away into the RC4 stream. – Thomas Pornin Mar 13 '13 at 11:11