有朋友在面試字節(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)的文章了：

• HTTPS RSA 握手解析
• HTTPS ECDHE 握手解析

然后對(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ù)類(lèi)型、版本號(hào)、壓縮后的長(zhǎng)度組成的報(bào)頭就是最終的加密報(bào)文數(shù)據(jù)。

記錄協(xié)議完成后，最終的加密報(bào)文數(shù)據(jù)將傳遞到傳輸控制協(xié)議 (TCP) 層進(jìn)行傳輸。

原文鏈接https://mp.weixin.qq.com/s/SPmx7tEhQYtHH_HDw7zXFw