我正在研究一些选项来保护来 self 们移动应用程序的流量，该应用程序目前正在通过 HTTP 请求向我们的服务器发送未加密的数据。
最明显的选择是使用 HTTPS/SSL，但是由于额外的网络流量(SSL 握手)和手机上的额外 CPU 负载，移动开发人员不愿意这样做。
我能找到的唯一可行的选择是使用预共享 key 来绕过握手的开销。因此，使用标准的 HTTP POST，我们会发送一个明文 API key 来识别移动应用程序，可能作为 HTTP header ，然后使用 PSK 加密 POST 数据并将其发送到服务器。服务器会从 API key 中查找 PSK，解密 POST，可能会进行一些验证以确保它看起来像好数据，然后将其传递给我们网络应用程序中的适当 Controller 。
这甚至是一个合理的选择吗？是否有更好的(或任何非 SSL)替代方案？
请注意，移动应用适用于黑莓和 iPhone，服务器端是 LAMP[php]。
最佳答案
嗯，
您的建议似乎是粗略地复制 SSL。我不是指握手例程、证书等，但最后，您仍然要来回加密每个请求，只使用 PSK，而不是使用 SSL 握手创建那种 PSK。这可能对您的健康有害。
这实际上取决于您要尝试做什么。如果您只在 xx 个请求中执行一次，那么在安全性和性能方面都可以。或者它可能非常危险。假设我捕获了该 API key ，伪造或稍微修改了请求并将其发送给您。然后怎样呢？
我明白开销的意义所在(如果您仍然加密数据，真的吗，您是否正在消除这一点？？)，但如果安全对您来说是个问题，我不会尝试在这里重新发明轮子并使用被广泛接受和证明的标准。 SSL 并不能解决所有问题，但您可能会遇到潜在的中间人攻击。
底线:重新实现或复制 SSL 将非常困难、耗时且成本高昂，更不用说您可能不会在第一次尝试时确保安全。不要去那里，使用SSL。这正是您所需要的
编辑: 此链接可能对 SSL 性能有用:A Study of the Performance of SSL on PDAs .其中，你会发现代价最大的操作，握手，通常不会每次都执行。
关于php - 通过公共(public)互联网安全发送数据的替代方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8452213/