1. the attacker can see (but not decrypt) the victim's TLS traffic to example.com

2. an attacker-controlled website makes the victim send many different invalid requests to example.com, each of which gets an error message

3. some data in each request is attacker-controlled, but authentication data in headers is filled in by the victim's browser

4. example.com compresses response data before encrypting it

5. because repetitions affect compression, the response size is smallest when the authentication data matches part of the attacker-controlled data

6. after enough requests, the attacker knows the authentication data to login to example.com as the victim

One workaround for CVE-2012-4929 was to set up the server so that an error message never depended on the request data. Before CVE-2012-4929 was announced, people thought it was sufficient to sanitize the error message (i.e., avoid XSS) but CVE-2012-4929 prompted a shift toward producing exactly the same error message for all invalid requests. (Not sure, but I think this was the original motivation for Google's famous "That's an error. That's all we know." messages.)

There were better CVE-2012-4929 defenses later, but the cargo cult had already formed. (Some subset of) a generation of developers believed that customized error messages were Very Bad because they enabled account takeover.