Are SSL encrypted requests vulnerable to Replay Attacks? If so, what are good options to prevent this?
The SSL/TLS channel itself is protected against replay attacks using the MAC (Message Authentication Code), computed using the MAC secret and the sequence number. (The MAC mechanism is what ensures the TLS communication integrity). See TLS 1.1 specification Appendix F.2:
To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings.
EDIT: As @CodesInChaos points out, the handshake must also be taken into account, otherwise the whole TLS connection could be replayed (not just some records, which is what the MAC and sequence number would protect against). If an attacker replayed the same
Client Hello message, the server would return a
Server Hello with a different server random value thereby altering the rest of the key exchange. In addition, in RSA key exchange mode, only the initial legitimate client would know the pre master secret it has encrypted; in DHE key exchange mode, the client and server randoms are signed together in the server key exchange message (hence the importance of good random numbers there too). (There's a bit more on these two modes in this question.)
It's not clear from your question what you're trying to protect against replay attacks. Typically, this would be a message sent above the SSL/TLS layer, used by your application.
The encryption provided by SSL/TLS certainly prevents an eavesdropper from seeing that application request, and thus from replaying it with their own separate SSL/TLS connection.
However, SSL/TLS on its own doesn't necessarily prevent the legitimate initial user from replaying a request. Protocols and applications that require this additional level of protection tend to have nonce-based mechanisms at the application level to address this problem (which is rather independent of SSL/TLS, although preventing eavesdropping helps).