在线不卡日本ⅴ一区v二区_精品一区二区中文字幕_天堂v在线视频_亚洲五月天婷婷中文网站

  • <menu id="lky3g"></menu>
  • <style id="lky3g"></style>
    <pre id="lky3g"><tt id="lky3g"></tt></pre>

    字節(jié)一面:HTTPS 會(huì)加密 URL 嗎?

    字節(jié)一面:HTTPS 會(huì)加密 URL 嗎?

    有朋友在面試字節(jié),被問到這個(gè)問題: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的開頭用了一個(gè)冒號(hào)來表示。

    比如請(qǐng)求方法和路徑偽頭字段如下:

    • “:method” 偽頭字段包含了 HTTP 方法;
    • “:path” 偽頭字段包含目標(biāo) URL 的路徑和查詢部分;

    如下圖:

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

    如果你用抓包工具,抓包 HTTPS 的數(shù)據(jù)的話,你是什么都看不到的,如下圖,只會(huì)顯示“Application Data”,表示這是一個(gè)已經(jīng)加密的 HTTP 應(yīng)用數(shù)據(jù)。

    HTTPS 可以看到域名嗎?

    再問大家一個(gè)問題,HTTPS 可以看到請(qǐng)求的域名嗎?

    從上面我們知道,HTTPS 是已經(jīng)把 HTTP Header + HTTP Body 整個(gè)加密的,所以我們是無法從加密的 HTTP 數(shù)據(jù)中獲取請(qǐng)求的域名的。

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

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

    所以,用了 HTTPS 也不能以為偷偷在公司上某 hub 不會(huì)被發(fā)現(xiàn)

    HTTPS 的應(yīng)用數(shù)據(jù)是如何保證完整性的?

    TLS 的握手協(xié)議我相信大家都很熟悉了,我也寫過很多相關(guān)的文章了:

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

    然后對(duì)于 HTTPS 是怎么加密 HTTP 數(shù)據(jù)的,我沒有提到過。

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

    事實(shí)上,TLS 在實(shí)現(xiàn)上分為握手協(xié)議和記錄協(xié)議兩層:

    • TLS 握手協(xié)議就是我們說的 TLS 四次握手的過程,負(fù)責(zé)協(xié)商加密算法和生成對(duì)稱密鑰,后續(xù)用此密鑰來保護(hù)應(yīng)用程序數(shù)據(jù)(即 HTTP 數(shù)據(jù));
    • TLS 記錄協(xié)議負(fù)責(zé)保護(hù)應(yīng)用程序數(shù)據(jù)并驗(yàn)證其完整性和來源,所以對(duì) HTTP 數(shù)據(jù)加密是使用記錄協(xié)議;

    TLS 記錄協(xié)議主要負(fù)責(zé)消息(HTTP 數(shù)據(jù))的壓縮,加密及數(shù)據(jù)的認(rèn)證,過程如下圖:

    具體過程如下:

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

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

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

    鄭重聲明:本文內(nèi)容及圖片均整理自互聯(lián)網(wǎng),不代表本站立場(chǎng),版權(quán)歸原作者所有,如有侵權(quán)請(qǐng)聯(lián)系管理員(admin#wlmqw.com)刪除。
    用戶投稿
    上一篇 2022年8月14日 14:35
    下一篇 2022年8月14日 14:35

    相關(guān)推薦

    聯(lián)系我們

    聯(lián)系郵箱:admin#wlmqw.com
    工作時(shí)間:周一至周五,10:30-18:30,節(jié)假日休息