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?)