I don't think this is true. I think you're assuming that the vulnerability has anything to do with how your app works, when it in fact targets browser behavior. The attacker uses (e.g.) Javascript, loaded from some random site, to generate a bajillion connections to your site, each of which will bear session cookies.
The 256 byte padding doesn't help either, because of the Fluhrer-McGrew biases.
Are the Fluhrer-McGrew biases actually exploitable? After all, they've been known for over ten years, but no one seems to have been particularly concerned about them before.
Yes, the summary of the full Patterson/Bernstein paper says the attacks on the Fluhrer-McGrew biases are easier in practice to exploit than the first 256 bytes --- which also were known for over ten years but weren't taken seriously until last year.
That still assumes you use session cookies at all. As I said, you can keep authentication entirely within the confines of the websocket connection, deliver only non-user-specific static assets over HTTP(S), and persist your authentication token client-side in localStorage/sessionStorage, thus avoiding cookies entirely. Which is actually the best practice for libraries like SockJS, since they rely on (and encourage the use of) cross-domain connections that can't see your cookies.
Of course, using localStorage (which doesn't have the equivalent to cookies' HTTPOnly attribute) makes the Javascript-injection attack even more effective--but that's a bit of an airtight hatchway problem[1]. If you already have control of the user's DOM, you can just make it look like they were logged out and phish their credentials out of them.
The 256 byte padding doesn't help either, because of the Fluhrer-McGrew biases.