我們將未加密的內容稱為明文，加密之後的內容稱為密文。
簡單來說，要加密一段明文，可以將這段內容輸入到乙個加密函式中，輸出密文。但這種簡單的加密方式存在被人盜取到加密函式從而破解明文的危險，且加密函式一般構成複雜，一旦被盜取更換成本較高。
於是人們想出了乙個辦法，在加密函式中再新增乙個引數，這個引數只有通訊雙方知道，沒有引數則無法正確解密出明文。這個引數被稱為金鑰。對於同乙個加密函式而言，金鑰值的不同則加密方式也不同，得出的密文也就不同。這樣加密系統的安全性提高了，被盜取金鑰之後更換金鑰的成本也低了很多。常見的情景是加密函式都是使用公開的演算法，使用者需要儲存的僅僅是自己的金鑰。
對稱金鑰加密就是加密與解密使用相同的是金鑰值。
流行的對稱金鑰加密包括：
對稱金鑰需要通訊雙方共享金鑰。對網際網路通訊而言，不同的通訊雙方需要不同的對稱金鑰，如果有n個使用者需要相互通訊，總共需要金鑰數n*(n-1)。
對稱金鑰加密存在需要金鑰數太多以及傳遞金鑰不方便的缺點，於是人們研究出非對稱的金鑰加密技術，即加密和解密的金鑰不需要一樣。常見的一種稱為公開金鑰加密。
公開金鑰加密將通訊一端的加密和解密金鑰分成兩個，其中加密金鑰可以公開發布，也就是隨便誰都可以使用該加密金鑰為明文加密，但要解密這段密文只能靠該端私有的解密金鑰。這解決了對稱金鑰加密中的缺點。其中公開的加密金鑰稱為公開金鑰，私有的解密金鑰稱為私有金鑰。
要保證公開金鑰加密的可用性必須確保以下情況無法計算出私有金鑰：
流行的公開金鑰加密包括：
公開金鑰加密雖然更加簡單安全但其加密演算法運算比較慢，所以一般混合使用公開金鑰加密和對稱金鑰加密的使用方式，即先通過公開金鑰加密獲取到對稱金鑰加密的金鑰，再通過對稱金鑰加密傳輸資料。這種情況在後文說明。
對稱金鑰加密和公開金鑰加密都是將報文加密的技術。但加密能做的不止如此，還可以用加密演算法來證明報文是誰編寫的以及中途沒有被篡改。數字簽名就是這種技術。
數字簽名是附加在報文上的特殊加密校驗碼。其使用了私有金鑰加密生成校驗碼，除傳送者外其他人都無法重新生成對應的校驗碼，這樣就證明了報文的身份以及中途沒有被人篡改過。
數字簽名通常通過公開金鑰技術產生，但使用方式相反。傳送者首先為要簽名內容生成報文摘要，使用簽名函式並輸入私有金鑰作為引數，對報文摘要進行加密，生成簽名並隨報文一起傳送出去。接收者通過附加了公開金鑰引數的簽名函式反函式將簽名解密，並與生成的報文摘要進行對比，如果結果一致則代表報文無誤。
常見的rsa加密系統可以同時用於公開金鑰加密和數字簽名。rsa加密系統將解碼函式d作為簽名函式使用，編碼函式e作為解簽名函式。
單純的公開金鑰加密只適合對等的兩端通訊，對於常用的伺服器-客戶端通訊模式仍存在一些問題。1是公開金鑰加密只能證明報文確實是傳送方傳送的且沒有篡改，但傳送方本身是誰則無從得知，因為誰都可以生成公鑰私鑰對。如果把所有需要訪問的**的公鑰都事先儲存下來，數量巨大不說，如何傳送這些公鑰且如何證明儲存的公鑰確實是這個**的公鑰也是個問題。數字證書則可以解決這些問題。
數字證書是網路上的身份證明。一般包括如下內容：
其中頒發者的數字簽名是通過數字證書的其餘部分的報文摘要經證書簽名演算法及證書頒發者的私有金鑰計算出的，用於驗證數字證書的真實性。
任何人都能自行生成乙個數字證書，但只有值得信任的組織（ca）生成的數字證書才會預設被瀏覽器信任。具體原因在下一節說明。
關於瀏覽器驗證**數字證書的流程網上的資料一般講的都不是很清楚。在查閱了不少資料後終於搞清楚這部分。
ca下發給**的證書都是乙個證書鏈，也就是一層一層的證書，從根證書開始，到下級ca，一層一層，最後一層就是**證書。
瀏覽器收到伺服器傳送的證書後，需要驗證其真實性。而證書的簽名是通過簽名演算法和上級ca的私鑰生成的，並非很多文章裡簡單說的靠ca私鑰生成。瀏覽器需要用上級ca的公鑰才能解密簽名，並與生成的指紋對比，那麼問題來了，這個上級ca的公鑰從哪來呢？
答案是此公鑰來自於證書鏈該層的上級ca的證書明文內。單個x509v3證書由以下部分組成：
x.509v3證書由三部分組成：
tbscertificate又包含10項內容，在https握手過程中以明文方式傳輸：
證書鏈由多個證書一層一層組成的，除了最底層的**證書的公鑰是給使用者加密報文外，其他層證書中的公鑰均用於解密底層的證書指紋簽名。最高層的根證書是自簽名的，也就是自己頒發給自己，所以它的公鑰不僅用來解密下層的簽名，也用來給自己的簽名解密。
驗證證書是否真實的任務完成了，那麼證書是否可靠如何驗證呢？一句話，只要根證書可靠，整個證書鏈就可靠，而根證書是否可靠要看這個根證書是否在作業系統或瀏覽器內建的可信根證書內，在的話就可信。
https是在http報文傳送給tcp之前對報文進行加密的安全協議。使用443埠進行通訊。
普通的http有如下四層：
https多了乙個安全層：
證書金鑰驗證都是在安全層驗證。常用的ssl/tls程式設計實現庫是openssl。
此部分內容主要參考《ssl/tls協議執行機制的概述》
實際的https驗證過程如下：
對於需要驗證使用者證書的還會包含請求要求使用者提供證書。
客戶端收到回應後首先驗證伺服器證書：
證書沒問題的話客戶端會回應以下內容：
此時通訊雙方都有了這三個隨機數。通過商定的加密方法根據三個隨機數生成乙個相同的會話金鑰sessionsecret，用於之後的對稱加密。
伺服器收到回應後計算出sessionsecret，並傳送以下內容給客戶端：
這樣https握手過程就結束了，之後就是通過http傳送經過對稱加密的報文。
對稱加密的金鑰交換
因為對稱加密金鑰是實時更新的，怎麼保證生成的金鑰安全的傳送到另一端呢？對稱加密的優點和缺點 優點 高效 缺點 金鑰交換是個問題，沒有非對稱加密的安全性高，金鑰越長安全性越高，當選擇256的aes，仍能勝任大多數的安全領域。公鑰密碼 非對稱加密 演算法的優點和缺點 優點 安全性足夠高 因為金鑰很長 沒...
對稱金鑰系統和公開金鑰系統
為了安全性，在網際網路上傳輸的一些資訊需要加密，比如使用者登陸所使用的密碼。加密系統一般分為對稱金鑰系統 symmetric key system 和公開金鑰系統 public key system 在對稱金鑰系統中，用於加密和解密的金鑰是相同的並且是秘密的，只能為兩個人所知。對稱金鑰系統要求雙方共...
對稱與非對稱金鑰加密
1.對稱與非對稱金鑰加密比較 非對稱金鑰加密 用接收方的公鑰進行加密 解決了金鑰協定與金鑰交換問題，但並沒有解決實際安全結構中的所有問題。具體地說，對稱與非對稱金鑰加密還有其他一些差別，各有所長。下表總結一下這些技術的實際用法 特徵對稱金鑰加密 非對稱金鑰加密 加密 解密使用的金鑰 加密 解密使用的...