ssl訪問的原理

　　本文無圖文對照解釋，但力求通俗易懂。請讀者邊讀邊手繪各個流程，一便於理解。     

整體交互流程以下

     1. 客戶端發起HTTPS請求

　　這個沒什麼好說的，就是用戶在瀏覽器裏輸入一個https網址，而後鏈接到server的443端口。

　　2. 服務端的配置

　　採用HTTPS協議的服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請。區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。若是對公鑰和私鑰不太理解，能夠想象成一把鑰匙和一個鎖頭，只是全世界只有你一我的有這把鑰匙，你能夠把鎖頭給別人，別人能夠用這個鎖把重要的東西鎖起來，而後發給你，由於只有你一我的有這把鑰匙，因此只有你才能看到被這把鎖鎖起來的東西。

　　3. 傳送證書

　　這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間等等。

　　4. 客戶端解析證書

　　這部分工做是有客戶端的TLS來完成的。

　　客戶端（以 IE 瀏覽器爲例，單擊「工具」——「Internet 選項」——「內容」選項卡——單擊「證書」）的"證書管理器"，有"受信任的根證書頒發機構"列表。客戶端會根據這張列表，查看解開數字證書的公鑰是否在列表以內。

　　首先會驗證公鑰是否有效，好比頒發機構，過時時間等等，若是發現異常，則會彈出一個警告框，提示證書存在問題。若是證書沒有問題，那麼就生成一個隨機值。而後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，否則看不到被鎖住的內容。

　　5. 傳送加密信息

　　這部分傳送的是用證書加密後的隨機值，目的就是讓服務端獲得這個隨機值，之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。

　　6. 服務段解密信息

　　服務端用私鑰解密後，獲得了客戶端傳過來的隨機值(私鑰)，而後把內容經過該值進行對稱加密（解說:正式的交互數據使用對稱加密，非對稱加密性能差）。所謂對稱加密就是，將信息和私鑰經過某種算法混合在一塊兒，這樣除非知道私鑰，否則沒法獲取內容，而正好客戶端和服務端都知道這個私鑰，因此只要加密算法夠彪悍，私鑰夠複雜，數據就夠安全。

　　7. 傳輸加密後的信息

　　這部分信息是服務段用私鑰加密後的信息，能夠在客戶端被還原。

　　8. 客戶端解密信息

　　客戶端用以前生成的私鑰解密服務段傳過來的信息，因而獲取瞭解密後的內容。整個過程第三方即便監聽到了數據，也一籌莫展。

 

幾個關鍵的背景概念

1）數字簽名——爲了證實發件人身份，情景再現以下，

　　Alice與Bob互換公鑰。
　　Alice用本身的私鑰對TXT文件進行數字簽名。
　　Alice用Bob的公鑰對TXT文件進行加密。
　　Alice把通過數字簽名和加密的文件TXT，經過郵件或其餘傳輸途徑，如QQ、MSN等）傳給Bob。
　　Bob在收到簽名並加密的郵件後首先用Bob本身的私鑰進行文件加密的解密，而後再用Alice的公鑰進行數字簽名解密。
　　一樣，在這個過程當中Cinda也能夠獲取Bob、Alice的公鑰和簽名並加密的標書文件TXT。同時因無Bob的私鑰而沒法打開郵件。同時因爲Alice在發送文件前已用本身的私鑰進行了數字簽名，因此當Bob在收到郵件後徹底能夠證明本身收到的就是Alice發來的郵件，而不多是其餘用戶的。試想若是Cinda非法用戶想要改變郵件，冒充Alice向Bob發送郵件，因Cinda沒有Alice的私鑰，因此在用其餘用戶的私鑰進行數字簽名時就不可能再以Alice的公鑰來解密數字簽名了。
　　在這裏要注意文件加密和數字簽名的前後順序，必定是先簽名再加密，這樣加密技術就能夠同時保證郵件中的數字簽名了。若是先加密，然後簽名，非法用戶在獲得郵件後就可經過獲取的公鑰破解數字簽名了，由於公鑰是能夠公開的，很容易被一些別有用心的人獲得。數字簽名破解後極可能簽名被替換。固然郵件中的內容在沒有收件人私鑰的狀況下仍是沒法打開的。

2）證書的起源——這裏也經過一個情景來展示

　　鮑勃有兩把鑰匙，一把是公鑰，另外一把是私鑰。

　　鮑勃把公鑰送給他的朋友們----帕蒂、道格、蘇珊----每人一把。

　　蘇珊要給鮑勃寫一封保密的信。她寫完後用鮑勃的公鑰加密，就能夠達到保密的效果。

　　鮑勃收信後，用私鑰解密，就看到了信件內容。這裏要強調的是，只要鮑勃的私鑰不泄露，這封信就是安全的，即便落在別人手裏，也沒法解密。

　　鮑勃給蘇珊回信，決定採用"數字簽名"。他寫完後先用 Hash 函數，生成信件的摘要（digest）。

　　而後，鮑勃使用私鑰，對這個摘要加密，生成"數字簽名"（signature）。

　　鮑勃將這個簽名，附在信件下面，一塊兒發給蘇珊。

　　蘇珊收信後，取下數字簽名，用鮑勃的公鑰解密，獲得信件的摘要。由此證實，這封信確實是鮑勃發出的。

　　蘇珊再對信件自己使用 Hash 函數，將獲得的結果，與上一步獲得的摘要進行對比。若是二者一致，就證實這封信未被修改過。

　　複雜的狀況出現了。道格想欺騙蘇珊，他偷偷使用了蘇珊的電腦，用本身的公鑰換走了鮑勃的公鑰。此時，蘇珊實際擁有的是道格的公鑰，可是還覺得這是鮑勃
的公鑰。所以，道格就能夠冒充鮑勃，用本身的私鑰作成"數字簽名"，寫信給蘇珊，讓蘇珊用假的鮑勃公鑰進行解密。

　　後來，蘇珊感受不對勁，發現本身沒法肯定公鑰是否真的屬於鮑勃。她想到了一個辦法，要求鮑勃去找"證書中心"（certificate authority，簡稱 CA），爲公
鑰作認證。證書中心用本身的私鑰，對鮑勃的公鑰和一些相關信息一塊兒加密，生成"數字證書"（Digital Certificate）。

　　鮑勃拿到數字證書之後，就能夠放心了。之後再給蘇珊寫信，只要在簽名的同時，再附上數字證書就好了。

　　蘇珊收信後，用 CA 的公鑰解開數字證書，就能夠拿到鮑勃真實的公鑰了，而後就能證實"數字簽名"是否真的是鮑勃籤的。

 

 

附件：一個較詳細的實現流解析

http://www.fenesky.com/blog/2014/07/19/how-https-works.html