2011-12-09 64 views
1

我正在研究一些保護來自我們的移動應用程序的流量的選項,該應用程序當前正通過http請求向我們的服務器發送未加密的數據。通過公共互聯網安全地發送數據的另一種方法

最明顯的選擇是使用HTTPS/SSL,但由於額外的網絡流量(SSL握手)和手機上額外的CPU負載,移動開發人員不願意這樣做。

我能找到的唯一有點可行的選擇是使用預共享密鑰來繞過握手的開銷。因此,使用標準的HTTP POST,我們會發送一個明文API Key來識別移動應用程序,可能是作爲HTTP Header,然後使用PSK加密POST數據並將其發送到服務器。服務器從API密鑰中查找PSK,解密POST,可能會做一些驗證以確保它看起來像是好的數據,然後將它傳遞到我們的Web應用程序中的相應控制器。

這是一個合理的選擇嗎?有更好的(或者任何非SSL)選擇嗎?

請注意,該移動應用程序是用於黑莓和iPhone,而服務器端是LAMP [php]。

+8

對此沒有使用SSL只是愚蠢的。 – BNL

+1

因此,而不是使用SSL,你想實現自己的? –

回答

4

那麼,

你是什麼建議似乎大致上複製的SSL。我並不是指握手例程,證書等,但最終,您仍然會使用PSK來加密每個請求,而不是使用SSL握手創建PSK類型。這可能會對你的健康有害。

這實際上取決於你想要做什麼。如果你只在xx請求中這樣做了一次,那麼就安全性和性能而言可以更好。或者它可能非常危險。假設我捕獲了該API密鑰,僞造或僅略微修改請求並將其發送給您。然後怎樣呢?如果你仍然在加密你的數據,那麼你真的會解決這個問題嗎?),但是如果安全性對你來說是一個問題,我不會嘗試在這裏重新發明輪子,使用廣泛接受和PROVEN標準。 SSL並不能解決所有問題,但是你在這裏有一個潛在的中間人攻擊。底線:重新實施或複製SSL將非常困難,耗時且成本高昂,更不用說在第一次嘗試時您可能不會保證安全。不要去那裏,使用SSL。這正是你需要的

編輯:此鏈接可能證明對於SSL性能很有用:A Study of the Performance of SSL on PDAs。在那裏,你會發現,最昂貴的操作,握手,通常不是每次都執行。

+0

感謝您的鏈接中的其他信息 - 我希望這是足夠的信息,勸阻其他開發人員使用非SSL解決方案。 – hafichuk

0

聽起來就像你試圖實現公鑰/私鑰Encrpytion。

我最好的建議是使用SSL或至少OpenSSL libraries。自己實現它會更困難,因爲你必須編寫自己的方法來處理非常大的整數數學。

3

a very similar question,幾天前遷移到Security.SE。

  • 什麼讓您認爲您使用SSL/TLS獲得的握手開銷將超過您自己的協議的開銷?
  • 您可以使用PSK with TLS
  • 您的環境是否適合使用預共享密鑰? (我的意思是,您可以輕鬆地在您的移動應用程序的每個實例中祕密分享您的密鑰)。

在嘗試提出SSL/TLS的替代方案之前,先對實際開銷進行測量,然後再考慮您的新解決方案是否會遭受相同的開銷。總的來說,很可能不會,您很可能不會像SSL/TLS一樣提供解決方案。