有朋友在面試字節(jié)，被問到這個問題：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 開發(fā)者工具查看的信息，瀏覽器顯示信息是已經(jīng)解密后的信息，所以不要誤以為 URL 沒有加密。
如果你用抓包工具，抓包 HTTPS 的數(shù)據(jù)的話，你是什么都看不到的，如下圖，只會顯示“Application Data”，表示這是一個已經(jīng)加密的 HTTP 應用數(shù)據(jù)。
HTTPS 可以看到域名嗎？
再問大家一個問題，HTTPS 可以看到請求的域名嗎？
從上面我們知道，HTTPS 是已經(jīng)把 HTTP Header + HTTP Body 整個加密的，所以我們是無法從加密的 HTTP 數(shù)據(jù)中獲取請求的域名的。
但是我們可以在 TLS 握手過程中看到域名信息。
比如下圖，TLS 第一次握手的 “Client Hello” 消息中，有個 server name 字段，它就是請求的域名地址。
所以，用了 HTTPS 也不能以為偷偷在公司上某 hub 不會被發(fā)現(xiàn)
HTTPS 的應用數(shù)據(jù)是如何保證完整性的？
TLS 的握手協(xié)議我相信大家都很熟悉了，我也寫過很多相關的文章了：
- HTTPS RSA 握手解析
- HTTPS ECDHE 握手解析
然后對于 HTTPS 是怎么加密 HTTP 數(shù)據(jù)的，我沒有提到過。
然后很多讀者以為 HTTP 數(shù)據(jù)就用對稱加密密鑰（TLS 握手過程中協(xié)商出來的對稱加密密鑰）加密后就直接發(fā)送了，然后就疑惑 HTTP 數(shù)據(jù)有沒有通過摘要算法來保證完整性？
事實上，TLS 在實現(xiàn)上分為握手協(xié)議和記錄協(xié)議兩層：
- TLS 握手協(xié)議就是我們說的 TLS 四次握手的過程，負責協(xié)商加密算法和生成對稱密鑰，后續(xù)用此密鑰來保護應用程序數(shù)據(jù)（即 HTTP 數(shù)據(jù)）；
- TLS 記錄協(xié)議負責保護應用程序數(shù)據(jù)并驗證其完整性和來源，所以對 HTTP 數(shù)據(jù)加密是使用記錄協(xié)議；
TLS 記錄協(xié)議主要負責消息（HTTP 數(shù)據(jù)）的壓縮，加密及數(shù)據(jù)的認證，過程如下圖：
具體過程如下：
- 首先，消息被分割成多個較短的片段,然后分別對每個片段進行壓縮。
- 接下來，經(jīng)過壓縮的片段會被加上消息認證碼（MAC 值，這個是通過哈希算法生成的），這是為了保證完整性，并進行數(shù)據(jù)的認證。通過附加消息認證碼的 MAC 值，可以識別出篡改。與此同時，為了防止重放攻擊，在計算消息認證碼時，還加上了片段的編碼。
- 再接下來，經(jīng)過壓縮的片段再加上消息認證碼會一起通過對稱密碼進行加密。
- 最后，上述經(jīng)過加密的數(shù)據(jù)再加上由數(shù)據(jù)類型、版本號、壓縮后的長度組成的報頭就是最終的加密報文數(shù)據(jù)。
記錄協(xié)議完成后，最終的加密報文數(shù)據(jù)將傳遞到傳輸控制協(xié)議 (TCP) 層進行傳輸。
原文鏈接https://mp.weixin.qq.com/s/SPmx7tEhQYtHH_HDw7zXFw
