一、公鑰私鑰
1，公鑰和私鑰成對出現
2，公開的金鑰叫公鑰，只有自己知道的叫私鑰
3，用公鑰加密的資料只有對應的私鑰可以解密
4，用私鑰加密的資料只有對應的公鑰可以解密
5，如果可以用公鑰解密，則必然是對應的私鑰加的密
6，如果可以用私鑰解密，則必然是對應的公鑰加的密
2，用私鑰加密資料（數字簽名），用公鈅來驗證數字簽名。
在實際的使用中，公鑰不會單獨出現，總是以數字證書的方式出現，這樣是為了公鑰的安全性和有效性。
二、ssl(secure sockets layer 安全套接層)
我和我得好朋友x，要進行安全的通訊。這種通訊可以是qq聊天，很頻繁的。用我的公鑰加密資料就不行了，因為：
1，我的好朋友x沒有公私鑰對，我怎麼給他發加密的訊息啊？ （注：實際情況中，可以雙方都有公私鑰對）
2，用公私鑰加密運算很費時間，很慢，影響qq效果。
好了，好朋友x，找了乙個數字3，用我的公鑰1，加密後發給我，說，我們以後就用這個數字來加密資訊吧。我解開後，得到了數字3。這樣，只有我們兩個人知 道這個秘密的數字3，別的人都不知道，因為他們既不知x挑了乙個什麼數字，加密後的內容他們也無法解開，我們把這個秘密的數字叫做會話金鑰。
然後，我們選擇一種對稱金鑰演算法，比如des，（對稱演算法是說，加密過程和解密過程是對稱的，用乙個金鑰加密，可以用同乙個金鑰解密。使用公私鑰的演算法是非對稱加密演算法），來加密我們之間的通訊內容。別人因為不知道3是我們的會話金鑰，因而無法解密。
好，複習一下：
1，ssl實現安全的通訊
2，通訊雙方使用一方或者雙方的公鑰來傳遞和約定會話金鑰 （這個過程叫做握手）
3，雙方使用會話金鑰，來加密雙方的通訊內容
上面說的是原理。大家可能覺得比較複雜了，實際使用中，比這還要複雜。不過慶幸的是，好心的先行者們在作業系統或者相關的軟體中實現了這層（layer），並且起了乙個難聽的名字叫做ssl，（secure socket layer）
ssl(secure sockets layer 安全套接層),及其繼任者傳輸層安全（transport layer security，tls）是為網路通訊提供安全及資料完整性的一種安全協議。tls與ssl在傳輸層對網路連線進行加密。一般的應用都是單向認證，如果 應用場景要求對客戶**做驗證也可以實現成雙向認證。
為 了便於更好的認識和理解 ssl 協議，這裡著重介紹 ssl 協議的握手協議。ssl 協議既用到了公鑰加密技術又用到了對稱加密技術，對稱加密技術雖然比公鑰加密技術的速度快，可是公鑰加密技術提供了更好的身份認證技術。ssl 的握手協議非常有效的讓客戶和伺服器之間完成相互之間的身份認證，其主要過程如下：
① 客戶端的瀏覽器向伺服器傳送客戶端 ssl 協議的版本號，加密演算法的種類，產生的隨機數，以及其他伺服器和客戶端之間通訊所需要的各種資訊。
② 伺服器向客戶端傳送 ssl 協議的版本號，加密演算法的種類，隨機數以及其他相關資訊，同時伺服器還將向客戶端傳送自己的證書。
③ 客戶利用伺服器傳過來的資訊驗證伺服器的合法性，伺服器的合法性包括：證書是否過期，發行伺服器證書的 ca 是否可靠，發行者證書的公鑰能否正確解開伺服器證書的「發行者的數字簽名」，伺服器證書上的網域名稱是否和伺服器的實際網域名稱相匹配。如果合法性驗證沒有通過， 通訊將斷開；如果合法性驗證通過，將繼續進行第四步。
④ 使用者端隨機產生乙個用於後面通訊的「對稱密碼」，然後用伺服器的公鑰（伺服器的公鑰從步驟②中的伺服器的證書中獲得）對其加密，然後將加密後的「預主密碼」傳給伺服器。
⑤ 如果伺服器要求客戶的身份認證（在握手過程中為可選），使用者可以建立乙個隨機數然後對其進行資料簽名，將這個含有簽名的隨機數和客戶自己的證書以及加密過的「預主密碼」一起傳給伺服器。
⑥ 如果伺服器要求客戶的身份認證，伺服器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的 ca 是否可靠，發行 ca 的公鑰能否正確解開客戶證書的發行 ca 的數字簽名，檢查客戶的證書是否在證書廢止列表（crl）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，伺服器將用自己的私鑰解開加密的「預主密 碼」，然後執行一系列步驟來產生主通訊密碼（客戶端也將通過同樣的方法產生相同的主通訊密碼）。
⑦ 伺服器和客戶端用相同的主密碼即「通話密碼」，乙個對稱金鑰用於 ssl 協議的安全資料通訊的加解密通訊。同時在 ssl 通訊過程中還要完成資料通訊的完整性，防止資料通訊中的任何變化。
⑧ 客戶端向伺服器端發出資訊，指明後面的資料通訊將使用的步驟⑦中的主密碼為對稱金鑰，同時通知伺服器客戶端的握手過程結束。
⑨ 伺服器向客戶端發出資訊，指明後面的資料通訊將使用的步驟⑦中的主密碼為對稱金鑰，同時通知客戶端伺服器端的握手過程結束。
⑩ ssl 的握手部分結束，ssl 安全通道的資料通訊開始，客戶和伺服器開始使用相同的對稱金鑰進行資料通訊，同時進行通訊完整性的檢驗。
雙向認證 ssl 協議的具體過程
① 瀏覽器傳送乙個連線請求給安全伺服器。
② 伺服器將自己的證書，以及同證書相關的資訊傳送給客戶瀏覽器。
③ 客戶瀏覽器檢查伺服器送過來的證書是否是由自己信賴的 ca 中心所簽發的。如果是，就繼續執行協議；如果不是，客戶瀏覽器就給客戶乙個警告訊息：警告客戶這個證書不是可以信賴的，詢問客戶是否需要繼續。
④ 接著客戶瀏覽器比較證書裡的訊息，例如網域名稱和公鑰，與伺服器剛剛傳送的相關訊息是否一致，如果是一致的，客戶瀏覽器認可這個伺服器的合法身份。
⑤ 伺服器要求客戶傳送客戶自己的證書。收到後，伺服器驗證客戶的證書，如果沒有通過驗證，拒絕連線；如果通過驗證，伺服器獲得使用者的公鑰。
⑥ 客戶瀏覽器告訴伺服器自己所能夠支援的通訊對稱密碼方案。
⑦ 伺服器從客戶傳送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密後通知瀏覽器。
⑧ 瀏覽器針對這個密碼方案，選擇乙個通話金鑰，接著用伺服器的公鑰加過密後傳送給伺服器。
⑨ 伺服器接收到瀏覽器送過來的訊息，用自己的私鑰解密，獲得通話金鑰。
⑩ 伺服器、瀏覽器接下來的通訊都是用對稱密碼方案，對稱金鑰是加過密的。
上面所述的是雙向認證 ssl 協議的具體通訊過程，這種情況要求伺服器和使用者雙方都有證書。單向認證 ssl 協議不需要客戶擁有 ca 證書，具體的過程相對於上面的步驟，只需將伺服器端驗證客戶證書的過程去掉，以及在協商對稱密碼方案，對稱通話金鑰時，伺服器傳送給客戶的是沒有加過密的 （這並不影響 ssl 過程的安全性）密碼方案。 這樣，雙方具體的通訊內容，就是加過密的資料，如果有第三方攻擊，獲得的只是加密的資料，第三方要獲得有用的資訊，就需要對加密的資料進行解密，這時候的 安全就依賴於密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通訊金鑰長度足夠的長，就足夠的安全。這也是我們強調要求使用 128 位加密通訊的原因。
SSL的單向認證和雙向認證
客戶端向伺服器傳送clienthello訊息，說明它支援的最高tls協議版本，隨機數 密碼演算法列表及壓縮方法。伺服器回覆serverhello訊息，包含基於客戶端clienthello訊息所選擇的tls協議版本，隨機數 密碼演算法列表及壓縮方法。伺服器選擇的協議版本為客戶端和伺服器都支援的最高版本...
SSL認證 單向認證與雙向認證
ssl協議即用到了對稱加密也用到了非對稱加密 公鑰加密 在建立傳輸鏈路時，ssl首先對對稱加密的金鑰使用非對稱加密，鏈路建立好之後，ssl對傳輸內容使用對稱加密。對稱加密 速度高，可加密內容較大，用來加密會話過程中的訊息 公鑰加密 加密速度較慢，但能提供更好的身份認證技術，用來加密對稱加密的金鑰 1...
SSL單向 雙向認證
引用 http cbwdkpl.blog.163.com blog static 453293822009814111320789 單向認證 客戶端向伺服器傳送訊息，伺服器接到訊息後，用伺服器端的金鑰庫中的私鑰對資料進行加密，然後把加密後的資料和伺服器端的公鑰一起傳送到客戶端，客戶端用伺服器傳送來的...