https S 代表的是SSL/TLS
先做個實驗： 在瀏覽器的地址欄上輸入 http:\\www.meituan.com
用http header LIVE 抓個包如下
過程如下：
瀏覽器先以HTTP協議來連接服務器。服務器因配置了HTTPS，所以使用了302跳轉至https頁面，瀏覽器再去連接服務器的443端口。
上述小實驗只是https步驟的第一步 ，接下來先進行TCP三次握手，然后進行SSL/TLS四次握手
接下來就是難點了。再講難點之前，先講難點細分討論
什么是對稱加密
只有一個密鑰，它可以對內容進行加密，也可以用該密鑰對密文進行解密。
但問題來了，密鑰如何保護呢？
什么是公鑰加密 (非對稱加密)
有兩把密鑰，一把公鑰，一把私鑰，公鑰加密的內容必須用私鑰才能解開，私鑰加密的內容必須用公鑰解開
單個公鑰私鑰，只能保障單方向的安全性，為什么這么說呢
服務器將他的公鑰明文發送給瀏覽器，瀏覽器將數據用公鑰加密發給服務器，只有服務器有私鑰可以查看數據。
服務器將數據用私鑰加密發送給瀏覽器，瀏覽器用公鑰解密
想想看，公鑰是一開始是明文傳輸的，意味着只要截獲了公鑰就可以查看服務器發送的消息，那怎樣可以保障雙方向的通信安全呢？
服務器一對公鑰私鑰，瀏覽器一對公鑰私鑰
服務器明文傳輸自己的公鑰A給瀏覽器，瀏覽器明文傳輸自己的公鑰B給服務器
以后瀏覽器給服務器發送的數據都用公鑰A加密，服務器給瀏覽器發送的數據用公鑰B加密，這樣就保障了雙向通信的安全性
但非對稱性加密非常耗時，如何解決呢 ？
對稱加密+非對稱加密結合
瀏覽器用公鑰A將自己的對稱密鑰X發送給服務器
服務器用私鑰A解密獲得對稱密鑰X
雙方用對稱密鑰X進行數據交換
這樣看起來很安全，但其實還要一個小問題
在發送自己的公鑰給對面時，有個中間人截獲雙方的公鑰，並且把自己的公鑰發送給瀏覽器和服務器
這時候中間人就可以收到用中間人的公鑰加密的對稱密鑰X，這樣看來，還是很危險，客戶端根本不知道接受的公鑰是否可信
數字證書
數字證書是網站的身份證，有了證書就可以證明該網站的合法性；
網站在使用HTTPS之前，需要向CA機構申請一份數字證書，數字證書里有持有者和網站公鑰的信息，服務器只需要把證書傳給瀏覽器即可
但如何證明證書的真偽性呢？
數字簽名
把證書的內容生成一份簽名，對比證書的內容和簽名是否一致
簽名如何制作呢： 將證書的明文信息用hash函數加密一次得到一個固定長度的序列，稱消息摘要，哈希值，然后CA用私鑰進行加密得數字簽名 明文和數字簽名組成數字證書
如何驗證呢：用CA機構的公鑰對數字簽名進行解密，得到哈希值，用證書里的hash算法對證書明文進行hash ，查看兩次得到的hash是否相同
CA公鑰是否可信？
操作系統，瀏覽器會默認安裝信任的證書，證書里包含信任的公鑰
現在來理解一下四次握手：
1.創建一個屬於瀏覽器與服務器之間的session，避免多次重復驗證
2.服務器將自己的證書發送給瀏覽器
3.瀏覽器發送對稱密鑰給服務器
4.安全的會話建立，數據采用私鑰加密
https中涉及的數據包
client hello報文：
TSL版本
SID（session id）：保持會話；擴展：不過只保留在一台服務器上，如果請求域名的流量很大的時候，往往右很多的服務器提供服務，就無法恢復對話。采用session ticket
密文族：密鑰交換算法-對稱加密算法-哈希算法
server_name：請求訪問的域名
服務器在收到client hello報文后，會回復三個數據包
server hello：session id 、選擇的密文族、選擇的TSL版本
Certificate報文：服務器的數字證書
server hello done 和server key exchange
客戶端驗證證書的真偽： 根據數字簽名
密鑰交換：客戶端通過服務器的證書將非對稱加密的密鑰發送給服務器
到此建立TSL連接結束了 ，其中還要很多細節之處由於水平有限，未能提出