http協議沒有任何的加密以及身份驗證的機制，非常容易遭遇竊聽、劫持、篡改，因此會造成個人隱私洩露，惡意的流量劫持等嚴重的安全問題。
就像寄信一樣，我給你寄信，中間可能會經過很多的郵遞員，他們可以拆開信讀取裡面的內容，因為是明文的。如果你的信裡涉及到了你們銀行賬號等敏感資訊，可能就會被竊取。除此之外，郵遞員們還可以給你偽造信的內容，導致你遭到欺騙。
要解決上面的問題，就要引入加密以及身份驗證的機制。
如果我給你的信是密文的，只有我和你才能讀懂，就可以保證資料的保密性。這時問題來了，我把信加密後，你如何讀懂這封信呢？這時我必須要把加密的金鑰告訴你，你才能解開密文的內容。但是這個秘鑰如果以明文的方式給你還是會被中間的人截獲，依然無法保證保密性，如果以密文的方式給你，你又如何獲得這個密文的秘鑰呢？
這時我們引入了非對稱加密的概念，我們知道非對稱機密如果是公鑰加密的資料私鑰才能解密，所以我只要把公鑰發給你，你就可以用這個公鑰來加密未來我們進行資料交換的秘鑰，發給我時，即使中間的人擷取了資訊，也無法解密，因為私鑰在我這裡，只有我才能解密，我拿到你的資訊後用私鑰解密後拿到加密資料用的對稱秘鑰通過這個對稱金鑰來進行後續的資料加密。除此之外，非對稱加密可以很好的管理秘鑰，保證每次資料加密的對稱金鑰都是不相同的。
但是這樣似乎還不夠，如果中間人在收到我的給你公鑰後並沒有發給你，而是自己偽造了乙個公鑰發給你，這是你把對稱金鑰用這個公鑰加密發回經過中間人，他可以用私鑰解密並拿到對稱金鑰，此時他在把此對稱金鑰用我的公鑰加密發回給我，這樣中間人就拿到了對稱金鑰，可以解密傳輸的資料了。為了解決此問題，我們引入了數字證書的概念。我首先生成公私鑰，將公鑰提供給相關機構（ca），ca將公鑰放入數字證書並將數字證書頒布給我，此時我就不是簡單的把公鑰給你，而是給你乙個數字證書，數字證書中加入了一些數字簽名的機制，保證了數字證書一定是我給你的。
為什麼是協議簡介呢？因為https涉及的東西實在太多了，尤其是一些加密演算法，非常的複雜，對於這些演算法面的東西就不去深入研究了，這部分僅僅是梳理一下一些關於https最基本的原理，為後面分解https的連線建立以及https優化等內容打下理論基礎。
對稱加密是指加密和解密使用相同金鑰的加密演算法。它要求傳送方和接收方在安全通訊之前，商定乙個金鑰。對稱演算法的安全性依賴於金鑰，洩漏金鑰就意味著任何人都可以對他們傳送或接收的訊息解密，所以金鑰的保密性對通訊至關重要。
對稱加密又分為兩種模式：流加密和分組加密。
流加密是將訊息作為位流對待，並且使用數學函式分別作用在每乙個位上，使用流加密時，每加密一次，相同的明文位會轉換成不同的密文位。流加密使用了金鑰流生成器，它生成的位流與明文位進行異或，從而生成密文。現在常用的就是rc4，不過rc4已經不再安全，微軟也建議網路盡量不要使用rc4流加密。
分組加密是將訊息劃分為若干位分組，這些分組隨後會通過數學函式進行處理，每次乙個分組。假設需要加密發生給對端的訊息，並且使用的是64位的分組密碼，此時如果訊息長度為640位，就會被劃分成10個64位的分組，每個分組都用一系列數學公式公式進行處理，最後得到10個加密文字分組。然後，將這條密文訊息傳送給對端。對端必須擁有相同的分組密碼，以相反的順序對10個密文分組使用前面的演算法解密，最終得到明文的訊息。比較常用的分組加密演算法有des、3des、aes。其中des是比較老的加密演算法，現在已經被證明不安全。而3des是乙個過渡的加密演算法，相當於在des基礎上進行三重運算來提高安全性，但其本質上還是和des演算法一致。而aes是des演算法的替代演算法，是現在最安全的對稱加密演算法之一。分組加密演算法除了演算法本身外還存在很多種不同的運算方式，比如ecb、cbc、cfb、ofb、ctr等，這些不同的模式可能只針對特定功能的環境中有效，所以要了解各種不同的模式以及每種模式的用途。這個部分後面的文章中會詳細講。
對稱加密演算法的優、缺點：
優點：演算法公開、計算量小、加密速度快、加密效率高。
缺點：（1）交易雙方都使用同樣鑰匙，安全性得不到保證；
（2）每對使用者每次使用對稱加密演算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發收信雙方所擁有的鑰匙數量呈幾何級數增長，金鑰管理成為使用者的負擔。
（3）能提供機密性，但是不能提供驗證和不可否認性。
在非對稱金鑰交換演算法出現以前，對稱加密乙個很大的問題就是不知道如何安全生成和保管金鑰。非對稱金鑰交換過程主要就是為了解決這個問題，使得對稱金鑰的生成和使用更加安全。
金鑰交換演算法本身非常複雜，金鑰交換過程涉及到隨機數生成，模指數運算，空白補齊，加密，簽名等操作。
常見的金鑰交換演算法有rsa，ecdhe，dh，dhe等演算法。涉及到比較複雜的數學問題，下面就簡單介紹下最經典的rsa演算法。rsa：演算法實現簡單，誕生於2023年，歷史悠久，經過了長時間的破解測試，安全性高。缺點就是需要比較大的素數也就是質數（目前常用的是2048位）來保證安全強度，很消耗cpu運算資源。rsa是目前唯一乙個既能用於金鑰交換又能用於證書簽名的演算法。我覺得rsa可以算是最經典的非對稱加密演算法了，雖然演算法本身都是數學的東西，但是作為最經典的演算法，我自己也花了點時間對演算法進行了研究，後面會詳細介紹。
非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：
1、cpu計算資源消耗非常大。一次完全tls握手，金鑰交換時的非對稱解密計算量佔整個握手過程的90%以上。而對稱加密的計算量只相當於非對稱加密的0.1%，如果應用層資料也使用非對稱加解密，效能開銷太大，無法承受。
2、非對稱加密演算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是2048位，意味著待加密內容不能超過256個位元組。
所以公鑰加密目前只能用來作金鑰交換或者內容簽名，不適合用來做應用層傳輸內容的加解密。
https協議中身份認證的部分是由數字證書來完成的，證書由公鑰、證書主體、數字簽名等內容組成，在客戶端發起ssl請求後，服務端會將數字證書發給客戶端，客戶端會對證書進行驗證，並獲取用於秘鑰交換的非對稱金鑰。
數字證書有兩個作用：
1、身份授權。確保瀏覽器訪問的**是經過ca驗證的可信任的**。
2、分發公鑰。每個數字證書都包含了註冊者生成的公鑰。在ssl握手時會通過certificate訊息傳輸給客戶端。
申請乙個受信任的數字證書通常有如下流程：
1、終端實體（可以是乙個終端硬體或者**）生成公私鑰和證書請求。
2、ra（證書註冊及審核機構）檢查實體的合法性。如果個人或者小**，這一步不是必須的。
3、ca（證書簽發機構）簽發證書，傳送給申請者。
4、證書更新到repository（負責數字證書及crl內容儲存和分發），終端後續從repository更新證書，查詢證書狀態等。
數字證書驗證：
申請者拿到ca的證書並部署在**伺服器端，那瀏覽器發起握手接收到證書後，如何確認這個證書就是ca簽發的呢？怎樣避免第三方偽造這個證書？答案就是數字簽名（digital signature）。數字簽名是證書的防偽標籤，目前使用最廣泛的sha-rsa（sha用於雜湊演算法，rsa用於非對稱加密演算法）數字簽名的製作和驗證過程如下：
1、數字簽名的簽發。首先是使用雜湊函式對待簽名內容進行安全雜湊，生成訊息摘要，然後使用ca自己的私鑰對訊息摘要進行加密。
2、數字簽名的校驗。使用ca的公鑰解密簽名，然後使用相同的簽名函式對待簽名證書內容進行簽名並和服務端數字簽名裡的簽名內容進行比較，如果相同就認為校驗成功。
需要注意的是：
1）數字簽名簽發和校驗使用的金鑰對是ca自己的公私金鑰，跟證書申請者提交的公鑰沒有關係。
2）數字簽名的簽發過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。
3）現在大的ca都會有證書鏈，證書鏈的好處一是安全，保持根ca的私鑰離線使用。第二個好處是方便部署和撤銷，即如果證書出現問題，只需要撤銷相應級別的證書，根證書依然安全。
4）根ca證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的製作和驗證。而證書鏈上的證書簽名都是使用上一級證書的金鑰對完成簽名和驗證的。
5）怎樣獲取根ca和多級ca的金鑰對？它們是否可信？當然可信，因為這些廠商跟瀏覽器和作業系統都有合作，它們的公鑰都預設裝到了瀏覽器或者作業系統環境裡。
資料傳輸過程中的完整性使用mac演算法來保證。為了避免網路中傳輸的資料被非法篡改，ssl利用基於md5或sha的mac演算法來保證訊息的完整性。 mac演算法是在金鑰參與下的資料摘要演算法，能將金鑰和任意長度的資料轉換為固定長度的資料。傳送者在金鑰的參與下，利用mac演算法計算出訊息的mac值，並將其加在訊息之後傳送給接收者。接收者利用同樣的金鑰和mac演算法計算出訊息的mac值，並與接收到的mac值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改，接收者將丟棄該報文。 由於md5在實際應用中存在衝突的可能性比較大，所以盡量別採用md5來驗證內容一致性。sha也不能使用sha0和sha1，中國山東大學的王小雲教授在2023年就宣布破解了 sha-1完整版演算法。微軟和google都已經宣布16年及17年之後不再支援sha1簽名證書。mac演算法涉及到很多複雜的數學問題，這裡就不多講細節了。
這篇文章是本人對https進行一定研究並參考了大量的文件梳理出來的一些重要的技術點以及其原理，必須在搞明白這些原理的基礎上才能進一步深入分析https的詳細報文。這篇文章作為開篇第一篇主要是簡單介紹一下https相關的知識點，關於深入的報文互動過程以及加密演算法原理相關，會在後面的中文逐一介紹。
https協議 什麼是HTTPS協議？
在我們平常上網的時候我經常接觸的 應該大部分都是 或者我們知道讓他是乙個超文字傳輸協議。那麼https是個什麼？雖然http和這個https兩者只差乙個s，但是本質是大不相同的，他們是兩種不同的網路傳輸協議。千萬不要搞混淆了。http協議通過請求 響應的方式，在客戶端和服務端之間進行通訊。這一切看起...
SSL協議 HTTPS協議
ssl secure socket layer安全套接層 tls transport layer security傳輸層安全，是被標準化的ssl pki 公鑰基礎設施 pki提供電子簽名證書，伺服器購買證書 網路伺服器通過證書被認證，客戶端則不需要認證。tls的三個階段 1.協商金鑰演算法 2.通過...
HTTP協議 HTTPS協議
http協議是基於tcp協議的，當然是要先建立tcp連線了。目前使用的http協議大部分都是1.1.在1.1的協議裡面，預設是開啟了keep alive的，這樣建立的tcp連線，就可以在多次請求中復用。http的報文大概分成三大部分。第一部分是請求行，第二部分是請求的首部，第三部分才是請求的正文實體...