標籤:隨機數 解析 ios 處理 否則 中間 blog hash演算法 過程
我們一般使用 AES 256 對內容做加密,這裡 AES 密鑰的管理也有兩種方式,其一是在用戶端使用固定的密鑰,為了加大破解的難度,我們可以對密鑰本身做多次加密處理,使用時再在記憶體裡解密出來真正的密鑰。其二是每次會話都使用不同的密鑰,原理類似 Forward Secrecy,即使流量被記錄,將來被暴力破解,也能極大的增加攻擊者破解的時間成本。
http://mrpeak.cn/blog/https-mitm/
https原理:認證傳遞、驗證和資料加密、解密過程解析
1.瀏覽器將自己支援的一套加密規則發送給網站。
2.網站從中選出一組密碼編譯演算法與HASH演算法,並將自己的身份資訊以認證的形式發回給瀏覽器。認證裡麵包含了網站地址,加密公開金鑰,以及認證的頒發機構等資訊。
3.瀏覽器獲得網站認證之後瀏覽器要做以下工作:
a) 驗證認證的合法性(頒發認證的機構是否合法,認證中包含的網站地址是否與正在訪問的地址一致等),如果認證受信任,則瀏覽器欄裡面會顯示一個小鎖頭,否則會給出認證不受信的提示。
b) 如果認證受信任,或者是使用者接受了不受信的認證,瀏覽器會產生一串隨機數的密碼,並用認證中提供的公開金鑰加密。
c) 使用約定好的HASH演算法計算握手訊息,並使用產生的隨機數對訊息進行加密,最後將之前產生的所有資訊發送給網站。
4.網站接收瀏覽器發來的資料之後要做以下的操作:
a) 使用自己的私密金鑰將資訊解密取出密碼,使用密碼解密瀏覽器發來的握手訊息,並驗證HASH是否與瀏覽器發來的一致。
b) 使用密碼加密一段握手訊息,發送給瀏覽器。
5.瀏覽器解密並計算握手訊息的HASH,如果與服務端發來的HASH一致,此時握手過程結束,之後所有的通訊資料將由之前瀏覽器產生的隨機密碼並利用對稱式加密演算法進行加密。
http://blog.csdn.net/clh604/article/details/22179907
轉:iOS 用戶端 HTTPS 防中間人攻擊實踐