最近在思考安全性的問題。情景是：服務器和客戶端之間的數(shù)據(jù)通訊（更確切的是，主要是服務器給客戶端傳遞數(shù)據(jù)）。如果使用https的話，不可避免的是每次鏈接都會有更多的握手步驟，帶來的時間開銷，會大大的降低移動端的用戶體驗吧。而且，用經典的ASIHttprequest似乎也不支持https╮(╯_╰)╭。不知道大俠們有些什么更好的建議？
2 回答
泛舟湖上清波郎朗
TA貢獻1818條經驗 獲得超3個贊
服務器端與客戶端先共同約定好一個密鑰K，客戶端可通過SFHKeychainUtils等工具加密存儲K；
服務器端加密時，可獲取當前unix時間戳，假設為T，則加密過程中可使用K-md5(T)-K（或任意其他規(guī)則，只要將T混淆到密鑰中即可）為密鑰，進行加密，并將加密時的時間戳T或md5(T）傳給客戶端；
客戶端根據(jù)相應的規(guī)則拼接好密鑰后，進行解密。
這樣做的好處是，即使密鑰K或任意一次會話過程中的密鑰被破解，仍然無法完全對所有會話進行解密，必須同時知道K、密鑰拼接規(guī)則以及加密方法才可完全破解。
斯蒂芬大帝
TA貢獻1827條經驗 獲得超8個贊
連接流程：
1. 客戶端生成一個隨機的密鑰K(當然K需要足夠強)，將它用公鑰加密，然后發(fā)送給服務器
2. 服務器用私鑰解密得到K
3. 二者直接使用AES（密鑰為K）加密通信。
優(yōu)點：安全(除非入侵服務器拿到私鑰、或者破解久經考驗的RSA/AES算法）、快速（只有第一次來回需要RSA解密稍慢）。
缺點：需要一次握手（但可以解決：握手的來回，實際上可以用密鑰K來進行加密額外發(fā)送數(shù)據(jù)）。
- 2 回答
- 0 關注
- 186 瀏覽
添加回答
舉報
0/150
提交
取消