在網購過程中，如果使用純粹的http協議，那麼使用者的賬號密碼，信用卡，銀行卡資訊都將在資訊傳輸過程中直接裸奔。從例子中我們可以看到信用卡資訊直接被明文傳輸了。除了明文傳輸之外，還存在著以下兩個問題:
無法驗證通訊方身份的真實性，即無法確認對方是否是真正的商家。
無法確認資訊是否被篡改，即無法確認傳輸過程信用卡資訊和收貨位址是否被篡改過。
常規情況下，可以對通訊的內容進行加密，來避免明文傳輸的問題。但是單靠這點，無法解決資訊完整性和認證問題。為了解決這些問題，需要對通訊進行加密。也就引入了 https 。
https 本身並不是乙個協議，它使用 ssl/tls 作為對通訊加密的協議，承載 http ，將兩種協議疊加，來實現對 http 通訊進行加密的目的。二者的關係為http+加密+認證+完整性保護=https單純從層次上對比二者的差異為：
即在 http 協議下又加了一層 ssl，計算機網路通訊過程的資訊流動方向是傳送方資訊由上到下進行包裝，然後接收方將資訊由下到上進行解包。上述的購物場景，如果使用了 ssl/tls 承載 http，那麼通訊的流程將會變化成如下圖：
無論是客戶端，還是服務端，訊息傳送的時候，都是從上往下，經過了 ssl/tls 加密，然後接收的時候再由下往上解密。
看到這裡你可能對流程已經有所理解，但又存在疑惑： ssl/tls 是什麼東西？
ssl（secure socket layer），稱為安全套接層，是2023年網景公司設計的一種安全協議，用於解決了網路通訊安全和資料完整性問題。第乙個版本的tls（transport layer security） 是在 ssl3.0基礎上設計的，可以理解為 ssl 3.1。後續的 tls 版本又加入了更多特性，可以把它理解為是 ssl 的公升級版。
目前普遍的說法是 ssl/tls 無法確切地被劃分到 osi 或者 tcp/ip 的具體某一層。從邏輯上來講，ssl/tls 的加密功能正好能和 osi的表示層相對應，但是一些應用程式會把它當做傳輸層。所以比較保守的說法是ssl/tls介於傳輸層和應用層之間。
ssl/tls 不僅可以承載 http，也可以承載其他應用層協議。
協議本身可以分成兩層，上層是握手協議，下層是記錄協議。如下圖：
上層又分成了4個子協議，其中第乙個握手協議是最重要的，它的作用是確認雙方使用的密碼套件，雙方共享金鑰，基於證書的認證操作。 其他三個子協議的作用分別是：
記錄協議位於下層，它的作用是使用對稱加密的方式對訊息進行加密通訊，過程可以再進一步細分為：
將訊息分割成多個片段，每個片段進行壓縮。
壓縮後的片段，加上訊息認證碼，用於保證完整性，並進行資料認證。訊息認證碼的金鑰在握手結束後可以生成，下面會介紹。
上面生成的東西，通過對稱加密，加密使用cbc模式，而cbc模式的初始化向量，以及對稱加密的金鑰，都可以在握手完成，通過主密碼生成，下面會介紹。
經過上面加密之後，再加上乙個報頭，就是最後的報文資料了。這個報頭由資料型別，版本號，壓縮後的長度組成。其中資料型別是上層握手協議的4個子協議之一。
我們知道 http 是基於 tcp 來完成的，tcp有握手過程，https同樣也有握手過程。當我們談論 https的時候，其實更側重的是談論 ssl。
預設情況下 http 通訊，客戶端會開啟一條到伺服器端口80的連線。而 https 則會開啟一條到伺服器端口443的連線。 tcp 連線建立後，會初始化 ssl，溝通加密引數，交換金鑰，完成握手過程後，ssl 初始化完成。然後就可以加密通訊了。
我們在談論https握手過程，其實就是ssl的握手過程。這個握手過程分成4個部分。下面將詳細地解析這4個部分。
一： 客戶端 -> 服務端
客戶端向服務端傳送client hello，告訴服務端它能理解的密碼套件（rsa/3des等），壓縮方式，會話id,當前時間，ssl/tls 協議的可用版本，客戶端隨機數。
二： 服務端 -> 客戶端
服務端向客戶端傳送server hello。
服務端傳送certificate，以及把證書清單發給客戶端,裡面包含了公開金鑰的證書。
certificate不足以滿足需求的時候，還會傳送 serverkeyexchange，告訴客戶端使用這些資訊來進行金鑰交換。
服務端向客戶端傳送certificaterequest訊息，傳送了服務端能理解的證書型別清單和能理解的的認證機構名稱清單。
serverhellodone
三： 客戶端 -> 服務端
如果收到 certificaterequest，會向服務端傳送certificate訊息，以及傳送自己的證書。
傳送 clientkeyexchange以及經過加密的預備主密碼（隨機數）。這個報文是經過加密的，加密的公鑰就是服務端傳送certificate時，發給客戶端的公鑰。
如果收到 certificaterequest，還會傳送 certificateverify訊息，告訴服務端它就時客戶端證書的持有者本人。
客戶端傳送changecipherspec訊息，告訴服務端要切換密碼了（實際上這個是密碼規則更變協議裡的東西）。服務端收到這個訊息後，雙方同時切換密碼
客戶端傳送 finished （這時候客戶端使用已經切換後的密碼套件來傳送）
四： 服務端 -> 客戶端
服務端傳送 changecipherspec，告訴客戶度要切換密碼了
服務端傳送 finished 表示結束。 然後就切換到了應用資料協議。之後雙方使用應用資料協議和tls記錄協議來進行密碼通訊。
握手過程一共完成的工作有：
客戶端獲得服務端的合法公鑰（第二部分第二點），完成服務端認證。
服務端獲得客戶端的合法公鑰（第三部分第一點），完成客戶端認證。
雙端生成通訊中對稱加密的共享金鑰。
雙端生成訊息認證中的共享金鑰。
https 採用了混合加密機制。在握手環節使用公鑰加密方式。通訊建立後，交換報文時，使用共享金鑰加密，也就是上面第3和第4點。對稱加密會比非對稱加密快很多，提高通訊過程的效率。共享金鑰的生成過程，可以從這張圖中去理解。
客戶端和服務端可以擁有一樣的預備主密碼，在握手的開始階段，雙方協商了共同使用什麼密碼套件。預備主密碼同時使用由密碼套件中兩個單向雜湊函式（md5和sha-1）組合的偽隨機數生成器，生成主密碼（客戶端的預備主密碼也是使用偽隨機數生成）。兩端都會根據這個一樣的預備主密碼，計算出一樣的主密碼。然後再由一樣的主密碼，生成下面三個：
每一樣都有兩份，即客戶端發往服務端，和服務端發往客戶端。所以主密碼一共可以生成6種資訊。
以上就是https握手過程的詳細解析。握手建立完成後，客戶端和服務端有擁有對稱加密的金鑰，那麼就可以使用這個金鑰對通訊內容進行加密了。
總結一下，https多做了什麼，它和http有什麼不一樣。
**密碼技術
http權威指南
transport layer security
https提供安全的web通訊 帶路
https提供安全的web通訊1.原理部分 1 了解加密演算法 加密演算法的分類 對稱加密和非對稱加密a.對稱加密 加密和解密使用同乙個金鑰，優點是速度快，缺點是金鑰的共享困難。典型的對稱加密演算法有des aes rc5 3des等。b.非對稱加密 生成乙個秘密對 公鑰和私鑰 加密過程中可以是私鑰...
確保Web安全的HTTPS
http主要又如下幾點不足 http 加密 認證 完整性保護 https https並非是應用層的一種新協議，只是http通訊介面部分用ssl secure socket layer 和tls transport layer security 協議代替而已。https其實就是身披ssl協議這層外殼的...
確保Web安全的HTTPS
證明身份 無法證明報文的完整性 證明公開金鑰正確性地證書 按tcp ip協議族的工作機制,通訊內容在所有的通訊線路上都有可能遭到窺視.為防止竊聽並保護資訊,有如下幾種加密方式 通訊加密 http協議沒有加密機制,但可以通過ssl或tls的組合使用,加密http通訊內容.與ssl組合使用的http被稱...