Nonces being used in SSL and MAC to prevent replay attacks I'm a bit confused in the way nonces are used in these processes to prevent replay attacks.
Heres How I think it works during SSL:

Nonces are exchanged during stage one of the handshake protocol. Nonces of the other party will be different so the keys will be different. The random numbers are used to create symmetric keys using the master_secret. Even if Eve could use the same random numbers as in the previous connection, the server will most likely not, therefore the keys will be different in the attempted replay connection.

Is that correct? I'm a bit confused how they work in MAC.
Well, you have it right in how nonces are used to make sure that the keys in different SSL sessions; this effectively prevents someone from taking an SSL record from one session, and injecting it into another -- because the keys aren't the same, it won't pass the integrity tests.

However, that's not the only place we care about replay attacks; we can also be concerned about someone taking an SSL record from one session, and replaying it latter in that same session.  Because the keys are the same, we can't use the above logic.

So, what SSL transmitter does when it computes the MAC for a record is logically prepend the current byte count; that is, the number of bytes that have passed through this SSL connection so far.  This byte count is not sent over the wire, but it is implied.  When the receiver gets the record, it also logically prepends its current byte count (which should match the transmitter's); and so it should compute the same MAC.  After processing the record, both the transmitter and the receiver updates its current byte count (based on how long the record was).

Now, if someone should replay that record, the receiver would then logically prepend its current byte count (which would not match what the transmitter prepended when it originally generated the record); because that count is different, the receiver would generate a different MAC, and so the record would be rejected.

That gives you the answer, I want to close with one clarification; you mentioned SSL; well, the current version of the protocol is known as TLS.  There are several versions (TLS 1.0, 1.1 and 1.2); TLS 1.2 handles the byte count slightly differently; however it does the same job.  There's also something known as DTLS; for that protocol, the count (which is a count of records, and not bytes) is explicitly sent within the record.