ession applies on the request body only, not the header. So secrets in the header, in particular cookie values, are safe from that one.
Since there are "probe requests", then the attack requires some malicious code in the client browser; the attacker must also observe the encrypted bytes on the network, and coordinate both elements. This is the same setup as for CRIME and BEAST.
It is unclear (from the article alone, which is all I have right now to discuss on) whether the compressed body is one from the client or from the server. "Probe request" are certainly sent by the client (on behalf of the attacker) but responses from the server may include part of that which is sent in the request, so the "chosen plaintext attack" can work both ways.

In any case, "BREACH" looks like an attack methodology which needs to be adapted to the specific case of a target site. In that sense, it is not new at all; it was already "well-known" that compression leaks information and there was no reason to believe that HTTP-level compression was magically immune. Heck, it was discussed right here last year. It is a good thing, however, that some people go the extra mile to show working demonstrations because otherwise flaws would never be fixed. For instance, padding oracle attacks against CBC had been described and even prototyped in 2002, but it took an actual demo against ASP in 2010 to convince Microsoft that the danger was real. Similarly for BEAST in 2011 (the need for unpredictable IV for CBC mode was known since 2002 as well) and CRIME in 2012; BREACH is more "CRIME II": one more layer of pedagogy to strike down the unbelievers.
Unfortunately, a lot of people will get it wrong and believe it to be an attack against SSL, which it is not. It has nothing to do with SSL, really. It is an attack which forces an information leak through a low-bandwidth data channel, the data length, that SSL has never covered, and never claimed to cover.
The one-line executive summary is that thou shalt not compress.

A:

BREACH, like CRIME, is a co