一.HTTPS是什么

HTTPS也是一個應用層協議，是在HTTP協議的基礎上引入了一個加密層（SSL）

HTTP協議內容都是按照文本的方式明文傳輸的，這就導致傳輸過程中可能出現被篡改的情況

最著名的就是十多年前網絡剛發展的時期，出現“運營商劫持”，當時普遍使用的HTTP協議，因此就出現客戶端發給服務器請求，服務器返回響應的結果，在返回的過程中被運營商劫持了，運營商就更改其中某些響應的數據，再發回給客戶端

最典型的就是廣告模塊，廣告商投錢給網站，網站就會當用戶查詢后，返回其相關的廣告

其中廣告收費模式大多也是CPC（按點擊計費），那么這計算點擊次數肯定不可能只讓其中一方進行統計，而是廣告商和網站雙方都進行統計，最后核對雙方統計是否一致，如果不一致，那么程序員再來查到底是哪里出現問題

當時就經常出現，廣告商統計的次數比網站統計的次數少，那么網站方的程序員就去查程序記錄，但是怎么也沒找到問題，查詢的次數就是網站當前統計的次數，廣告商也不服氣，自己這邊明明也只被點擊了這么多次，卻要交網站多統計出來錢，最后網站也只能啞巴吃榴蓮，有苦說不出

時間一長，這種事就流傳開來了，因為不止一家網站會出現這種情況，而是許多家，最后內部人員也透露，是被運營商劫持了

即用戶發給網站請求，網站接收請求并返回響應，其中就包括廣告商的廣告，但是這個返回的響應被運營商劫持了，將其中的廣告換成跟自己運營商有利益關系的廣告商，這時再返回給用戶，那么此時用戶點擊廣告，但這個廣告不是網站返回的廣告，而是運營商劫持后修改的廣告，那么就導致網站這邊統計了廣告點擊次數，而真正的廣告商根本沒有接收到點擊，因此就出現了不一致的情況

所以網站作為反制手段，就對HTTP協議進行了加密，即HTTPS，這樣就能防止運營商對其中的內容進行篡改

二.什么是加密

要傳輸的內容叫做明文，明文經過加密，再看到的就是密文

解密則是將密文經過解密，得到的就是明文

而加密和解密的過程中，往往需要密鑰

而密鑰又往往分為公鑰和私鑰，公鑰是公開的，大家都知道的，而私鑰則是私密的，別人不知道的，公鑰是由私鑰推導而生成的

三.HTTPS的工作過程

1.引入對稱加密

首先加密方式主要有兩種：對稱加密和非對稱加密

對稱加密是指加密解密用的是同一個密鑰，這個密鑰是私鑰

非對稱加密是指加密解密用不同的密鑰，一個公鑰，一個私鑰

這兩個加密方式各有優缺點，其中非對稱加密的運輸速度非常慢，比對稱加密要慢的多

那么也許就會說，我們就選對稱加密就好了呀

但是有一個問題，即一開始客戶端和服務端要設置對稱加密的密鑰，如果客戶端說“我們使用密鑰*****”，服務端說“好的好的”

那么這兩段話是沒有使用密鑰加密的，必須要等這兩段話后，雙方才使用剛剛設定的密鑰進行加密解密，所以在這兩段對話時就有可能已經被其他人知道了，那么后面的加密解密操作也就相當于掩耳盜鈴了

如果你說那給這兩段話也進行密鑰加密，當然也可以，但是新生成的這個密鑰又要先經過雙方溝通才能知道，而這段溝通也是未被加密的，因此就陷入俄羅斯套娃的情況了

因此我們就需要引入非對稱加密

2.引入非對稱加密

服務端生成非對稱加密的私鑰，然后匹配出公鑰并公開給客戶端，客戶端拿到公鑰，同時生成對稱密鑰

客戶端說“我們使用對稱加密密鑰****”，然后使用非對稱加密的公鑰進行加密

而此時服務器接收到這段密文，用非對稱加密的私鑰解密，獲取到“我們使用對稱加密密鑰****”這段話，于是服務端說“好的好的”，并用對稱加密密鑰進行加密

客戶端接收到服務端的密文，用對稱加密密鑰解密得到“好的好的”

然后雙方就可以拋棄非對稱加密，使用約定的對稱加密進行對話即可

3.中間人攻擊

雖然上述使用非對稱加密后，再使用對稱加密，看起來似乎好像就安全了，但實際上并不安全

比如AB要做生意，雙方僅僅只是聽說過但沒有聯系方式，這時有個中間人C，C認識AB且有聯系方式，于是AB就讓C搭橋牽線，C也有一個朋友D，于是劇情如下

一開始AB都以為：

A找C聯系B，B來人跟A磋商，一來一回就能達成交易

實際上：

A找C聯系B，結果C卻讓D來，于是A以為D是B，將交易條件和細節告訴了D

D把A的交易條件和細節告訴B，B以為D是A，于是又將交易條件和細節告訴了D

于是一來一回，AB也能達成交易，但是神不知鬼不覺的情況下就多了一個中間人，而這個中間人把握了雙方所有的交易信息

回到客戶端和服務端上

剛剛介紹的都是雙方以為的

但實際上就有可能：

服務端生成非對稱加密的私鑰A，然后匹配出公鑰A并公開給客戶端的時候，被黑客攔下了，然后修改為公鑰B，并自己生成私鑰B，再傳給客戶端

客戶端拿到公鑰B，說“我們使用對稱加密密鑰****”，并用公鑰B加密，此時黑客用私鑰B對此解密，獲取到“我們使用對稱加密密鑰****”這段話，得到對稱加密密鑰，然后再將這段話用公鑰A加密，返回給服務端

服務端用私鑰A進行解密，獲取到“我們使用對稱加密密鑰****”這段話，于是客戶端和服務端就拋棄非對稱加密密鑰，使用對稱加密密鑰進行加密解密

但是對稱加密密鑰已經被黑客得知了，所以客戶端和服務端之間的加密也是如同虛設的，且還是在雙方毫無察覺的情況下知道的

這就是中間人攻擊

4.引入證書

中間人攻擊之所以能成功，就是因為客戶端無法分辨發來的信息是否來自服務端，同理，服務端也無法分辨發來的信息是否來自客戶端，所以要防止中間人攻擊，就必須解決識別信息來源的問題

簡單來說就是引入第三方公證機構，服務器將自己的信息發給公證機構

信息包括：證書的公證機構是誰，證書有效期多久，服務器的非對稱加密的公鑰，服務器的域名

公證機構就會對上述信息進行一些公式計算，也就是密鑰加密，得到一串數字，叫做“校驗和”，也就作為數字簽名返回給服務器

于是服務器就將信息和數字簽名發給客戶端，其中信息還是發給公證機構的信息，信息和數字簽名統稱為一張數字證書

其中信息都是明文公開的，誰都看得到

這時客戶端拿到數字證書，將信息也發給公證機構計算校驗和，如果校驗和=數字簽名，就說明這個信息未被篡改，可以信息，如果！=，則說明信息被修改了，不可信

也許你會說黑客難道就不能偽造修改證書嗎

如果黑客攔截了服務器發來的數字證書，按照往常修改信息中非對稱加密的密鑰，那么再返回給客戶端，客戶端拿到公證機構驗證，就會發現數字簽名對不上，所以不行

那黑客能不能再把數字簽名也給篡改了呢，那就是不行了，因為黑客要將自己篡改后的信息生成符合公證機構的校驗和，只有兩種選擇，一是將篡改后的信息也按正常流程去申請證書，但此時黑客的實際域名和篡改信息中服務器的域名發生沖突，公證機構拒絕頒布證書。二是獲取公證機構的私鑰，將篡改信息自己進行加密，這風險難度很大，公證機構比較是專業的，不是黑客想偷就能偷走的，如果真有這種技術，那還不如直接去偷服務器公開給客戶端公鑰對應的私鑰，然后用私鑰解密客戶端采用的對稱加密密鑰，這難度也比去偷公證機構私鑰簡單

所以綜上，就解決了中間人攻擊的問題

所以通過這一套HTTPS工作流程下來，之前出現的“運營商劫持”這種中間人攻擊就失效了，同時也基本替代了HTTP協議，如今網絡上大部分都是HTTPS協議的網站，幾乎沒有純HTTP協議的網站了