請教一個https安全問題?
客戶端通過服務端的公鑰對私鑰加密傳給服務端的時候，服務端如何辨別不是黑客使用服務端公鑰加密的自己的私鑰?
問題中的“私鑰”不是私鑰，而是對稱密鑰。對稱密鑰其實也是泛稱，準確的專業名詞為“預備的主密鑰”（Pre-Master Key）。所以問題就變為，客戶端通過服務端的公鑰對“Pre-Master Key”加密傳給服務端的時候，服務端如何辨別不是黑客使用服務端公鑰加密的“Pre-Master Key”?
無法知道。
你訪問知乎，還是黑客訪問知乎，在建立安全連接TLS完成時，知乎服務器并不知道你是你，黑客是黑客。因為在安全連接TLS建立過程，知乎服務器并沒有校驗你的真實身份，無論是你、我、他、黑客，都是可以訪問知乎的。訪問知乎的用戶（客戶端）都沒有屬于自己的數字證書，所以壓根無法校驗用戶的真實身份。
但是，知乎服務器對你的身份很感興趣。所以一旦安全連接建立完成，會通過http會話校驗你的身份。無非手機驗證碼、用戶名密碼等方式認證。由于黑客沒有你實時的手機驗證碼信息，所以他無法冒用你的身份。但是依然可以嘗試通過用戶名、密碼進入你的賬戶，前提是你的密碼特別簡單。這個話題和這篇文章的相關系數小，不再展開。
上文中的“Pre-Master Key”，除了你知道，黑客知道嗎？
不知道。因為“Pre-Master Key”被服務器的公鑰加密了，黑客因為沒有服務器的私鑰，所以無法破解，自然也無法知道。
上文中的“Pre-Master Key”，除了你知道，還有誰知道？
服務器。因為服務器有服務器的私鑰，自然可以解密，得到明文的Pre-Master Key。
所以，整個互聯網世界，除了你、服務器知道Pre-Master Key，不會有第三個人知曉Pre-Master Key明文。根據Pre-Master Key加密的數據包在公共的互聯網上傳輸時，沒有第三方可以破解。
Pre-Master Key能直接加密用戶數據嗎？
不能。因為Pre-Master Key不夠隨機化，且其長度和加密算法（AES 128/256）長度并不相等。
怎么辦？
需要將Pre-Master Key輸入偽隨機函數PRF，其實就是N次的hash計算。輸出結果可以任意指定長度，這個輸出結果就是Master Key。
Master Key能直接解密/解密用戶數據嗎？
依然不能。
怎樣才能得到直接加密用戶數據的Session Key？
需要將Master Key、Client Nonce、Server Nonce、以及協議標準字符串再運行一次PRF，得到的輸出結果，按照bit位的先后次序，可以得到Read Session Key、Write Session Key、Read HMAC Key、Write HMAC Key等等。
前兩者用戶數據加密/解密（雙向）Key，后兩者用于用戶數據校驗的（雙向）Key。
文中的Master，是指這個密鑰是礦主，通信所有的Key都由礦主衍生并分發給每個礦工使用。
最后，需要強調：你和服務器之所以能夠安全通信，全憑服務器的公鑰，被第三方公證并簽名的證書，其中有服務器的公鑰明文。
文中分發Pre-Master Key的方法，已經無法滿足PFS安全需求，所以在TLS1.3版本已經被完全拋棄。TLS 1.3目前只使用DH算法以及由DH衍生出DH-ECC算法來分發密鑰。即使有一天，服務器的私鑰泄露，人人都知道服務器的私鑰，但是卻無法使用該私鑰解密歷史數據，這就是PFS真實含義。但是使用本文的分發Pre-Master Key的方法，一旦服務器私鑰泄露，歷史數據就可以毫無障礙破解。
