<sub id="gqw76"><listing id="gqw76"></listing></sub>
      <sub id="gqw76"><listing id="gqw76"></listing></sub>

    1. <form id="gqw76"><legend id="gqw76"></legend></form>
    2. HTTPS:網絡安全攻堅戰

      本文為《三萬長文50+趣圖帶你領悟web編程的內功心法》第五個章節。

      5、HTTPS

      我們知道,明文傳輸和不安全是HTTP的其中一個特點,但是隨著越來越多機密的業務交易轉移到線上,如銀行轉賬、證券交易、在線支付、電商等,我們對傳輸的安全性有了更高的要求,為此,出現了HTTP的擴展:HTTPS,Hypertext Transfer Protocol Secure,超文本傳輸安全協議。

      HTTPS默認端口號為443,基于HTTP擴展了安全傳輸的特性,其他特性完全沿用HTTP。

      5.1、HTTPS協議架構

      我們先來看一看HTTP的協議架構和HTTPS協議架構的區別:

      image-20200905173347776

      HTTP是基于TCP/IP的協議,中間沒有任何安全傳輸相關的模塊。為此,HTTPS在中間引入了一個傳輸級的密碼安全層,該層可以使用安全套接層 Secure Sockets Layer(SSL),也可以使用其后繼者:傳輸層安全 Transport Layer Security(TLS)。

      HTTPS = HTTP + SSL or TLS

      加入這層之后,收發報文也就不再是使用Socket API,而是調用了安全層提供的安全API。在使用HTTPS時無需過多的修改協議處理邏輯。

      為此,如果我們弄清楚這個SSL/TLS,就理解了HTTPS的精華所在了。

      5.2、SSL/TLS發展歷史

      為了保證安全性,SSL/TLS在不斷的迭代升級版本,引入了更加安全的算法套件。下面是大致的升級過程:

      image-20200905181844188

      在1999年,SSL 3.0升級為TLS 1.0,寫入到RFC 2246標準中。

      不過由于安全問題,TLS 1.1及其以下版本都將作廢,不再維護,目前主要在用的是TLS 1.2和TLS 1.3。

      OpenSSL是開源版本的實現,目前急需在維護的是OpenSSL 1.1.1版本。

      5.3、TLS詳解

      瀏覽器和服務器通信之前,會先協商,選出他們都支持的加密套件,用于實現安全的通信。

      常見的加密套件可以參考 161 Cipher Suites[1]

      我們選一個來看看加密套件的命名格式:

      image-20200905192031686

      如最后一個組合,意味著:

      • ECDHE: 握手時,使用ECDHE算法交換密鑰;
      • ECDSA: 使用ECDSA算法進行簽名;
      • AES128-GCM: 使用AES256對稱加密算法進行通信,密鑰長度128,分組模式GCM;
      • SHA256: 使用SHA256算法進行消息的完整性驗證和產生隨機數。

      5.3.1、為什么需要用到這么多算法?

      以密碼學為基礎的信息安全包含主要的五個方面:機密性,可用性,完整性,認證性,不可否認性。

      為了保證安全,TLS就需要保證這五個特性。簡要說明下這個五個特性:

      • 機密性:保密信息不會透露給非授權的用戶或實體;
      • 可用性:指的是加密服務的高可用;
      • 完整性:信息不回被非法篡改,有對應的篡改檢測機制;
      • 認證性:參與信息交換的兩個主體需要確認對方的身份是否可信,避免信息被不懷好意的人給竊取或者篡改;
      • 不可否認性:指的是用戶在事后無法否認曾經進行的信息交換、簽發;

      每種算法,在TLS中都有其特定的用處,下面先簡單介紹各種算法。

      5.3.2、對稱加密算法

      所謂對稱加密,就是使用同一個密鑰進行加解密。

      最常見的就是AES加密算法。

      但是對稱加密,加解密雙方如何安全的傳遞密鑰是一個問題。如果服務器直接把密鑰傳輸給客戶端,然后才進行加密通信,可能在傳輸密鑰的過程中,密鑰就被竊取了。

      5.3.3、非對稱加密

      非對稱加密通常包含一對密鑰,稱為公鑰(public key)和私鑰(private key)。

      其中一個密鑰加密后的數據,只能讓另一個密鑰進行解密。

      使用公鑰推算出私鑰是非常困難的,但是隨著計算機運算能力提升,目前在程序中使用的非對稱密鑰至少要2048位才能保證安全性

      雖然非對稱加密能夠保證安全性,但是性能卻比對稱加密差很多。

      為此,在TLS中,實際上用的是用到了兩種算法的混合加密。通過非對稱加密算法交換對稱加密算法的密鑰,交換完成之后,在使用對稱加密進行加解密傳輸數據。這樣就保證了會話的機密性

      5.3.4、摘要算法

      摘要算法主要用于保證信息的完整性,相當于信息的指紋信息。常見的散列函數,哈希函數,MD5算法都屬于這類算法,其特點是單向性,無法反推原文

      為了保證安全性,目前TLS推薦使用SHA-2摘要算法,禁止使用MD5和SHA-1。

      有了摘要算法就能保證完整性了嗎?

      假如黑客截取了信息,改動了信息之后,重新生成了摘要,那么,這個時候就判斷不出來消息是被篡改過了。

      image-20200905224436088

      為了避免這類消息發生,我們需要給摘要也通過會話密鑰進行加密,這樣就看不到摘要明文信息了,能更好的保證信息的安全性了。

      image-20200905230547998

      可見,離開了機密性,完整性也就無從說起了。

      5.3.5、數字簽名

      到目前為止,我們還有一個問題沒有解決,那就是:怎么知道我們要連接的網站不是偽造的呢,如果是偽造的,即使他給了我們他的公鑰,也是可以成功進行加解密的,因為他給的公鑰給他自己的私鑰本身就是一對。

      如下圖,客戶端的請求被中間人截獲了,中間人給了客戶端自己的公鑰,最終客戶端把消息發給了中間人,中間人這個時候是可以解密密文拿到原始數據的。然后中間人請求實際的服務器,拿到了實際服務器的公鑰,再把消息轉發給實際的服務器。這樣就竊取了客戶端的信息了。

      中間人攻擊

      image-20200906115538254

      為了避免拿到假的公鑰,所以我們需要一個權威機構幫忙驗證這個公鑰是不是真的。

      通過CA機構生成數字證書

      這個時候我們請來了權威的機構,來幫忙我們生成網站公鑰的數字證書:

      image-20200906152343426

      如上圖,服務器和CA機構分別有一對密鑰,服務器請求CA機構把服務器公鑰生成一個數字證書,生成流程:

      • CA機構通過摘要算法生成公鑰的摘要;
      • CA機構通過自己的CA私鑰以及特定的簽名算法加密摘要,生成簽名;
      • 把簽名、服務器公鑰,以及其他基本信息打包放入數字證書中。

      最后,CA機構把生成的數字證書返回給服務器。

      服務器配置好生成的證書,以后客戶端連接服務器,都先把這個證書返回給客戶端,讓客戶端驗證并獲取服務器的公鑰。

      服務器公鑰驗證流程

      客戶端接收到服務器發送的數字證書和CA機構的公鑰,通過CA機構的公鑰對數字證書上的簽名進行驗證。

      image-20200906181030185

      驗證過程:

      • 使用CA公鑰和聲明的簽名算法對CA中的簽名進行解密,得到服務器公鑰的摘要內容;
      • 拿到證書里面的服務器公鑰,用摘要算法生成摘要內容,與第一步的結果對比,如果一致,則說該證書就是合法的,里面的公鑰是正確的,否則證書就是非法的。

      誰來保證CA的公鑰的正確性?

      服務器驗證的時候,需要拿到數字證書發布機構的CA公鑰,但是怎么證明這個CA公鑰是正確的呢?這個時候就需要有更大的CA幫小的CA的公鑰做認證了,一層一層的背書,最頂層的CA,Root CA,稱為根證書,作為信任鏈的根,是全球皆知的的極大著名CA,這些根證書一般會內置到操作系統中。

      image-20200906182339641

      大家可以到操作系統的證書目錄下,或者瀏覽器,看看證書文件里面都有什么內容。

      思考題:

      1. 即使證書驗證通過了,這樣就能夠保證安全了么,想想還有沒有其他原因導致請求的網站身份不可信的;
      2. 有了CA機構,就沒法進行中間人攻擊了嗎?

      5.3.6、算法總結

      image-20200906182757193

      我們來總結一下上面提到的各種算法的作用:

      • 簽名算法:通過數字證書,和CA公鑰,驗證獲取到的服務器公鑰的可靠性,保證了認證性;
      • 密鑰交換算法 + 對稱加密算法:通過交換的密鑰,進行加密通信,保證了機密性和不可否認性;
      • 摘要算法:保證完整性。

      本文首次發表于: HTTPS:網絡安全攻堅戰 以及公眾號 Java架構雜談,未經許可,不得轉載。

      5.4、HTTPS連接過程

      HTTS連接訪問比HTTP多了一步TLS連接:DNS解析,TCP連接、TLS連接

      最關鍵的就是TLS連接,這里我們重點來分析。

      其中TLS連接認證分為單向認證和雙向認證:

      單向認證 :服務器提供證書,客戶端驗證服務器證書;

      雙向認證 :服務器客戶端分別提供證書給對方,并互相驗證對方的證書。

      不過,大多數運行HTTPS的web服務器都不需要客戶端提供證書,如果服務器需要驗證客戶端的身份,一般是通過用戶名和密碼、手機驗證碼等之類的憑證來完成。對于更高安全級別要求的系統,如大額網銀轉賬等,則會提供雙向認證的場景,來確保對客戶身份提供認證性。

      早期的TLS密鑰交換用的是RSA算法,目前主流都是用ECDHE算法來做密鑰交換的。下面我們分別來介紹下。

      5.4.1、基于TLS1.2的HTTPS連接過程

      5.4.1.1、RSA密鑰交換算法

      這個過程稍微有點復雜,還是先上圖,流程的關鍵部分都加上了注釋,后面詳細解釋。

      image-20200908083032132

      如上圖:

      • 首先是TCP三次握手,握手成功之后,就可以開始通過TCP傳輸數據了;
      • 接下來是TLS握手的流程:
        • Client Hello:客戶端生成一個Client Random隨機數,明文發送給服務器,同時提供自己的 TLS版本號,以及自己支持的加密套件;
        • Server Hello:服務器收到之后,也生成了一個Server Random隨機數,明文發送給客戶端,同時告知自己選擇的TLS版本號,以及選擇的加密套件;
        • Server Certificate:服務器發送自己的證書給到客戶端;
        • Server Hello Done:提示服務器信息發送完畢;
        • 客戶端收到證書之后進行證書的校驗,確保公鑰是合法的;
        • Client Key Exchange:客戶端生成一個PreMaster隨機數,通過服務器的公鑰加密傳輸給服務器;
        • 這個時候客戶端和服務器都有三個參數:Server Random、Client Random、PreMaster,其中PreMaster是無法被不懷好意的人截獲的,通過這三個參數,生成對稱密鑰;
        • 客戶端Change Cipher Spec:客戶端通知服務器后續改用剛剛生成的密鑰進行加密通信;
        • 客戶端Encrypted Handshake Message:客戶端準備用剛剛的參數加密傳輸,驗證加密通信;
        • 服務器Change Cipher Spec:服務器也通知客戶端后續改用剛剛生成的密鑰進行加密通信;
        • 服務器Encrypted Handshake Message:服務器準備用剛剛的參數加密傳輸,驗證加密通信;
        • 在雙方都確認好了之后,最后是驗證的消息。

      這里的核心是:通過非對稱加密交換參數,生成對稱通信加密的密鑰,其中PreMaster是非對稱加密傳輸的,保證了不會泄露通信加密的密鑰。

      下面我們再來看看主流的ECDHE密鑰交換算法的HTTPS連接過程。

      5.4.1.2、ECDHE密鑰交換算法

      我把與基于RSA算法的連接過程的差異步驟都進行高亮顯示了,如下圖:

      image-20200908083058518

      這里我重點說明不一樣的地方:

      • Server Key Exchange:在服務端發送完證書之后,多了這一步,這個是橢圓曲線參數Server Params,為了保證認證性,這里同時生成了Server Params的簽名,一起發給客戶端;
      • Client Key Exchange:這里不再是直接發送客戶端生成PreMaster,而是生成客戶端的橢圓曲線參數Client Params,直接傳送給服務端;接著,客戶端和服務端雙方通過ECDHE算法用Client Params和Server Params算出最終的PreMaster,這個PreMaster是保證不會被截獲的。這樣雙方就有了:Client Random,Server Random,PreMaster參數了,通過這三個參數就可以生成通信密鑰了;
      • 在客戶端發送了Encrypted Handshake Message之后,就立刻發送測試包了,不用等到服務端發送完Encrypted Handshake Message。

      5.4.2、TLS1.3對安全性和性能的提升

      TLS1.3是2018年發布的,這個版本中對安全性和性能上有了大幅度提升。

      5.4.2.1、安全性提升

      這個版本中砍掉了很多不夠安全點加密套件中的算法,只提供了少而精的加密套件。

      密鑰交換算法廢棄了RSA,更好地保證了安全性,不會因為RSA私鑰泄露導致歷史報文被破解的問題出現。

      假設有人故意截獲了會話中所有的加密報文,在RSA算法中,如果私鑰泄露,那么就可以推算出PreMaster和對稱密鑰,那么保存了所有的歷史報文都會被破解。

      5.4.2.2、性能提升

      上圖我們看到,TLS握手經歷了兩個RTT。

      TLS1.3簡化了握手過程,主要就是把原來兩個RTT中的信息,打包成一個發送了,減少傳輸次數,最終只需要1個RTT就完成了信息的交換和握手。

      思考:用了HTTPS肯定會變慢,有什么提升速度的措施呢?


      這篇文章的內容就介紹到這里,能夠閱讀到這里的朋友真的是很有耐心,為你點個贊。

      本文為arthinking基于相關技術資料和官方文檔撰寫而成,確保內容的準確性,如果你發現了有何錯漏之處,煩請高抬貴手幫忙指正,萬分感激。

      如果您覺得讀完本文有所收獲的話,可以關注我的賬號,或者點贊吧,碼字不易,您的支持就是我寫作的最大動力,再次感謝!

      為了把相關系列文章收集起來,方便后續查閱,這里我創建了一個Github倉庫,把發布的文章按照分類收集起來了,感興趣的朋友可以Star跟進:

      https://github.com/arthinking/java-tech-stack

      java-tech-stack-info

      關注我的博客IT宅(itzhai.com)或者公眾號Java架構雜談,及時獲取最新的文章。我將持續更新后端相關技術,涉及JVM、Java基礎、架構設計、網絡編程、數據結構、數據庫、算法、并發編程、分布式系統等相關內容。

      References

      • 謝希仁. 計算機網絡(第6版). 電子工業出版社.
      • TCP/IP詳解 卷1:協議(原書第2版). 機械工業出版社.
      • UNIX網絡編程 卷1:套接字聯網API. 人民郵電出版社
      • HTTP權威指南. 人民郵電出版社
      • HTTP/2基礎教程. 人民郵電出版社
      • 劉超. 趣談網絡協議. 極客時間
      • 羅劍鋒. 透視HTTP協議. 即可時間

      本文同步發表于我的博客IT宅(itzhai.com)和公眾號(Java架構雜談)

      作者:arthinking | 公眾號:Java架構雜談

      博客鏈接:https://www.itzhai.com/articles/https-the-battle-for-network-security.html

      版權聲明: 版權歸作者所有,未經許可不得轉載,侵權必究!聯系作者請加公眾號。


      1. 161 Cipher Suites. Retrieved from https://ciphersuite.info/cs/?software=openssl&singlepage=true ??

      posted @ 2021-02-26 07:52  arthinking-itzhai  閱讀(1579)  評論(6編輯  收藏
      最新chease0ldman老人|无码亚洲人妻下载|大香蕉在线看好吊妞视频这里有精品www|亚洲色情综合网

        <sub id="gqw76"><listing id="gqw76"></listing></sub>
        <sub id="gqw76"><listing id="gqw76"></listing></sub>

      1. <form id="gqw76"><legend id="gqw76"></legend></form>