http的缺點
http的數據是明文傳輸
如果用明文傳輸 很容易被第三方獲取到傳輸的數據 因此我們一般要在網絡傳輸過程中對數據進行加密
常見的加密方式
對稱加密
秘鑰key 待加密數據data
a和b是兩個主機，它們都有秘鑰key ，
a傳輸data會先用key進行加密，生成密文DATA，
b拿到DATA后再用key解密，獲取到data
問題： key可能被第三方獲取，從而得到原數據data
非對稱加密
公鑰publick_key 私鑰private_key 可以公鑰加密，私鑰解密，也可以私鑰加密，公鑰解密
a第一次請求，b給a返回公鑰，
a第二次請求，給b傳輸用公鑰加密后的密文DATA，
b收到后 用私鑰解密DATA，拿到原數據data
由於私鑰只有b才擁有，因此第三方無法獲取私鑰，自然無法對加密數據進行解密
問題：如果b向a發送數據的話 如果用公鑰加密 但a沒有私鑰 所以無法解密 ；如果用私鑰加密，a用公鑰解密，但是第三方也能拿到公鑰。
既然都不行，那該怎么解決呢？
對稱加密+非對稱加密
- 先使用非對稱加密 得到公鑰 再利用公鑰生成一個傳輸秘鑰 進行雙方的數據傳輸
- client第一次請求，server給client返回公鑰，
- client拿到公鑰，再生成一個隨機字符串，使用公鑰對這個字符串進行加密，傳給server
- server收到后 用私鑰解密出字符串，這個字符串用來作為之后雙方進行數據傳輸的對稱秘鑰
問題： 中間人攻擊
在client 向server請求公鑰時 中間人攔截請求 並向client發送自己的公鑰 因此中間人就可以在之后的傳輸過程中查看和篡改數據
中間人攻擊的產生原因以及如何避免？
產生原因： 無法確認server的身份
需要有CA（證書頒發機構）對網站身份進行認證
申請證書
服務端將域名和公鑰傳給CA CA有自己的公鑰和私鑰，然后給服務端下發證書。
證書的內容主要有： 域名， 證書頒發機構相關信息， 用CA私鑰加密過后的服務器公鑰， 用CA私鑰加密過后證書簽名。
服務器會用CA公鑰解密，獲取證書簽名 ，
證書簽名是由服務器域名 + CA公鑰 + 服務器公鑰，通過hash算法加密而成的一段信息
證書簽名用來驗證是否被篡改
服務器收到證書，會用域名、 CA公鑰、 自己公鑰生成一個簽名 檢查該簽名是否和證書的簽名一致 一致則說明沒有被篡改
https傳輸流程
- client向server發起請求 ，server先返回一個證書
- 由於client的操作系統中存有ca的公鑰 因此可以對證書的密文進行解密，獲取到服務器的公鑰和證書簽名。
- client驗證證書簽名 也就是用證書上的域名 + CA公鑰 + 服務器公鑰用hash算法進行加密 把加密結果和證書簽名進行對比 若結果一致 就證明證書簽名沒有被篡改 沒有被篡改的話 client就可以生成一個隨機字符串
- 隨機字符串用服務器公鑰進行加密，傳給server
- server收到后解密拿到隨機字符串，作為之后雙方傳輸數據的公鑰
如果client獲取到的證書是沒有認證的 網頁就會提示證書是不安全的
https傳輸過程中能否被篡改？
1.中間人能否篡改證書的公鑰和證書簽名？
由於每個CA公鑰是公開的，所以中間人也有，能夠揭秘獲取到服務器公鑰和證書簽名，中間人如果想修改這兩個數據，則需要用中間人自己的私鑰進行加密，但是client會用CA公鑰解密，自然是解不開的，所以無法篡改。
2.中間人能否篡改證書的域名？
驗證簽名的過程會出錯，因為client需要將域名、 CA公鑰、 自己公鑰用hash算法生成一個簽名，再和證書上的簽名對比，此時發現不一致，則說明域名、 CA公鑰、 自己公鑰被篡改過了。
3.中間人能否在client請求證書時就攔截，並返回一個中間人自己的證書？
其實是可以的，但需要得到client的同意，信任此證書才行。這也是抓包工具可以截取到https傳輸過程中數據的原因。但也會有第三方利用這一點，出現個彈窗誘導用戶點擊，就可以給client植入“木馬病毒”，這樣就能獲取和篡改client和server的數據。
大家如果對木馬感興趣的話，之后會准備下知識點，詳細介紹一下～~