CRIME and BREACH (note there's an "R" in there) use TLS level compression to "leak" information about the encrypted data. Very shortly: If you can control part of the data stream and send different data, when you send data that is the same as part of the stream that you do not control the output will be smaller (as compression will de-duplicate them) and you'll know the contents of the part that you don't control.
BEAST takes advantage of a flaw in CBC encryption in TLS 1.0. It's mostly impractical, but a demonstration exploit has been created and definitely works. There are two potential fixes for this, disable CBC Encryption (which includes basically all "good" encryption for TLS, leaving you with RC4 which has vulnerabilities of it's own, including leaking plaintext) or disabling TLS 1.0 and using only TLS 1.1 (or newer, ie 1.2).
The attacks are mostly impractical, but if you're in a high security environment (like PCIDSS or EHR) you'll need to disable TLS Compression and TLS 1.0 CBC Encyrption. The TLS Compression is completely separate from content compression (ie Deflate and GZip). As of the latest stats, about 2/3 of HTTPS Servers are "vulnerable" to BEAST, about 1/6 to CRIME. Keeping things in perspective, 1/3 are vulnerable because they're running a stupid configuration that doesn't properly protect data at nearly any level.
In response to your comment: What are commonly marketed as "SSL Certificates" are actually x509 Certificates and have nothing to do with SSL other than being used by the protocol. When you're getting a Cert, make sure it's either 2048 or 4096 bits (the former is very common) RSA or 384+ bit ECDSA. Certificates use asymmetric encryption, which is horridly slow - for that reason their not used to encrypt the data transported over SSL/TLS. They're used only for agreeing on a key for the stream cypher to use.
Common stream cyphers are RSA, RC4, Camellia, and DES/3DES. This is where you run into the 64-bit, 128-bit, 256-bit encryption - it's the key size of those stream cyphers. RSA is the "best" of the widely supported cyphers from a SysAdmin's viewpoint - but it suffers from the CBC issue in the BEAST attack above. RC4 "leaks" plaintext. Camellia is pretty great, but not universally supported, so you can't rely it in a public environment. DES/3DES is broken and shouldn't be used anymore, ever.
You're essentially stumbling over the same issue as millions of others: The choice between universal support and functional security. You can't have both right now. Disabling TLS Compression is a bit of a no-brainer in my opinion, as content compression makes up most of the difference - thus little cost for "fixing" the problem. But the stream cypher choice is pretty much: implement flawed security with RC4 or AES, or require TLS 1.1+ and break your website for half the Internet.
Footnote: Don't worry, this will all seem like spilled milk when quantum processors hit 128+ bits and make cracking "SSL Certificates" trivial. We're probably less than 10 years away from that, currently at 4-bits.