字節(jié)一面：HTTPS 會(huì)加密 URL 嗎？
大家好，我是小林，昨晚有位讀者又給我送素材來(lái)了。
他在面試字節(jié)，被問(wèn)到這個(gè)問(wèn)題：HTTPS 會(huì)加密 URL 嗎？
?
答案是，會(huì)加密的。
因?yàn)?URL 的信息都是保存在 HTTP Header 中的，而 HTTPS 是會(huì)對(duì) HTTP Header + HTTP Body 整個(gè)加密的，所以 URL 自然是會(huì)被加密的。
下圖是 HTTP/1.1 的請(qǐng)求頭部，可以看到是包含 URL 信息的。
對(duì)應(yīng)的實(shí)際的 HTTP/1.1 的請(qǐng)求頭部：
HTTP/1.1 請(qǐng)求的第一行包含請(qǐng)求方法和路徑。HTTP/2 用一系列偽頭部（pseudo-header）替換了請(qǐng)求行，這五個(gè)偽頭部很容易識(shí)別，因?yàn)樗鼈冊(cè)诿Q的開(kāi)頭用了一個(gè)冒號(hào)來(lái)表示。
比如請(qǐng)求方法和路徑偽頭字段如下：
- ":method" 偽頭字段包含了 HTTP 方法；
- ":path" 偽頭字段包含目標(biāo) URL 的路徑和查詢部分；
如下圖：
上圖是我瀏覽器 F12 開(kāi)發(fā)者工具查看的信息，瀏覽器顯示信息是已經(jīng)解密后的信息，所以不要誤以為 URL 沒(méi)有加密。
如果你用抓包工具，抓包 HTTPS 的數(shù)據(jù)的話，你是什么都看不到的，如下圖，只會(huì)顯示“Application Data”，表示這是一個(gè)已經(jīng)加密的 HTTP 應(yīng)用數(shù)據(jù)。
HTTPS 可以看到域名嗎？
再問(wèn)大家一個(gè)問(wèn)題，HTTPS 可以看到請(qǐng)求的域名嗎？
從上面我們知道，HTTPS 是已經(jīng)把 HTTP Header + HTTP Body 整個(gè)加密的，所以我們是無(wú)法從加密的 HTTP 數(shù)據(jù)中獲取請(qǐng)求的域名的。
但是我們可以在 TLS 握手過(guò)程中看到域名信息。
比如下圖，TLS 第一次握手的 “Client Hello” 消息中，有個(gè) server name 字段，它就是請(qǐng)求的域名地址。
所以，用了 HTTPS 也不能以為偷偷在公司上某 hub 不會(huì)被發(fā)現(xiàn)。
HTTPS 的應(yīng)用數(shù)據(jù)是如何保證完整性的？
TLS 的握手協(xié)議我相信大家都很熟悉了，我也寫(xiě)過(guò)相關(guān)的文章了：
然后對(duì)于 HTTPS 是怎么加密 HTTP 數(shù)據(jù)的，我沒(méi)有提到過(guò)。
然后很多讀者以為 HTTP 數(shù)據(jù)就用對(duì)稱加密密鑰（TLS 握手過(guò)程中協(xié)商出來(lái)的對(duì)稱加密密鑰）加密后就直接發(fā)送了，然后就疑惑 HTTP 數(shù)據(jù)有沒(méi)有通過(guò)摘要算法來(lái)保證完整性？
事實(shí)上，TLS 在實(shí)現(xiàn)上分為握手協(xié)議和記錄協(xié)議兩層：
- TLS 握手協(xié)議就是我們說(shuō)的 TLS 四次握手的過(guò)程，負(fù)責(zé)協(xié)商加密算法和生成對(duì)稱密鑰，后續(xù)用此密鑰來(lái)保護(hù)應(yīng)用程序數(shù)據(jù)（即 HTTP 數(shù)據(jù)）；
- TLS 記錄協(xié)議負(fù)責(zé)保護(hù)應(yīng)用程序數(shù)據(jù)并驗(yàn)證其完整性和來(lái)源，所以對(duì) HTTP 數(shù)據(jù)加密是使用記錄協(xié)議；
TLS 記錄協(xié)議主要負(fù)責(zé)消息（HTTP 數(shù)據(jù)）的壓縮，加密及數(shù)據(jù)的認(rèn)證，過(guò)程如下圖：
具體過(guò)程如下：
- 首先，消息被分割成多個(gè)較短的片段,然后分別對(duì)每個(gè)片段進(jìn)行壓縮。
- 接下來(lái)，經(jīng)過(guò)壓縮的片段會(huì)被加上消息認(rèn)證碼（MAC 值，這個(gè)是通過(guò)哈希算法生成的），這是為了保證完整性，并進(jìn)行數(shù)據(jù)的認(rèn)證。通過(guò)附加消息認(rèn)證碼的 MAC 值，可以識(shí)別出篡改。與此同時(shí)，為了防止重放攻擊，在計(jì)算消息認(rèn)證碼時(shí)，還加上了片段的編碼。
- 再接下來(lái)，經(jīng)過(guò)壓縮的片段再加上消息認(rèn)證碼會(huì)一起通過(guò)對(duì)稱密碼進(jìn)行加密。
- 最后，上述經(jīng)過(guò)加密的數(shù)據(jù)再加上由數(shù)據(jù)類型、版本號(hào)、壓縮后的長(zhǎng)度組成的報(bào)頭就是最終的加密報(bào)文數(shù)據(jù)。
記錄協(xié)議完成后，最終的加密報(bào)文數(shù)據(jù)將傳遞到傳輸控制協(xié)議 (TCP) 層進(jìn)行傳輸。
