字節一面:HTTPS 會加密URL 嗎?

2022.08.17
字節一面:HTTPS 會加密URL 嗎?

因為URL 的信息都是保存在HTTP Header 中的,而HTTPS 是會對HTTP Header + HTTP Body 整個加密的,所以URL 自然是會被加密的。

大家好,我是小林,昨晚有位讀者又給我送素材來了。

他在面試字節,被問到這個問題:HTTPS 會加密URL 嗎?

圖片

圖片

答案是,會加密的。

因為URL 的信息都是保存在HTTP Header 中的,而HTTPS 是會對HTTP Header + HTTP Body 整個加密的,所以URL 自然是會被加密的。

下圖是HTTP/1.1 的請求頭部,可以看到是包含URL 信息的。

圖片

對應的實際的HTTP/1.1 的請求頭部:

圖片

HTTP/1.1 請求的第一行包含請求方法和路徑。HTTP/2 用一系列偽頭部(pseudo-header)替換了請求行,這五個偽頭部很容易識別,因為它們在名稱的開頭用了一個冒號來表示。

比如請求方法和路徑偽頭字段如下:

  • ":method" 偽頭字段包含了HTTP 方法;
  • ":path" 偽頭字段包含目標URL 的路徑和查詢部分;

如下圖:

圖片

上圖是我瀏覽器F12 開發者工具查看的信息,瀏覽器顯示信息是已經解密後的信息,所以不要誤以為URL 沒有加密。

如果你用抓包工具,抓包HTTPS 的數據的話,你是什麼都看不到的,如下圖,只會顯示“Application Data”,表示這是一個已經加密的HTTP 應用數據。

圖片

HTTPS 可以看到域名嗎?

再問大家一個問題,HTTPS 可以看到請求的域名嗎?

從上面我們知道,HTTPS 是已經把 HTTP Header + HTTP Body 整個加密的,所以我們是無法從加密的HTTP 數據中獲取請求的域名的。

但是我們可以在TLS 握手過程中看到域名信息。

比如下圖,TLS 第一次握手的“Client Hello” 消息中,有個server name 字段,它就是請求的域名地址。

圖片

所以,用了HTTPS 也不能以為偷偷在公司上某hub 不會被發現。

HTTPS 的應用數據是如何保證完整性的?

TLS 的握手協議我相信大家都很熟悉了,我也寫過相關的文章了:

然後對於HTTPS 是怎麼加密HTTP 數據的,我沒有提到過。

然後很多讀者以為HTTP 數據就用對稱加密密鑰(TLS 握手過程中協商出來的對稱加密密鑰)加密後就直接發送了,然後就疑惑HTTP 數據有沒有通過摘要算法來保證完整性?

事實上,TLS 在實現上分為握手協議和記錄協議兩層:

  • TLS 握手協議就是我們說的TLS 四次握手的過程,負責協商加密算法和生成對稱密鑰,後續用此密鑰來保護應用程序數據(即HTTP 數據);
  • TLS 記錄協議負責保護應用程序數據並驗證其完整性和來源,所以對HTTP 數據加密是使用記錄協議;

TLS 記錄協議主要負責消息(HTTP 數據)的壓縮,加密及數據的認證,過程如下圖:

圖片

具體過程如下:

  • 首先,消息被分割成多個較短的片段,然後分別對每個片段進行壓縮。
  • 接下來,經過壓縮的片段會被加上消息認證碼(MAC 值,這個是通過哈希算法生成的),這是為了保證完整性,並進行數據的認證。通過附加消息認證碼的MAC 值,可以識別出篡改。與此同時,為了防止重放攻擊,在計算消息認證碼時,還加上了片段的編碼。
  • 再接下來,經過壓縮的片段再加上消息認證碼會一起通過對稱密碼進行加密。
  • 最後,上述經過加密的數據再加上由數據類型、版本號、壓縮後的長度組成的報頭就是最終的加密報文數據。

記錄協議完成後,最終的加密報文數據將傳遞到傳輸控制協議(TCP) 層進行傳輸。