對於HTTP,大家都很熟悉了，使用也相當廣泛。但是同很多未加密協議一樣，HTTP也存在着安全性的問題。
比如：
1、明文消息，很容易被竊聽
2、不驗證通信方身份，很容易遭遇僞裝
3、無法證明報文的完整性，內容容易被篡改
這時候HTTPS就需要加上必要的加密處理和認證機制了。我們將這個加了加密認證機制的HTTP叫做HTTPS(HTTP Secure)。
HTTPS並非是一種新的協議，只是HTTP通信接口部分改成SSL和TLS協議代替而已。同城HTTP跟TCP通信，當使用SSL時，先變成SSL通信，再由SSL和TCP通信。其實就是身披SSL的HTTP
類似的不光是HTTP協議，其他運行在應用層上的協議都可以配上一層SSL,比如SMTP,Telnet等協議，都可以配合SSL來提高安全性。
單純的http很好理解，這裏不再做介紹。
https就是在http之上加上一層安全機制。這層安全我們需要依賴於密碼學以及相關的認證機制。
所以接下來我們來了解下https是如何做數據的加密以及認證的。
在密碼學中，加密的算法都是公開的。所以我們加密並不依賴於算法的保密性，而是依賴於密鑰的保密。換言之，只要獲得密鑰，就可以解密。這時候在保密通信中密鑰的傳輸就尤爲關鍵。
如果想要通信安全，那麼需要使用密鑰加密通信。但是如何保證密鑰安全？就是如何保證密鑰安全的送達對方？在互聯網環境中，如果密鑰在轉發時被竊聽，截取甚至篡改，那麼我們後面的加密將失去意義。
這就陷入一個循環了，密鑰的發送會有安全的風險。但是我不發送就無法加密會話。而如果我能安全發送密鑰，那麼我應該也能安全發送數據。。。
爲了解決這樣一個問題，後面有人提出了使用非對稱加密。
對稱加密就是加密和解密都是使用相同的一個密鑰。也就是加密和解密的過程只用一個密鑰。
非對稱加密分公鑰和私鑰。發送方使用共鑰加密數據，接收方使用私鑰解密數據。也就是說保密方會生成對應的公鑰和私鑰，之後公鑰就發出去了。保密的數據使用公鑰進行加密，接收方會使用私鑰對加密數據進行解密。
利用非對稱加密方式，就可以繞過前面的問題。我們將公鑰發出去，而私鑰是自己保留。最壞的情況是會話被截取，但是也無法被解密。但是這裏還是有一個問題，如何保證公鑰就是貨真價實公鑰，公鑰被惡意篡改了怎麼辦？
1、如果公鑰在送達對方的時候就已經被篡改了，那麼很有可能就是遭受到了中間人攻擊，有人冒名頂替了我方跟對面通話。
2、如果公鑰在送達對方之後被截取，攻擊者即使無法解密出會話內容，也能輕易做到冒名頂替對方跟我方通信。
爲了解決這個問題，人們使用了數字證書認證機構（CA,Certificate Authority）和其相關機關頒發的公開密鑰證書。
數字證書認證機構是通信雙方都認可的第三方機構。這個機構就像是公證處一樣，經過公證處認可的公鑰，那就是可以信任的。基於這種理念，前面的問題就可以解決了。客戶端不是不確定我們服務器的公鑰是否被篡改麼？找公證處問問就行了。實際上我們的做法是服務器的運營人員會向認證機構提供身份信息，並提出公鑰證書的申請。一般的公鑰和私鑰都是自己生成好的，然後認證機構會用自己的私鑰對你的公鑰進行數字簽名，簽名之後就能得到一個數字證書，這個證書包含了公鑰信息。用認證機構的私鑰對公鑰進行簽名的意義在於，認證機構是可信任的，認證機構的公鑰被預置於瀏覽器端已經接受到瀏覽器的信任。所以服務器的公鑰證書如果能在客戶端被受信任的公鑰解密，那麼說明這個證書本身也就是值得信賴的。
我們知道，在打開瀏覽器的安全選項的時候，有一個證書的列表，這就是瀏覽器廠商幫我們預置的證書，這些證書就是這個瀏覽器信任的。（這裏多嘴一句，後面我們對https數據進行竊聽，就需要生成第三方的證書並讓瀏覽器信任。比如，我們用burp進行竊聽，就需要生成一個證書。這個證書需要讓瀏覽器信任）
在真正通信的時候，服務器端將這個帶有認證機構認證的公鑰證書發出來。客戶端接到證書後可以用認證機構的公鑰對數字證書進行解密。如果解密成功，那麼這個證書就是經過認證的。
這裏還有一個小問題要注意，我們向認證機構申請公鑰證書的時候，還要提供自己的身份信息，還有服務器的ip，域名等信息。這些信息也會被添加到公鑰證書中。這樣做的好處就爲了防止證書的欺騙。
因爲服務器端發出去的公鑰證書，如果能被客戶端正常解密，其實只能說明這個公鑰證書來源沒問題，確實是通過認證的。但是如果出現中間人攻擊，攻擊者也同樣用認證後的證書發送給客戶端，那麼客戶端毋庸置疑也可以解密證書拿到裏面的公鑰。這時候客戶端這邊對證書的校驗工作就顯得尤爲重要了。解密後的公鑰會包含原來證書申請者的信息，所以客戶端在校驗證書的時候還需要校驗證書的信息與我們要訪問的對象信息是否符合。比如：證書是否已經過期，證書的域名，ip等是否就是我們當前訪問的ip等。一般瀏覽器或客戶端校驗證書時，都會先檢查證書是否是“受信任的根證書頒發機構”頒發，再檢查SSL證書中的證書吊銷列表，再檢查檢查此SSL證書是否過期，再檢查SSL證書的網站的域名是否與當前訪問域名一致。如果使用一個合法簽發的證書實際上可以通過大部分校驗。
只有經過這一系列的校驗，才能明確這個證書確實是經過公證的我們正在訪問的服務器端發過來的證書。
前面我們說了這麼多證書和認證的內容，這些在我們的https協議上都有具體的應用。現在回到我們的https協議上來看看，這套認證機制是如何應用的。
上面的一張圖展示了一個https 的握手包括密鑰協商大致整個過程。
這裏我們注意到，https 中混合使用了對稱加密和非對稱加密兩種，其實完全是可以從頭到尾使用非對稱加密的。但是有人從加密解密算法小效率上提出來了，如果一直使用非對稱加密，會造成通信效率的底下，尤其是不適合像客戶端和服務器之間這種高頻的通信過程中，所以使用非對稱加密，只是爲了保證我們密鑰的交換過程是安全的，一旦挖完成密鑰的交換，後續的就是使用對稱加密算法進行加密了。
當然，我們前面說了這麼多，其實都是單方向認證的，不知道大家注意了沒有。就是全部的內容，其實都是在做客戶端對服務器的驗證。即如何保證服務器是真正的服務器，而我們服務器並沒有對客戶端進行校驗。也就是服務器端不管誰來請求，都是沒問題的，所以後續，還會有雙向驗證的問題。當然過程也是和單項差不多的，無非是服務器端要驗證客戶端證書的合法性問題（具體的這裏先不做介紹）
證書的出現，一方面爲了解決數據的安全問題。另一方面，證書的申請需要提供真實的身份信息，因此也可以用來判定服務器背後的運營企業是否真實存在。
下面再介紹下證書的類型：
1、首先是EV SSL 證書，持有EV SSL證書的web網站在瀏覽器的地址欄會有綠色的顯示安全的提示，可以很容易分辨出來
2、由自認證機構頒發的證書。這種也叫自簽名證書，因爲openssl是開源的， 每個人都可以構建一套屬於自己的證書，當然這種證書肯定是沒通過第三方認證的，不過好處就是不用錢，也一樣可以起到加密的作用，所以也會有很多人使用這種自簽名證書。當然這種自簽名證書安全性不高，因爲它無法消除被證書欺騙的風險，也就是說攻擊者可以僞造證書並完成中間人攻擊。