Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm gonna be writing an app that connects to a server with sensitive information and one of the main requirements is that only my app will be able to make the connection. There is no user supplied username or password involved. Btw, this will be on the Android platform, but that shouldn't be too relevant for this question.

I'm not too familiar with the inner workings of secure internet communications, however, I'm assuming the best approach will be to establish a SSL connection between my app and the server. The concern I have is: what prevents someone from monitoring what network traffic my app sends to the server to initiate the SSL connection and then sending the same traffic to open up their own connection (ie: duplicate the random number I send to the server that's used to create the session key)? I'm assuming these kind of things have been though of before and secured against, but I'm hoping someone can share some more insight into this to help deal with my concern.

Thanks, Harry

share|improve this question

migrated from Dec 6 '11 at 14:35

This question came from our site for professional and enthusiast programmers.

SSL is designed such that you don't need to worry about those details. As long as you're using SSL (the strongest encryption feasible for our solution) you're as protected from sniffers as you can be. – David Dec 5 '11 at 4:39

SSL prevents an attacker on the network from being able to see or manipulate the data in transit. However, this makes no guarantee that the user of the application hasn't modified the application. Any value stored in memory on the device can be easily obtained using a debugger.

In short you can never trust the client, and this isn't a problem that cryptography can solve, period.

share|improve this answer

First, an attack where someone relays traffic between two parties is called a man-in-the-middle attack. SSL protects against them if the two sides have been authenticated. Authenticating the two sides requires that you use SSL in a particular way, either (preferably) with client certificates or some application-specific method.

In any case, if you want to ensure that only your application will talk with the server, you need to store a secret inside your application. There has to be something that your application knows and the attacker does not know. It is not impossible to store secrets in an application that you distribute, but it is very very hard; it requires obfuscation. Note that the word “obfuscation” has several meanings when it comes to software; here you want obfuscation not in the sense of source code that's hard to read but in the sense of hiding a secret inside an application. The obfuscation bible is Surreptitious software by Christian Collberg and Jasvir Nagra if you want to go down this route. All obfuscation methods are cracked eventually, so your only hope is to stay abreast of the attackers and keep changing your techniques. Developing for obfuscation will easily multiply your development time by two or three, after you've acquired the necessary background. If anyone tells you that you can get it more easily, they're misguided or lying.

In summary, you cannot trust the client. If you have sensitive data, keep it on the server. Treat any response from the client as untrusted.

share|improve this answer

1- You need to get yourself familiarized with the principles of secure communications. There is no escape here.
2- As others have said NEVER TRUST THE CLIENT, even if you are writing the client.
3- For every communication you need to make sure who is on either side (on client side you need to make sure you are talking to the correct server, on the server you need to make sure you are talking to the client you are expecting to talk too). One of the many ways to do this is to use a combination of asymmetric and symmetric encryption, on the server you need to know [each] client's public key, on client you need to know your servers public key then you can exchange an RSA key or some symmetric key (specially if performance is an issue).

This is just a suggestion, you need to tweak it based on what you need.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.