我們都知道https能夠加密資訊，以免敏感資訊被第三方獲取。所以很多銀行**或電子郵箱等等安全級別較高的服務都會採用https協議。
https其實是有兩部分組成：http + ssl / tls，也就是在http上又加了一層處理加密資訊的模組。服務端和客戶端的資訊傳輸都會通過tls進行加密，所以傳輸的資料都是加密後的資料。具體是如何進行加密，解密，驗證的，且看下圖。
這個沒什麼好說的，就是使用者在瀏覽器裡輸入乙個https**，然後連線到server的443埠。
採用https協議的伺服器必須要有一套數字證書，可以自己製作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和乙個鎖頭，只是全世界只有你乙個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然後發給你，因為只有你乙個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。
這個證書其實就是公鑰，只是包含了很多資訊，如證書的頒發機構，過期時間等等。
這部分工作是有客戶端的tls來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出乙個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成乙個隨即值。然後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。
這部分傳送的是用證書加密後的隨機值，目的就是讓服務端得到這個隨機值，以後客戶端和服務端的通訊就可以通過這個隨機值來進行加密解密了。
服務端用私鑰解密後，得到了客戶端傳過來的隨機值(私鑰)，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將資訊和私鑰通過某種演算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密演算法夠彪悍，私鑰夠複雜，資料就夠安全。
這部分資訊是服務段用私鑰加密後的資訊，可以在客戶端被還原
客戶端用之前生成的私鑰解密服務段傳過來的資訊，於是獲取了解密後的內容。整個過程第三方即使監聽到了資料，也束手無策。
--eof--
我們知道，http請求都是明文傳輸的，所謂的明文指的是沒有經過加密的資訊，如果http請求被黑客攔截，並且裡面含有銀行卡密碼等敏感資料的話，會非常危險。為了解決這個問題，netscape 公司制定了https協議，https可以將資料加密傳輸，也就是傳輸的是密文，即便黑客在傳輸過程中攔截到資料也無法破譯，這就保證了網路通訊的安全。
在正式講解https協議之前，我們首先要知道一些密碼學的知識。
明文： 明文指的是未被加密過的原始資料。
密文：明文被某種加密演算法加密之後，會變成密文，從而確保原始資料的安全。密文也可以被解密，得到原始的明文。
金鑰：金鑰是一種引數，它是在明文轉換為密文或將密文轉換為明文的演算法中輸入的引數。金鑰分為對稱金鑰與非對稱金鑰，分別應用在對稱加密和非對稱加密上。
對稱加密：對稱加密又叫做私鑰加密，即資訊的傳送方和接收方使用同乙個金鑰去加密和解密資料。對稱加密的特點是演算法公開、加密和解密速度快，適合於對大資料量進行加密，常見的對稱加密演算法有des、3des、tdea、blowfish、rc5和idea。
其加密過程如下：明文 + 加密演算法 + 私鑰 => 密文
解密過程如下：密文 + 解密演算法 + 私鑰 => 明文
對稱加密中用到的金鑰叫做私鑰，私鑰表示個人私有的金鑰，即該金鑰不能被洩露。
其加密過程中的私鑰與解密過程中用到的私鑰是同乙個金鑰，這也是稱加密之所以稱之為「對稱」的原因。由於對稱加密的演算法是公開的，所以一旦私鑰被洩露，那麼密文就很容易被破解，所以對稱加密的缺點是金鑰安全管理困難。
非對稱加密：非對稱加密也叫做公鑰加密。非對稱加密與對稱加密相比，其安全性更好。對稱加密的通訊雙方使用相同的金鑰，如果一方的金鑰遭洩露，那麼整個通訊就會被破解。而非對稱加密使用一對金鑰，即公鑰和私鑰，且二者成對出現。私鑰被自己儲存，不能對外洩露。公鑰指的是公共的金鑰，任何人都可以獲得該金鑰。用公鑰或私鑰中的任何乙個進行加密，用另乙個進行解密。
被公鑰加密過的密文只能被私鑰解密，過程如下：
明文 + 加密演算法 + 公鑰 => 密文， 密文 + 解密演算法 + 私鑰 => 明文
被私鑰加密過的密文只能被公鑰解密，過程如下：
明文 + 加密演算法 + 私鑰 => 密文， 密文 + 解密演算法 + 公鑰 => 明文
由於加密和解密使用了兩個不同的金鑰，這就是非對稱加密「非對稱」的原因。
非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少量資料進行加密。
在非對稱加密中使用的主要演算法有：rsa、elgamal、rabin、d-h、ecc（橢圓曲線加密演算法）等。
https協議 = http協議 + ssl/tls協議，在https資料傳輸的過程中，需要用ssl/tls對資料進行加密和解密，需要用http對加密後的資料進行傳輸，由此可以看出https是由http和ssl/tls一起合作完成的。
ssl的全稱是secure sockets layer，即安全套接層協議，是為網路通訊提供安全及資料完整性的一種安全協議。ssl協議在2023年被netscape發明，後來各個瀏覽器均支援ssl，其最新的版本是3.0
tls的全稱是transport layer security，即安全傳輸層協議，最新版本的tls（transport layer security，傳輸層安全協議）是ietf（internet engineering task force，internet工程任務組）制定的一種新的協議，它建立在ssl 3.0協議規範之上，是ssl 3.0的後續版本。在tls與ssl3.0之間存在著顯著的差別，主要是它們所支援的加密演算法不同，所以tls與ssl3.0不能互操作。雖然tls與ssl3.0在加密演算法上不同，但是在我們理解https的過程中，我們可以把ssl和tls看做是同乙個協議。
https為了兼顧安全與效率，同時使用了對稱加密和非對稱加密。資料是被對稱加密傳輸的，對稱加密過程需要客戶端的乙個金鑰，為了確保能把該金鑰安全傳輸到伺服器端，採用非對稱加密對該金鑰進行加密傳輸，總的來說，對資料進行對稱加密，對稱加密所要使用的金鑰通過非對稱加密傳輸。
以下來自於limboy的部落格
https在傳輸的過程中會涉及到三個金鑰：
伺服器端的公鑰和私鑰，用來進行非對稱加密
客戶端生成的隨機金鑰，用來進行對稱加密
乙個https請求實際上包含了兩次http傳輸，可以細分為8步。
1.客戶端向伺服器發起https請求，連線到伺服器的443埠
2.伺服器端有乙個金鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，伺服器端儲存著私鑰，不能將其洩露，公鑰可以傳送給任何人。
3.伺服器將自己的公鑰傳送給客戶端。
4.客戶端收到伺服器端的公鑰之後，會對公鑰進行檢查，驗證其合法性，如果發現發現公鑰有問題，那麼https傳輸就無法繼續。嚴格的說，這裡應該是驗證伺服器傳送的數字證書的合法性，關於客戶端如何驗證數字證書的合法性，下文會進行說明。如果公鑰合格，那麼客戶端會生成乙個隨機值，這個隨機值就是用於進行對稱加密的金鑰，我們將該金鑰稱之為client key，即客戶端金鑰，這樣在概念上和伺服器端的金鑰容易進行區分。然後用伺服器的公鑰對客戶端金鑰進行非對稱加密，這樣客戶端金鑰就變成密文了，至此，https中的第一次http請求結束。
5.客戶端會發起https中的第二個http請求，將加密之後的客戶端金鑰傳送給伺服器。
6.伺服器接收到客戶端發來的密文之後，會用自己的私鑰對其進行非對稱解密，解密之後的明文就是客戶端金鑰，然後用客戶端金鑰對資料進行對稱加密，這樣資料就變成了密文。
7.然後伺服器將加密後的密文傳送給客戶端。
8.客戶端收到伺服器傳送來的密文，用客戶端金鑰對其進行對稱解密，得到伺服器傳送的資料。這樣https中的第二個http請求結束，整個https傳輸完成。
HTTPS工作原理和TCP握手機制
https在傳輸資料之前需要客戶端 瀏覽器 與服務端 之間進行一次握手，在握手過程中將確立雙方加密傳輸資料的密碼資訊。tls ssl協議不僅僅是一套加密傳輸的協議，更是一件經過藝術家精心設計的藝術品，tls ssl中使用了非對稱加密，對稱加密以及hash演算法。握手過程的具體描述如下 1.瀏覽器將自...
HTTPS工作原理和TCP握手機制
原文出處 https在傳輸資料之前需要客戶端 瀏覽器 與服務端 之間進行一次握手，在握手過程中將確立雙方加密傳輸資料的密碼資訊。tls ssl協議不僅僅是一套加密傳輸的協議，更是一件經過藝術家精心設計的藝術品，tls ssl中使用了非對稱加密，對稱加密以及hash演算法。握手過程的具體描述如下 1....
HTTPS通訊機制
使用http協議進行通訊時，由於傳輸的是明文所以很容易遭到竊聽，就算是加密過的資訊也容易在傳輸中遭受到篡改，因此需要在http協議基礎上新增加密處理，認證處理等，有了這些處理機制的http成為https。https是在應用層和傳輸層之間加入了ssl secure socket layer 安全套接層...