Home/ Questions/Q 6915657
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T09:30:09+00:00

I’m researching some options for securing the traffic from our mobile application, which currently

  • 0

I’m researching some options for securing the traffic from our mobile application, which currently is sending unencrypted data over an http request to our servers.

The most obvious option was to use HTTPS/SSL, however the mobile developer is reluctant to do this because of the extra network traffic (SSL Handshake) and the extra CPU load on the phone.

The only somewhat feasible option I can find is to use a pre-shared key to bypass the overhead of the handshake. So with using a standard HTTP POST, we’d send a cleartext API Key to identify the mobile app, probably as a HTTP Header, then encrypt the POST data with the PSK and send that to the server. The server’d lookup the PSK from the API Key, decrypt the POST, presumably do some validation to ensure it looks like good data, then pass it to the appropriate controller in our web app.

Is this even a plausible option? Are there better (or any non-SSL) alternatives?

Note that the mobile app is for both Blackberry and iPhone, and the serverside is LAMP[php].

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well,

    what are you suggesting seems like roughly replicating the SSL. I don’t mean the handshake routine, certificates etc, but in the end, you’re still going to encrypt every request, back and forth, only with PSK instead of creating the sort-of PSK with SSL handshake. And that can be bad for your health.

    It really depends on what is it you’re trying to do. If you would do this only once in xx requests, it CAN be ok in terms of security and better in terms of performance. Or it may be very dangerous. Say I catch that API key, forge or just slightly modify the request and send it to you. What then?

    I see the point with the overhead (and are you eliminating this, if you still encrypt your data, really??), but if a security is an issue to you, I would not try to reinvent the wheel here and use widely accepted and PROVEN standard. SSL doesn’t solve everything, but you have a potential man-in-the-middle attack here.

    Bottom line: Reimplementing, or replicating SSL is going to be hard, time consuming and costly, not to mention you will probably not make this secure on your first attempt. Don’t go there, use SSL. It’s exactly what you need

    Edit: This link may prove useful as for SSL performance: A Study of the Performance of SSL on PDAs. Among there, you will find that the most expensive operation, the handshake, is not performed every time, usually.

    • 0