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?

1 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.

  • I have a signature (I think) from the server, which is used by the SSL socket factory in android and checked against whatever an server sends to it, only the certificate on the server is accepted. In which case MITM are impossible I think Regarding replay attacks, sorry please see my edit, I meant replay attacks with session info, not SSL.
    – user2918
    Jun 6, 2013 at 11:24
  • I have heard that BlueCoat is able to spoof the Cert to a MITM - how is that done?
    – user93353
    Jun 7, 2013 at 12:01
  • BlueCoat relies on the installation on the client system of the public key of a certification authority that BlueCoat controls -- BlueCoat issues, on the fly, a fake certificate for the server, and the client trusts it because it trusts the installed CA key. Jun 7, 2013 at 21:47

You must log in to answer this question.