前言
早期的tcp/IP定位的直接就是能夠更好的實作主機之間的通信，并沒有過多的考慮安全問題。随着網際網路規模的擴大以及鳥大了什麼林子都有的原則，ftp、http、smtp、telnet這些協定都是明文傳輸的，很容易被不法分子利用，安全問題逐漸被人們重視，在網際網路領域當中密碼學是
安全的重要保障，密碼學不是一項技術，而是科學，并且做為國家軍事戰略高度的科學，對于我們普通人來講，密碼學就是資料加密的機制。
加密的本質是一種轉換規則。
常見的加密方式有三種：對稱加密，非對稱加密，單向加密
總結：因為應用的某些協定不安全，是以在應用層在傳輸層又加了半層，這半層以被稱為TLS某種SSL，無論是TLS還是SSL，主要都是利用密碼學來實作的，而密碼學對我們這些使用者來講就是一種轉換規則，常見的加密方式又被分為三種：對稱加密，非對稱加密，單向加密。
補充：
SM3中國首個hash算法
所謂的破解并不是通過密文推導出明文，而是找到了兩個hash一樣的資料。
所謂的數字簽名就是CA用自己的私鑰加密從資料中提取出來的特征碼，實作了身份驗證和資料的完整性。
算法并不依賴于算法的本身，而是依賴于密鑰，算法本身很多都是公開的
對稱加密和非對稱加密
資料加密：公鑰加密很少用到資料的加密的，因為太慢，密鑰太長，對稱加密比非對稱加密快1000倍左右，公鑰的主要舞台用于身體驗證。加密資料的話一般要使用對稱加密，加密完成之後的對稱密鑰再用非對稱密鑰加密。
數字簽名：數字簽名的主要目的是讓接收方知道資料的确是發送方發送的，用于使用者身份驗證，發送方生成一段資料，用自己的私鑰加密這段資料然後發給接收方，接收方通過發送方事先公開的公鑰就是确認發送方的身份。
密鑰交換：所謂的密鑰交換我認為是在SSL的基礎上了解上,比如bob把自己的證書發送給alice,而alice會生成一個對稱密鑰,通過bob給的證書當中的公鑰加密這個對稱密鑰之後發送給bob.,密鑰交換可以這樣了解,通過非對稱密鑰來完成對對稱密鑰的交換.
小結：
發送方用自己的私鑰加密資料（數字簽名），能夠實作資料的身份驗證，但是不能實作資料的機密性。
發送方用對方的公鑰加密資料（密鑰交換），可以保證的資料所機密性，但不可以身體驗證。
舉例：
A給B發送一段資料，B要确認是這A發的(身份驗證)，資料沒有被修改過（完整性），并不用保證資料的機密性。
A--------------->>------------B
答：A通過單向加密對資料提取一段特征碼附加在檔案的尾部，然後A通過自己的私鑰僅僅加密最後一段特征碼即可（數字簽名），當B收到之後通過A事先公開的公鑰實作對身份的驗證，解開被加密後的特征碼之後可以得到真正的特征碼，然後B通過同樣的單向加密算法，對資料進行單向提取特征碼，通過與發送方發過來的特征碼做比較來完成資料完整性的較驗。
A--------->-----C-------->--------B
這個過程有沒有可能被人破壞呢？是有可能，還是使用上述方式：“A對資料提取特征碼附加在資料的尾部，然後通過自己的私鑰加密發送給B。“ B想要解密A加密的特性碼，肯定在加密A發送的資料前擷取A的公鑰，那麼問題來了，B怎樣才能獲得A的公鑰呢？一般就是A主動把自己的公鑰發送給B，但是路上還是有C在攔截，C完全有可能把A發送給B的公鑰給截獲了，然後自己生成一對密鑰，C把自己的公鑰發送給B并說明自己就是A，然後B就相信了。當A給B發送真正的資料時，又被C給截獲了，C即使不用A的公鑰加密也完全能夠看到A發送給B的内容，當然C的野心不僅僅是檢視内容這麼簡單，C通常會把A給B發送的資料扔掉，然後自己生成一段資料（當然這段資料可能是辱罵B的資料）然後自己用單向加密提取特性碼附加到資料的尾部，C再通過自己的私鑰加密特性碼之後發送給B，這時B還會拿着自己認為的A的公鑰去解密特性碼，然後對資料做一次單向提取之後與“A”發來的的特性碼對照，經過對照發現這個辱罵自己的資料就是A發送的，于是C與A絕交。
三種算法放到一塊，讓A與B通信一次，并且保證不讓C破壞
A-------------->>-------------B
還是A給B發送一個資料，并且要保證這個資料隻能是B收到，并且不能被人篡改僞造。
第一步通過單向加密對資料提取特征碼附加在資料的尾部，這是在原有的公鑰上面附加了資訊，原有的公鑰沒有變化。
第二步通過自己的私鑰對特征碼進行加密，這是把hash通過私鑰（轉換規則）進行了轉換，并沒有附加資訊。
第三步然後把公鑰+被私鑰加密後的hash這兩部分進行一次對稱加密，此次加密遺留了一個對稱密鑰沒處存放。
第四步然後通過對方的公鑰對對稱密鑰再加加密一次。
1. 當B收到之後，首先通過自己的私鑰打開對稱密碼，這裡可以實作機密性，這個資料隻有自己可以打開。
2. 用對稱密鑰，再打開被加密後的内容（公鑰+被自己私鑰加密後的HASH），這裡什麼也沒實作，如果硬說實作了什麼的話，那就是實作了效率，其實在這裡就可以看到，是哪個CA給A發的證書。
3. 如果自己本地沒有此CA的數字證書的話，就顯示不信任的證書頒發機構，如果本地有此CA的數字證書會進一步進行驗證，嘗試是否能打開“被CA私鑰加密後的hash”，如果能打開就實作了身份驗證，說明此公鑰的确是CA給頒發的。
4. 别急，還沒完呢！再把A的公鑰和附加資訊hash一遍，然後與A發來的HASH進行對比，這一步可以實作完整性的校驗。B（通常是用戶端浏覽器）應該還要檢查此證書是否在證書頒發機構的吊銷清單裡面，還要再檢視用戶端通路的URL是否與公鑰裡面的資訊一模一樣，不一樣也不行。
一次通信，三次加密算法都用上了。
這種通信機制當中還是存在了一個問題，依然存在着傳輸密鑰時被C給截獲的風險，依然是不安全
PKI(Public Key Infrastructure)公鑰基礎設施
本小節主要介紹了：
l 公鑰基礎設施的概念和x509證書的格式
l CA資料簽名的過程以及用戶端驗證CA憑證的過程
l QQ是怎樣實作加密的
PKI的全稱為public key infrastructure公鑰基礎設施，這是一個統稱，就像新華電腦學院是多個專業的統稱一樣，其實公鑰基礎設施由四個部分組成，如下圖：
證書存取庫：将來我們向CA申請證書的時候就是向證書存取庫裡面申請的。現在證書存取庫發放的證書都是X.509的格式，X.509不僅僅是一種證書格式還是證書的規範，有三個版本，我們現在使用的都是它的第三版證書，它定義了一個規範的證書裡面應該包括：
CA是怎樣給某個主機進行發證的呢？
第一步：CA想要給别人發證，首先自己得有私鑰和公鑰。私鑰用來給來申請的主機進行數字簽名，公鑰是要發給用戶端的，用來實作對CA的身份驗證，我們講過的：“使用自己的私鑰加密，讓别人通過公鑰打開，可以實作身份驗證而不能實作資料的機密性”。
第二步：CA僅有私鑰和公鑰還不成，還要有自己的數字證書。為什麼要自己有證書呢？一個CA為了友善使用者的驗證是要把自己的公鑰公布于衆的，但是并不是直接把自己的公鑰直接公布出去，而是把自己的數字證書公布出去（數字證書裡面有自己的公鑰），為什麼要這麼做呢？直接公布公鑰不成嗎？直接公布公鑰是很有可能被中間人僞造的，是以要公布自己的數字證書，這樣友善使用者的驗證。實際上使用者導入CA數字證書的機會很少，因為一般主流的作業系統在發行時都已經把最常見的CA機構的數字證書内置到了作業系統内部了，但是也有沒有導入的CA，比如12306網站使用的CA。CA是給别人發證的，那麼CA自己的證書是誰給它發的呢？答案是自己給自己發的，那麼怎樣才能自己給自己發證呢？是這樣的，過程是很簡單的，CA把自己的公鑰和一些必需要填報的資訊：比如主體名稱，國家，城市，等等通過一個檔案自己送出給自己，核實無誤然後再用自己的私鑰對這個請求檔案進行數字簽名，簽過名之後就會生成一個數字證書。那麼簽名的過程是怎樣的呢？由于CA是自己給自己發證，是以送出請求之後并沒有進行驗證，如果在真實的環境某主機給CA送出請求的話，CA機構會派人到該公司裡内部核對申請的資訊是否真實，有營業執照、公網IP，責任人等等确認無誤之後，CA會通過單向加密，把主機送出的請求檔案提取一個特征碼附加在檔案的尾部，然後通過自己的私鑰僅對特征碼進行加密，注意簽名的過程并沒有對資料進行加密，加密的隻是檔案尾部的特征碼，被加密過的檔案特征碼申請資訊就組成一個數字證書，生成數字證書的過程就是數字簽名。從CA給企業頒發證書的這個過程來看，僅僅實作了一個完整性的校驗，對于機密性和身份認證都不能實作 ，因為在這個階段，企業還沒有數字證書，最好的方式就是企業拿着U盤去CA把CA的數字證書拿過了，這樣最為保險，當然也可以讓CA把自己的數字證書送過來，其實這一步，一般是用不着使用者做的，系統一般都會把常用CA的數字證書給安裝好了。
第三步： CA将做簽名的證書然後送回給申請的公司，申請的公司将把這個數字證書導入到需要使用的此證書的應用程式的主目錄當中，比如，httpd會放到/etc/httpd/當中
NOTE：這個過程在下面的實驗當中有示範。
使用者怎樣驗證對方發來的證書是可信的呢？在描述驗證以前我們應該明确一點，作業系統在發行時一般都會将市面上最常見，最權威的CA機構的公鑰内置到作業系統的内部以友善使用者的驗證。
第一步：當alice把自己的證書（當然此證書一定要是某CA機構簽署頒布的）發送給bob時，bob為了驗證alice就是alice而不第三方僞裝的，就要先打開alice給的數字證書，首先檢視發行者（CA）的名稱，如果此CA的名稱與系統内置的某一個CA的名稱重合，重合意味着系統内置了此CA的公鑰，反之，就認為此CA機構不可信任。
第二步：bob通過系統内置的CA公鑰去驗證發行者（CA）的簽名，怎樣驗證呢？我們在上面講過，CA給alice簽名就是“CA用自己的私鑰對alice申請檔案的特征碼做加密”，是以bob隻要用CA的公鑰能夠打開CA對alice的私鑰簽名就證明alice是确認是這個CA頒布的證書，我們在前面提過：”用自己的私鑰加密可以實作身體驗證，是以在這裡bob能夠用CA的公鑰打開CA的簽名就表示alice的證書就是信任的CA頒發的證書，到了這一步僅僅能說明證書裡面的資料可能是正确的，為什麼？因為證書裡面的版本号、序列号、主體公鑰等等都沒有加密，僅僅是提取的特征碼被加密而已，裡面的資訊還是有可能被中間人修改的。
第三步：第三步解開的是證書内部的：”版本号，序列号，主體公鑰，主體名稱等等“這些資訊的特征碼，bob還要通過單身加密計算出這些資訊的特征碼，然後通過自己的計算出的特征碼與CA公鑰打開的特征碼做比較，如果一樣，就表示證書内所有的資訊都是完整的，可靠的。
第四步：用戶端檢查證書是否位于證書吊銷清單當中，大部分浏覽器都沒有做最後一步，為了保險期間我們最好人工去檢視一下。
現在網際網路的證書主要有兩種，一種是個人證書，一種是主機證書。銀行給的U盾，U盾裡面存放的就是使用者自己的數字證書，當我們需要用電腦在網上轉賬的時候，伺服器會把我們的http請求自動轉換為https，轉換為https的過程就是使用者去驗證伺服器的資料證書的過程，這是單向的驗證，我們在淘寶上付款時也是這樣的，但是銀行轉賬用戶端不僅要驗證伺服器的數字證書，銀行還要驗證使用者的數字證書，而使用者的數字證書就在銀行給的U盾裡面，這個U盾裡儲存的數字證書就是個人證書，個人證書與主機證書最大的不同是主機證書的主體名字上寫的是主機的名字，比如www.taobao.com而使用者的數字證書上的主體名稱是使用者的姓名，比如馬雲。當然最為常用的還是主機證書，在這裡需要注意的是證書裡面的主體名一定要與真正主機的主機名要一緻，不然的話，業務會失敗.
CA
1. 生成一對密鑰。
2. 利用公鑰和申請資訊産生一份申請檔案送出給自己（此檔案當中包括自己的公鑰）。
3. 自己生成自己的數字簽名證書：CA先利用hash提取出這個檔案的特征碼附加到檔案的尾部，然後自己的私鑰對此特征碼加密，注意，檔案并沒有加密。
4. 将此數字簽名證書公布于衆，各大作業系統的發行商會将其內建到自己的作業系統當中。
HTTPS
1. 生成一對密鑰
2. 利用公鑰和申請資訊産生一份申請檔案送出給CA（此檔案當中包括自己的公鑰）。
3. CA對申請資訊核實無誤之後，會生成數字簽名證書：CA先利用hash提取出這個檔案的特征碼附加到檔案的尾部，然後自己的私鑰對此特征碼加密，注意，檔案并沒有加密。
4. CA将此數字證書給HTTP，HTTP會将其放置到自己的工作目錄的。
Client
Client預設就是有CA自己的數字簽名的，也就是說使用者有CA的公鑰，發行商內建的嘛！
1. 當用戶端通路網站時，當然先建立虛鍊路、然後附加TLS通道，伺服器會把CA簽名過的數字證書發送給用戶端。
2. 用戶端驗證，怎樣驗證呢？用CA的公鑰嘗試打開網站給的數字證書當中被加密後的特征碼，如果打開了就實作了身體驗證，打開之後利用hash進一步驗證完整性。
3. 用戶端拿到網站的公鑰之後會随機生成對稱密鑰，通過公鑰加密之後發送給網站，然後後面它們加密的資料都是用對稱密鑰處理之後再發送。
QQ的加密通信:
當資料從資源子網交給通信子網之後，資料會被封裝，但是封裝并沒有改變資源子網的資料，如果有人可以擷取到這些包的話就可以看到通信子網當中的内容。可能有人說不會呀？我用QQ發送的資料即被抓到包也看不到裡面發送的明文，這是怎麼回事呢？其實“資源子網把資料給通信子網之後資料并沒有改變”這個原則并沒有改變，隻不過是QQ這個軟體本身實作了資料加密的功能（有的資源子網的協定或者軟體可自行實作資料的加密，而有的協定或者軟體本身是不支援加密的，像早期的QQ就不支援加密），像這樣的案例還有，比如ftp，當我們使用ftp的時候就可以抓住ftp要傳輸的内容包括密碼，如果我們在網上轉賬呢？這豈不是太不安全了，其實這是有解決辦法的。像ftp這種資源子網當中的協定本身不能加密，而通信子網又不能改變資料的内容，隻要在資源子網在通信子網之間加上半層，讓這半層專門實作加密功能來加密資料。
TLS和SSL
SSl（安全的套接字層）和TLS（transport layer security）傳輸層安全
PKI是公共密鑰基礎設施，是為了資料能夠安全可靠的傳輸，實質上這種設施是為了應用程式準備的，比如http（超文本傳輸協定）這個協定原本隻能傳輸明文沒有加密的機制，非常的不安全可靠，但是現在不同的了，有了公共密鑰基礎設施，我們就可以在http的基礎上使用公共密鑰基礎設施，怎樣使用呢？
OSI參考模型在之是以是七層很大原因就是某一層的調整并不會影響到其他層，我們在應用層和傳輸層中間再放半層，用這半層專門來實作對PKI的應用，憑什麼這半層能夠實作加密，就是因為這半層的主要任務就是協商加密方式，對資料進行加密，驗證對方的數字證書，講到這裡，我們知道了，協商加密方式，對要傳輸的資料加密，驗證對方的證書并不是計算機完成的，而是由這半個中間層完成的,那麼這半個層就是TLS或者是SSL.
那麼到底是TLS還是SSL呢?它們兩個是什麼關系呢? SSL（安全的套接字層）是網警一個公司為自己的浏覽器的研制出的協定，後來微軟打敗的IE打敗.後來國際标準化組織也搞了出了一個協定就叫TLS（傳輸層安全協定），TLS現在是第一版，相當于SSL的第三版，原理和機制差不多，那麼我們下面再講的時候是不加以區分的。有的軟體僅支援SSL，有的僅支援TLS，有的兩種協定都支援.
半層？一層？
那麼為什麼說這個中間層隻有半層而不是一層呢？是這樣的，如下圖：
當http不使用TLS或者是SSL層的時候傳輸的都是明文，當http使用TLS或者SSL的時候就變成了https，傳輸的不同進明文而是密文,是以我們可以使用tls也可以不使用,這一層并不是必需存在的,是以這是說這是半個層而不是一個整層.
SSL隻能基于IP位址的通路，而不能根據主機名來實作，因為SSL它終究不是應用層的的應用或者協定，它是位于應用層與傳輸層之間的庫，SSL握手的時候隻能基于IP，而不能基于主機名，是因為在使用基于主機名的通路的時候主機名是封裝在應用層的，SSL可以讀取到網絡層的但是讀取不到應用層的資訊，是以無論是哪個虛拟主機,隻要是IP一樣,SSL都會當成一個會話來看待,一個IP位址基于一個應用層協定隻能建立一個會話.
http VS https
本小節主要介紹了http和https的會話過程:
http的會話過程:
1. 用戶端把請求發送到伺服器上,伺服器上的核心根據請求包當中的目标端×××給http服務
2. http根據請求到的内容讓核心去硬體當中調用資料,交給http程序
3. http建構響應封包根據套接字回複到用戶端并記錄日志
https的會話過程:
1. 用戶端向伺服器發起請求
2. 伺服器先要跟用戶端協商到底使用SSL還有sls協定的哪個版本，這是雙向的過程 。
3. 伺服器會把自己的證書發給用戶端（用戶端一般沒有證書），用戶端是看簽署的CA是不是自己信任的，資訊是否完整，拿到伺服器的公鑰。