久久国产精品一区二区三区四区,久色婷婷小香蕉久久,国产日韩欧美在线播放不卡,另类av一区二区

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

他在面試字節，被問到這個問題：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 RSA 握手解析????HTTPS ECDHE 握手解析??

然后對于 HTTPS 是怎么加密 HTTP 數據的，我沒有提到過。

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

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

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

TLS 記錄協議主要負責消息（HTTP 數據）的壓縮，加密及數據的認證，過程如下圖：

具體過程如下：

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

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

關鍵詞： 加密密鑰 應用程序 請求方法 這個問題 數據加密