學習敖丙，傳送門
http 是超文字傳輸協議，資訊是明文傳輸，存在安全風險的問題；https 則解決 http 不安全的缺陷，在 tcp 和 http 應用層之間加入了 ssl/tls 安全協議，使得報文能夠加密傳輸；
http 連線建立相對簡單，tcp 三次握手之後便可進行 http 的報文傳輸；而 https 在 tcp 三次握手之後，還需進行ssl/tls 的握手過程，才可進入加密報文傳輸；
http 的埠號是 80，https 的埠號是 443；
https 協議需要向 ca（證書權威機構）申請數字證書，來保證伺服器的身份是可信的；
https在 應用層（http） 與 傳輸層（tcp）層之間加入了ssl/tls協議；
https 的工作原理
https 採用的是對稱加密和非對稱加密結合的「混合加密」方式；
對稱加密：對稱加密是指有乙個金鑰，用它可以對一段明文加密，加密之後也只能用這個金鑰來解密得到明文。如果通訊雙方都持有金鑰，且天知地知你知我知，絕對不會有別的人知道，那麼通訊安全自然是可以得到保證的（在金鑰足夠強的情況下）；
非對稱加密：非對稱加密有兩個金鑰，乙個是公鑰，另乙個是私鑰。一般來說，公鑰用來加密，這時密文只能用私鑰才能解開。但是在傳輸時會準備兩組公鑰私鑰，這是因為單組公鑰私鑰只能保證單程的加解密，因此使用兩組。
服務端有非對稱加密的公鑰 a1，私鑰 a2；客戶端有非對稱加密的公鑰 b1，私鑰 b2；
客戶端向服務端發起請求，服務端將公鑰 a1 返回客戶端；
客戶端瀏覽器收到公鑰 a1後，將自己儲存的公鑰 b1 傳送給服務端；
之後服務端向客戶端傳送的所有資料，服務端使用公鑰 b1 進行加密，客戶端使用私鑰 b2 進行解密；
客戶端向服務端傳送的所有資料，客戶端使用公鑰 a1 進行加密，服務端使用私鑰 a2 進行解密。
但是 https 並沒有採用完全的非對稱加密，因為非對稱加解密耗時要遠大於對稱加解密，對效能有很大損耗；因此 https 使用的是對稱加密和非對稱加密。
服務端有非對稱加密的公鑰 a1，私鑰 a2；客戶端發起請求，服務端將公鑰 a1 返回給客戶端；客戶端隨機生成乙個對稱加密的金鑰 k，用公鑰 a1 加密後傳送給服務端；服務端收到密文後使用私鑰 a2 進行解密，得到對稱金鑰 k，此時完成了完全的對稱金鑰交換，解決了對稱加密時金鑰傳輸被人竊取的問題；之後雙方通訊都使用金鑰 k 進行對稱加解密。
此時，還不是完全的安全！！有下面這種情況：
出現這一問題的核心原因是客戶端無法確認收到的公鑰是不是真的是服務端發來的。為了解決這個問題，網際網路引入了乙個公信機構，這就是 ca。
服務端在使用 https 前，去經過認證的 ca 機構申請頒發乙份數字證書，數字證書裡包含有證書持有者、證書有效期、公鑰等資訊，服務端將證書傳送給客戶端，客戶端校驗證書身份和要訪問的**身份確實一致後再進行後續的加密操作。
並且該數字證書是被「數字簽名」後的，其實就是一種防偽技術，只要有人篡改了證書，那麼數字簽名必然校驗失敗；那麼就會有：
ca機構擁有自己的一對公鑰和私鑰
ca機構在頒發證書時對證書明文資訊進行雜湊
將雜湊值用私鑰進行加簽，得到數字簽名
明文資料和數字簽名組成證書，傳遞給客戶端。
客戶端得到證書，分解成明文部分 text 和數字簽名 sig1；
用 ca 機構的公鑰進行解籤，得到 sig2（由於 ca 機構是一種公信身份，因此在系統或瀏覽器中會內建 ca 機構的證書和公鑰資訊）；
用證書裡宣告的雜湊演算法對明文 text 部分進行雜湊得到 h；
當自己計算得到的雜湊值 h 與解籤後的 sig2相等，表示證書可信，沒有被篡改。
應用層協議分析 HTTPS協議分析
例項化secure socket layer ssl 俗稱安全套接層，是由netscape communitcation於1990年開發，用於保障word wide web www 通訊的安全。主要任務是提供私密性，資訊完整性和身份認證。1994年改版為sslv2，1995年改版為sslv3。tra...
表示層 應用層
表示層 功能 為異種機通訊提供一種公共語言，以便能進行互操作。這種型別的服務之所以需要，是因為不同的計算機體系結構使用的資料表示法不同。例如，ibm主機使用ebcdic編碼，而大部分pc機使用的是ascii碼。在這種情況下，便需要表示層來完成這種轉換。應用層 包含了通常要使用的協議 http協議 超...
應用層協議
應用層協議定義了執行在不同端系統上的應用程式程序如何相互傳遞訊息。特別是定義了 交換的訊息型別，如請求訊息和響應訊息。各種訊息型別的語法，如訊息中的各個字段及其詳細描述。欄位的語義，即包含在字段中的資訊的含義。程序何時 如何傳送訊息及對訊息進行響應的規則。有些應用層協議是由rfc文件定義的，因此它們...