MITM and replay attacks prevention

Question

I have a client (a mobile app) and a server, the app connects to the server via SSL.

The server uses a self-signed certificate, and the client has a file (I'm not entirely sure what, something to do with bks and hostname verification) that validates the certificate.

From what I've read this should prevent MITM attacks, in which case apart from physical access to the client or physical access/hacking the server means the session token is impossible to get to use in a replay attack.

Because users don't want to want to log in even once a month, the token lasts forever (unless they log out or log in on a new device), I can only think of one way around this, which is with every request a new token is returned, but then an attacker might be able to steal the victims session.

So, questions:

1) Does a self-signed certificate with some sort of validation on the client (assuming neither have been tampered with) protect against MITM attacks?

2) If not, is it possible to prevent replay attacks with persistent session tokens or stop hijacking if tokens are renewed constantly?

I'm not worried about tampering on the client side as the data as although the users data is private it couldn't be used to cause any more damage.

EDIT: To clarify, I mean replay attacks using the session tokens, basically I'm trying to find out if using SSL (to stop attackers from getting the session token) is enough to prevent replay attacks, or whether I need additional validation on the session tokens/clients, and if so what?

Answer 1

Min-in-the-Middle attacks in SSL are prevented by the client "making sure" that it uses the correct, genuine server public key. This "making sure" element is what certificate validation is about. When the server certificate is self-signed (i.e. not issued by a trusted certification authority), then such validation must be done some other way. A simple method, which works, is when the client already knows the server certificate (it is embedded in its own code): the certificate from the server is validated by a simple bit-to-bit comparison. There are many ways to do such a validation, and many ways to botch it, so I cannot say whether your specific method is correct or not.

Replay attacks are a completely different beast, and are unrelated to the self-signedness of the server certificate. To make the story short, replay attacks in SSL don't work, because both client and server include random values in their initial handshake messages (the ClientHello and the ServerHello -- see the handshake overview in the standard) and these random values are used in all subsequent cryptographic operations, preventing the raw reuse of previously captured network traffic (which is what replay attacks are about). The same data (e.g. the same session token) will be reencrypted anew, with a new session key for each new SSL connection.