HTTPS誕生原因(三)

本片文章基於三點介紹

  • 1、HTTP的缺點
  • 2、HTTPS = HTTP + 加密 + 認證 + 完整性保護
  • 3、身份認證的方法
    • 1、BASIC認證
    • 2、DIGEST認證
    • 3、SSL客戶端認證
    • 4、表單認證

1、HTTP的缺點

HTTP的不足主要有三個方面

  • 1、通訊使用明文,內容會被竊聽
  • 2、不驗證通訊方的身份,因此有可能遭遇僞裝
  • 3、無法證明報文的完整行,所以可能被篡改

1.1、通訊使用明文,內容會被竊聽

由於HTTP本身是不具備加密的功能的,所以也無法做到對通訊整體進行加密,即HTTP報文是使用明文方式發送的

按照TCP/IP協議族的工作機制,通訊內容在所有的通訊線路上都有可能遭到窺視。

所謂的互聯網使用連通到全世界的網絡組成的,所以通訊過程不是私有的,是完全公開的,即使我們對報文內容進行加密處理,也只能讓別人無法簡單的破解報文信息,但是外人還是能夠截取加密的信息

竊聽相同段上的通訊並不是難事,網上有很多的抓包工具,像sniffer,packet Capture,Wireshark等等

1.2、不驗證通訊方的身份,因此有可能遭遇僞裝

HTTP協議中的請求和響應不會對通訊進行確認的,也就是任何人都可以發出請求。

84ECC05F-7427-4F4F-9247-D82F27ACA845.png

HTTP協議的實現本身非常簡單,無論是誰發過來的請求都會返回響應,不會確認通訊方,因此存在很多的隱患。

  • 1、無法確認請求發送至目標的web服務器是否是按真實意圖返回響應的那臺服務器
  • 2、無法確定響應返回到的客戶端是否是真實的客戶端
  • 3、無法確定通訊對方是否具備訪問權限
  • 4、無法確定請求來自何方,出自誰
  • 5、即使是無意義的請求也會照單全收,無法阻止海量的請求下的Dos攻擊

1.3、無法證明報文的完整行,所以可能被篡改

由於HTTP協議無法證明通訊報文的完整性,因此,在請求或響應發出之後直到對方接受之前這段時間內,即使請求或者響應內容遭到篡改也沒有辦法獲取

AE81B212-33C6-435D-B0AA-B8396A902FDD.png

像這樣請求或者響應在傳輸途中,遭到攻擊者攔截並篡改內容的攻擊稱爲爲中間人攻擊

2、HTTPS = HTTP + 加密 + 認證 + 完整性保護

爲了應對HTTP上面的不足,HTTPS應運而生。

HTTP加上加密處理和認證以及完整性保護後即使HTTPS。

HTTPS通訊歷程

HTTPS並非是應用層的一種新的協議,只是HTTP通訊接口部分用了SSL和TLS協議代替而已。通常HTTP直接和TCP通訊,當使用SSL時,則變成了HTTP先與SSL通訊,再有SSL和TCP通訊HTTPS其實就是添加了SSL協議的外殼的HTTP

SSL是獨立於HTTP的協議,是採用的一種非非對稱式加密的處理方式,所以不光是HTTP協議,其他運行在應用層的SMTP和Telnet等協議均可以配合SSL協議使用,可以說SSL是當今世界上應用最爲廣泛的網絡安全技術

2.1、加密

常用的加密方式主要有

  • 1、對稱式加密:對稱式加密可以叫做共享密鑰加密,或者堆成密鑰加密,是加密解密同用一個密鑰的方式
  • 2、非對稱式加密:非對稱式加密也叫做公開密鑰加密,使用一對非對稱的密鑰,一把公鑰,一把私鑰

以對稱式加密的方式加密時,必須要將密鑰發送給對方。可是究竟怎樣才能安全的轉交呢?在互聯網上轉發密鑰的時候,如果通訊被監聽,那麼密鑰就有可能落入到攻擊者的手中,同時也就失去了加密的意義。

密鑰發送問題

非對稱式加密能夠很好的解決這一個問題,使用非對稱式加密的時候,發送密文的一方使用對方的公開密鑰進行加密處理,對方收到加密信息後,使用私鑰解密。但是這個方式也存在一個非常大的問題,就是要想要根據密文和公開密鑰恢復到信息原文式異常困難的,因爲解密過程就是對離散對數進行求值的,這是非常消耗性能的

因此,爲了照顧安全性和性能問題,HTTPS採用了混合加密機制在交換密鑰環節使用公開加密方式,之後的建立通訊交換報文階段使用對稱加密方式

混合加密機制

2.2、 認證

遺憾的是公開密鑰加密還有一個問題,就是無法證明公開密鑰本身就是貨真價實的公開密鑰。比如,我們怎麼證明收到的公開密鑰就是原來預想的那臺服務器發出的密鑰,而不是公開密鑰在傳輸的過程中真正的公開密鑰已經被攻擊者替換掉了。

爲了解決這個問題,可以使用數字證書認證機構和其他相關機關頒佈的公開密鑰證書。數字正式認證機構處於客戶端與服務器雙方都可信賴的第三方機構的立場。

數字證書頒佈以及使用流程

  • 1、服務器的運營人員向數字認證機構提出公開密鑰的申請
  • 2、數字人數認證機構在判明提出申請者的身份以後,會對已申請的公開密鑰做數字簽名,然後分配這個已簽名的公開密鑰,並將公開密鑰放入公鑰證書後綁定在一起
  • 3、服務器會將這個由數字證書認證機構頒發的公鑰證書發送給客戶端,進行公開密鑰加密方式通訊。
  • 4、接到證書的客戶端可以使用數字證書認證機構的公開密鑰,對那張證書上的數字簽名進行驗證,一旦驗證通過,客戶端便可明確兩件事,一是認證服務器的公開密鑰的是真實有效的數字認證機構,二是服務器公開密鑰是指的信賴的
數字證書認證

爲什麼不一直使用HTTPS

  • 1、HTTPS在使用SSL的時候,他的處理速度會變慢,HTTPS比HTTP要慢2到100倍。
  • 2、使用數字證書的時候需要購買

SSL的慢分爲兩種

  • 1、通信忙
  • 2、消耗大量的CPU資源,導致處理速度變慢
SSL

因此,如果是非敏感信息則使用HTTP通信,只有包含了個人信息等敏感數據時,才利用HTTPS加密通信

HTTP認證方式

HTTP認證方式

  • 1、BASIC認證(基本認證)
  • 2、DIGEST認證(摘要認證)
  • 3、SSL客戶端認證
  • 4、表單認證

BASIC認證(基本認證)

BASIC認證是從HTTP/1.0定義的一種認證方式,但是BASIC認證使用上不夠靈活,且安全等級較低,因此不經常使用。

BASIC認證步驟

BASIC認證步驟

  • 1、當請求的資源需要BASIC認證的時,服務器會隨狀態碼401返回帶WWW-Authenicate首部字段的響應。該字段內包含認證的方式(BASIC)以及Request-URL安全與字符串
  • 2、接收到狀態碼401的客戶端爲了通過BASIC認證,需要將用戶ID和密碼發給服務器
  • 3、接收到包含首部字段Authorization請求的服務器,會對認證的信息的正確性進行驗證,驗證通過,返回200

DIGEST認證(摘要認證)

DIGEST認證(摘要認證)即諮詢響應式,一開始一方會先發送認證要求給另一方,接着使用從另一方那接收到的諮詢碼計算生成響應碼,最後響應碼返回給對方進行認證

DIGEST認證(摘要認證

SSL客戶端認證

步驟

  • 1、接收到需要認證資源的請求,服務器會放數字證書報文,要求客戶端提供客戶端證書
  • 2、用戶選擇將發送的客戶端證書後,客戶端會把客戶端證書信息以Client Certificate報文方式發送給服務器
  • 3、服務器驗證客戶端證書通過後方可領取證書內客戶端的公開密鑰,然後進行HTTPS加密通信

表單認證

HTTP協議標準中提供的BASIC認證和DIGEST認證幾乎不怎麼使用,SSL客戶端認證雖然具有較高的安全等級,但是因爲導入和費用問題,普及不怎麼廣泛。因此出現了表單認證。

表單認證

表單認證的基礎思想就是用戶登錄,然後根據用戶的ID和密碼生成token

文章參考自《圖解HTTP》

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章