Notation
1. Alice and Bob are the two communicating parties denoted A and B, while Mallet, is the attacker and is denoted by M.
2. If a message X is encrypted using a key it is denoted key[X].
3. MAC[X] denotes X's MAC value.
4. Hash[X] denotes X's hash function value.
5. Garble[X] denotes a garbled message X.

Preventing Identity Fraud
Lets say that Alice wishes to contact Bob and Bob has a certificate which contains his public key:
A->B: Hi.
B->A: Good day, I'm Bob, bob's-certificate.
However anyone can tap the communication line between Bob and Alice and so Mallet can do the following:
A->B: Hi.
M->A: Good day, I'm Bob, bob's-certificate.
But, since Mallet doesn't have Bob's private key he will not be able to authenticate himself as Bob:
A->B: Hi.
B->A: Good day, I'm Bob, bob's-certificate.
A->B: Yeah Right!
B->A: Alice, It's really me
bobs-private-key[ Hash[Alice, It's really me] ].
What Bob has just done is called a digital signature. Only Bob's public key can decrypt the second part of his message. Alice, using the public key in Bob's certificate, can decrypt the second part of the message and use the hash function on the first part and compare the result with the value in the decrypted message. (A good hash function is MD5). Bob and Alice must agree on the hash function first, but this is not shown here.
Mallet doesn't know bobs-private key and therefore will be discovered for the fraud he is.

Preventing Garbling Attacks
Alice has determined that Bob is really himself and now wants to exchange a secret key for the symmetric encryption algorithm that will be used in further communication (The most common symmetric encryption algorithm is DES and its variants):
A->B: All right Bob, keep this to your self bob's-public-key[secret-key]
B->A: secret-key[bob's message]
However Mallet can be innovative and do the following:
A->B: Hi.
M->B: Hi.
B->A: Good day, I'm Bob, bob's-certificate.
M->A: Good day, I'm Bob, bob's-certificate.
A->B: Yeah Right!
M->B: Yeah Right!
B->A: Alice, It's really me
bobs-private-key[ Hash[Alice, It's really me] ].
M->A: Alice, It's really me
bobs-private-key[ Hash[Alice, It's really me] ].
A->B: All right Bob, keep this to your self bob's-public-key[secret-key]
M->B: All right Bob, keep this to your self bob's-public-key[secret-key]
B->A: secret-key[bob's message]
M->A: Garble[ secret-key[bob's message] ]
Alice doesn't know that Mallet has been passing the information between her and Bob, so when Mallet sees that a secret key has been exchanged he garbles the communication in hope that Alice, which trusts Bob now, will believe the garbled message and may respond to it. Mallet doesn't know the secret key and may not produce a valid message, but there is always the chance that he will.
To counter such an attack a MAC is used:
A->B: All right bob, keep this to your self: bob's-public-key[secret-key]
secret-key[ some message, MAC[some message] ]
Now Bob and Alice can confirm the authenticity of their messages with MAC computations, comparing the received MAC value with the computation results. Mallet can try to guess the MAC values for his garbled message but with a good hash function Mallets chances are practically zero.

Preventing Replaying Messages
Mallet might not give up, and replay recordings of previous communications. This may cause quite a lot of trouble. However, if random elements such as the time of the message are added to every message and checked, replayed messages can be detected.
Furthermore, using a sequence number in computing the MAC prevents replay attacks. If an attacker wishes to record a message and replay it, the receiving party won’t accept it because the counter in the message’s MAC won’t be synchronized with the receiver’s counter.

Preventing Cut and Paste Attacks
The cut-and-paste attack means that a person in the middle cuts an encrypted cipher text from some packet and pastes it into the cipher text of another packet, so that the receiving party will unintentionally give away its plain text after decryption.
SSL v3.0 stops cut-and-paste attacks by using strong authentication prior to each encrypted transfer packet. This provides an effective defense from enemy modification.

Preventing CipherSuite rollback attacks
An active attacker could force the parties to use a low security encryption algorithm by changing the unprotected list of CipherSuites supported by the client.
This is known as the CipherSuite rollback attack. SSL v3.0 fixed this weakness by using a pending CipherSuite state. Instead of using the negotiated CipherSuite at the moment, they continue to use their original initialized CipherSuite state.
It means that all the cryptographic parameters that the server and client have negotiated are kept in the pending CipherSuite state. After negotiation is complete, the client and server exchange the change_cipher_spec message to indicate to each other to move the pending state to the current one. Then, finally they exchange the finished message, which is already protected. This allows the client or server to reject using a weaker encryption algorithm by sending a handshake_failure alert instead of the finished message.

Preventing Version rollback attacks
In this kind of attack, the attacker modifies the version given in the client_hello message to SSL v2.0. This modification forces the server to choose the weaker version of SSL, which has more breaches.
So, if both endpoints support SSL v2.0 and SSL v3.0, an attacker can force them to use SSL v2.0 instead of v3.0. In this situation, each party has the ability to detect that the other endpoint supports SSL v3.0. Client implementation, which supports SSL v3.0, inserts some v3.0’s indicator values into the RSA encryption. On the other side, servers, which support SSL v3.0, will be able to detect those indicator values.
Note that a version rollback attack is only detected in RSA key-exchange. Actually, it is enough because if an attacker wants to modify the version from 3.0 to 2.0, he has to use RSA key-exchange algorithm. Using a different key-exchange algorithm couldn’t be taken into consideration because SSL 2.0 doesn’t support it.

Preventing Dictionary attacks
This attack works in a situation when an attacker knows some of the plain text in the original message. In this case, an attacker would try to encrypt the known part of the plain text with every possible key until he found occurrences in the cipher text itself. If one is found, the whole message can be decrypted with the suitable key.
SSL prevents this attack by using strong encryption algorithms, like IDEA (128 bits) or 3DES (168 bits).

Traffic attacks
An active attacker can discover all the exchange messages’ length by examining the unprotected current IP header fields. More than that, the destination and source IP addresses are also unprotected. Those parameters can teach what the parties are interested about and what kind of services are in use. This kind of attack is relatively harmless, so SSL v3.0 doesn’t attempt to fix it.

Short-block attacks
When the final message block contains 1 byte of plain text and the remainder of it is filled with padding, this encrypted block is relatively easy to decrypt.
In fact, SSL is not infected with this attack, because it doesn’t use short blocks.