剛了解這些原理，不是專業人士，所以不懂，望指教。

一般用的RSA+AES混合加密演算法，密鑰是隨機的嗎？不會存在直接用帳戶密碼（口令）來作為密鑰加密數據的吧？

加解密的密鑰和用戶帳號的密碼（口令）有一定的相似或者關聯嗎？

比如現在一個黑客截取了被HTTPS加密後的數據包，同時知道我的帳號密碼了（但是他無法登陸帳號，因為有登陸保護），用暴力破解，是否能更快破解加密數據的密鑰出來呢？

密鑰是隨機生成的，和賬戶密碼沒有關聯。題主提到的RSA演算法，在這個問題里，RSA不僅僅充當認證演算法，還充當密鑰交換（Key Exchange）演算法。

RSA認證演算法

客戶端請求伺服器RSA數字證書，伺服器將自己的證書、給自己簽名的二級CA證書、給二級CA簽名的一級CA證書，一股腦發給客戶端。客戶端驗證以上三個證書形成的證書鏈，信任的源頭就是操作系統/瀏覽器早已安裝的一級CA證書明文公鑰。認證完成會進入下一個環節，RSA密鑰交換演算法。

RSA密鑰交換演算法

客戶端調用偽隨機函數PRF，PRF返回一串偽隨機字元串，字元串被客戶端用伺服器RSA證書公鑰加密，發給伺服器。伺服器使用RSA證書私鑰解密，獲取明文字元串。至此雙方共同分享了一個共同的秘密，「偽隨機字元串」，雙方以此為素材，共同推導出AES對稱加密/解密「密鑰」，推導過程略。

偽隨機函數

完全隨機函數很難實現，所以才有了偽隨機函數的叫法，意思是接近隨機。為了讓PRF輸出的字元串最大可能隨機，可以將用戶滑動滑鼠的軌跡取樣生成隨機素材，也可以以當前時間+ 隨機數的組合，然後選擇感興趣素材為輸入量，運行Hash函數，得到偽隨機字元串。

用戶身份認證

完成了以上安全通信準備工作，一個HTTPS加密通道就建立了起來。

為了讓用戶能訪問自己的賬戶，需要先驗證用戶的身份。

為了最大限度保護用戶密碼安全，在任何場合下絕對避免用戶密碼在Internet上傳輸，即使有HTTPS保護也不行，甚至用戶明文密碼在傳輸前使用MD5加密也不行。

為了滿足以上約束條件，需要將用戶密碼加鹽（Salt）處理，即用戶密碼MD5 散列+ 一次性隨機碼組合，將這個組合再計算MD5散列值，得到一次性驗證密碼。

伺服器運行同樣的演算法，如果雙方的一次性驗證密碼匹配，用戶認證成功，否則認證失敗。

將來即使有第三方破解了HTTPS加密/解密的密鑰，但是依然無法獲取用戶明文密碼，甚至連用戶密碼的MD5散列值也無法獲取。

為了最大限度保護數據傳輸安全，通常需要很多功能模塊的協作。為了防止某一環節出問題而造成系統性風險，通常會做這樣的假設，如果其他模塊不安全了（被破解），能否最大限度保護數據的安全，保護用戶的隱私（密碼）！

這個術語叫PFS，Perfect Forward Secrecy，通俗地說，一個小兵掉鏈子，不能影響帝國集團軍整體掉鏈子！

RSA雙重演算法是否滿足了PFS要求？ 以及TLS 1.3為何要完全拋棄RSA密鑰交換演算法，歡迎閱讀公眾號（chexiaopangnetwork）同名更新文章。

ssl證書的私鑰和你用戶的賬號密碼沒有任何關係。

打個比方。(比方不是我朋友)

保險箱放在運鈔車裡。

運鈔車押運就是ssl加密，保險箱的密碼就是你的賬號密碼。

攻擊保險箱就是暴力破解

攻擊運鈔車只能靠中間人攻擊

從概念上理一下。你這裡說的包含了幾個概念：

  1. 會話密鑰。業務數據實際被加密（別人拿到也解不開）和完整性保護（別人不能偽造、篡改、重放密文，發送端不能抵賴）。這個就是題主問的結果。
  2. 「會話密鑰管理」密鑰。會話密鑰會定期協商更新的，協商過程的報文也要保護，一般會有一個管理密鑰來保護會話密鑰的協商更新。
  3. 認證憑據。雙方認可對方是正確、合法的通信對端需要呈上的ID（我是誰，用戶名和網站的URL或伺服器組織名稱）和需要證實持有憑據的證明（密碼和網站證書）。認證過程必須綁定一個管理密鑰協商，也就是，認證結束後，要讓合法的雙方共享一個或一組或一對不能讓第三方知曉的秘密。這個秘密一般是第2個密鑰或者密鑰生成材料。這個共享的獲得可以是直接用公鑰加密的密鑰2，或者用其他密鑰生成方法。

在一般通話過程中，如果這3部分間的結合正確，那麼除非雙方的主機內的認證過程和密鑰生成材料都被獲取到，才能破解。

如果伺服器端和客戶端的私鑰也丟失的話，那麼依賴於公私鑰保護的密鑰2生成就會出問題。因為他獲取了私鑰就可以解密所有通話過程，包括公私鑰鑰保護的"密鑰"。

所以在最新的協議中，都用了有PFS（完美前向安全）的保護，也就是必須使用網路上「不傳輸任何完整密鑰密文或明文」的協議。例如，使用DH交換或密鑰不可逆生成方式，同時要求刪除DH或其他生成方式的材料。這個刪除最好是在協商出密鑰時立刻刪除。這樣即使獲取到所有的密文，也沒法還原。

如果使用公鑰加密密鑰，那麼一般密鑰只要滿足隨機即可。

如果使用類似DH的密鑰交換，因為使用了非對稱密鑰的原理，在生成隨機數的時候會有一些限制，因為這些數學結構中會有一些易破解的密鑰。

如果使用不可逆演算法密鑰生成，一般是兩端各自提供一些隨機數，也沒有要求。

而使用不可逆演算法生成密鑰，恰恰有一種密鑰生成法，和口令有關，叫「pbe（基於口令的加密演算法）」，一般是 HASH（口令，隨機數1，隨機數2，。。。。。）。這種情況下，有可能被破解。

很多應用也許會採用這種加密的方式。因為這種方式的密鑰完全掌握在用戶手裡，伺服器沒有任何參與，很適合「個人隱私保護」。

當然https不是這樣的。

發給你公鑰 你用公鑰在本地加密之後發回伺服器，就算攔截到了 也沒辦法解開哈，但是如果是中間人攻擊，就不行了 ，所以一般我還會發一個鹽給你，本地把鹽和你的密碼放在一起搞個散列計算，把結果發給我 ，這樣就算中間人攻擊了怕啥，你的密碼自始至終也沒有離開你的電腦呀

RSA+AES跟有沒有使用https沒啥很大的關係

一般來說，客戶端隨機生成一個AES密鑰，用RSA公鑰加密，把加密後的內容發給伺服器，伺服器用RSA私鑰解密得到AES密鑰，之後兩邊會用AES通信。

因為AES密鑰是隨機的，所以只要客戶端和伺服器不被破解，理論上很難反解出AES密鑰。

順，密鑰跟密碼理論上不會有關係。但是實際中我不敢說的很絕對。

再，關於密碼的問題，我認為不論客戶端還是伺服器都不能存明文，密碼拿到後必須hash，並且要求高的話可能的話加鹽多次hash，並避免單獨使用md5，再走加密通道傳輸。如果現在那個公司還能被拖庫後讓人解出原始密碼，那我感覺這公司不用幹了，特別是涉及到保密、金錢的那些。

是隨機生成的，跟用戶賬號密碼沒有任何關聯。

https實際上是http over SSL。

在SSL協商密鑰的時候，http還沒開始會話呢。

參考《圖解密碼學》

先用隨機數生成aes密碼，然後用rsa交換aes密碼，之後都用aes加密解密。

推薦閱讀：
相关文章