Originally asked on https://crypto.stackexchange.com/questions/24430/security-at-application-layer but was suggested to ask here instead.

I saw lots of questions asking about encryption over http, such as this. Most of the responses I saw said there is no way to verify server's identity so vulnerable to MitM attack.

My question below will be slightly different, because it is asking about mobile environment, where I assume the app is downloaded from AppStore or PlayStore. In this way, I can assume the code is verified and not modified by hacker and the public key of server bundled with the app is not modified either so that it can verify server's identity.

Given these guarantees, is it possible to do encryption at application layer and is there any existing libraries to do it?

More specifically, I am writing some app that talks to HTTP server. The server is hosted on some cheap plans where no HTTPS is available. Assuming the server handles HTTP requests using PHP or Python, is it possible to implement the client and server, so that they do some handshake at the beginning of the session over HTTP, to agree on some encryption keys; afterwards, all messages are encrypted using the keys. So from hackers point of view, they see the HTTP traffic between client and server and they see some basic fields in HTTP headers, e.g. host and endpoint, as plaintext but everything else are just encrypted as HTTP body or some URL argument.

Is that possible and is there any libraries doing that easily? Intuitively speaking, it is just implementing TLS in the application level, so theoretically it is totally possible and has the same security strength as TLS. Do I miss any security holes here?

  • If someone does some reverse engineering on your application and get the public key will they not be able to pretend that they are "genuine" ? – sir_k Mar 17 '15 at 10:46
  • @FlorinCoada They won't be able to sign the data because they don't have the private key. The signature verification would fail for SSL/TLS anyway. – RoraΖ Mar 17 '15 at 11:28
  • If your server has OpenSSL installed: Python Library PHP Library If it doesn't, I would find another server provider. – RoraΖ Mar 17 '15 at 11:32

the first security hole is your shared "el-cheapo" server. if you can not trust your machine, you can not trust your applications.

what this means is that if you have no controle over the machine itself, adding security to it is pointless, an attacker will just attack your webserver instead of your connection and makes sure he can do anything he/she wants to do and "Steal all the data!"

have a look at the OWASP pages. they offer much information about how to secure any (web-) program.

If in the end all you want to do is have a limited set of clients use your "app" and do it secure, you could look at implementing an SSH client / server architecture (basically making SSH do all the security and connection and just use it as a tunnel for your purpose)

good luck

  • The security hole you pointed out is very helpful since I never thought about it. However, I would say, even though it is some cheap shared plan, it can still be hosted by not-so-small companies, such as GoDaddy, where hacking to the server is not super trivial. I think I can have some sort of trust on the machine. – icando Mar 18 '15 at 0:51
  • do not make the mistake of trusting someone only because there big. companies like godaddy have more secure (read: more expensive) hosting options for the clients that want higher level of security. Cheap is cheap for a reason, mostly because more ppl use the same "hardware". Trust should be earned not assumed. – LvB Mar 18 '15 at 10:30
  • As you said, the cheap is because more people share the same machine. This has no logical relation to whether it is more or less secure. You argument here is just pointless and only for the sake of arguing. I don't see they deliberately maintain two set of systems to make cheap ones insecure. As long as hacker can't login to the machine and access my home directory, what else do I need to concern? If they are able to hack into SSH, then what else on earth could be better? – icando Mar 18 '15 at 16:46
  • the less security is due to more surface area for an attack (from within a system it is much easier to attack than from a neighboring system, if only because on the same system I can read memory and temp files.) (ergo. logic why its 'less' secure. you need to trust not only your provider; but also all of the clients of that provider that share your 'box'). they maintain more than 2 sets of systems, because different users have different needs. and different security profiles! Your reaction is telling for someone who has not made a security analysis if his needs/system. I rec. you get 1. – LvB Mar 18 '15 at 20:53
  • Good point for reading memory. I can imagine if I read the private key into memory and forget to zero out the memory after using, hacker on the same machine might be able to read it by repeatedly allocating memory. What else could potentially cause the private key leaked? Assume I carefully zero out the memory after using, is there any other holes? Is Linux's trustworthy? Can a ordinary user raise their privilege to root on a Linux machine and see other users' file? – icando Mar 18 '15 at 23:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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