国产精在线-国产精欧美一区二区三区-国产精视频-国产精品 日韩-一级黄色片在线看-一级黄色片在线播放

HTTPS 是如何保護你的安全的

多年以前,我還在上大學(xué)的時候,曾經(jīng)聽學(xué)長說起他打過的一份工,每個月可以賺不少零花錢。這份工作非常簡單,就是去互聯(lián)網(wǎng)上流行的各種網(wǎng)站、手機上流行的各大 APP 以及各個網(wǎng)站的手機瀏覽器版本(WAP、H5 之類的)執(zhí)行一些基本的操作,包括注冊、登錄、操作具體業(yè)務(wù)等,比如航空類的網(wǎng)站就嘗試查詢航班、購買機票,團購類的網(wǎng)站就嘗試搜索美食、發(fā)布評價……

在操作的同時,通過 Wireshark 這樣的抓包軟件把所有的通信包全部記錄下來并分析其中的 HTTP 數(shù)據(jù),你會發(fā)現(xiàn)賬號、業(yè)務(wù)內(nèi)容等信息絕大部分都以明文形式在互聯(lián)網(wǎng)上流動,即使少部分看起來是亂碼,經(jīng)過簡單的解碼、解密,也可以快速獲取原文。

學(xué)長告訴我這樣的世界太不安全了:想要通過互聯(lián)網(wǎng)完成任何一件事情,你都需要從電腦或手機發(fā)起一系列 HTTP 請求,這些請求通過一層層的路由,最終送到千里之外的某臺服務(wù)器。

在這個過程中,你同宿舍的室友可能在偷看你的聊天,你的學(xué)校也可能以安全為由監(jiān)控著你的行蹤,還有一些不法分子在暗中記錄你的賬號和密碼;在這個過程中,許許多多的釣魚網(wǎng)站通過攔截你的網(wǎng)絡(luò),假冒銀行、政府,獲取你的信任,套取你的信息;在這個過程中,運營商可能為了利益,在你正常瀏覽的網(wǎng)頁中嵌入了生硬的廣告,篡改了原始的頁面內(nèi)容……

直到我們有了 HTTPS —— 它簡直就是這一切的「救世主」。

HTTP 帶來的風(fēng)險

HTTPS,中文名是「超文本傳輸安全協(xié)議」(HyperText Transfer Protocol Secure),它以 HTTP 為基礎(chǔ),為 HTTP 提供額外的加密和認證。這也正是其名字的由來:HTTP + Secure。

如果我們用日常生活中的交流來模擬 HTTP,那么?明文的聊天?可能是這樣的:

致少數(shù)派:我叫李明,我的密碼是 123456;我最近收到了什么新的私信?

答復(fù):李明你好,已確認你的身份。昨天張三給你發(fā)了一條私信,內(nèi)容是「天氣真好」。

問題在于你和少數(shù)派并不是面對面交流的。事實上你跟少數(shù)派說的每一句話,都像一張明信片一樣,郵局拿到你的明信片,中間經(jīng)過一層層的郵政網(wǎng)點轉(zhuǎn)發(fā),最終才派送到少數(shù)派那兒。少數(shù)派給你的答復(fù)也是如此。

這樣至少就帶來以下風(fēng)險:

  1. 明信片嘛,所有郵遞員都可以看到。大家不但知道了你的私信內(nèi)容,大家甚至知道了你的姓名和密碼
  2. 你雖然收到了一個答復(fù),但是你無法確定到底是不是少數(shù)派給出的。萬一哪個郵遞員懶得(或者故意不去)送你的明信片,而自己隨便寫了一條私信回給你呢?
  3. 內(nèi)容可能被篡改。郵遞員完成了派送,也成功取回了少數(shù)派給你的答復(fù)。但是少數(shù)派回復(fù)的私信內(nèi)容明明是「天氣真好」,有個搗蛋的郵遞員把它改成了「天氣真不好」

HTTPS 的互相問候

引入 HTTPS 之后情況就完全不一樣了,雖然仍然使用明信片進行交流,但是這次你和少數(shù)派之間首先有個見面的問候:

致少數(shù)派:

我需要訪問私信;

我懂得使用 TLS_RSA_WITH_AES_256_GCM_SHA384 算法、 TLS_RSA_WITH_AES_128_GCM_SHA256 算法,你選一個;

我生成了一個隨機數(shù),11872

當(dāng)然,實際使用時的信息會再多一些,這里只選取了其中最重要的幾個。它們分別是:

  1. 所需訪問的網(wǎng)站
  2. 我所支持的算法
  3. 我生成的隨機數(shù)

少數(shù)派拿到你的信息之后,會根據(jù)自身情況做出答復(fù):

答復(fù):

我們就用 TLS_RSA_WITH_AES_256_GCM_SHA384 算法吧;

我也生成了一個隨機數(shù),785391;

給你私信網(wǎng)站的證書(一個文件袋)

少數(shù)派給的答復(fù)也比我所舉的例子復(fù)雜得多,這里選取的幾項分別是:

  1. 從你所給的幾種算法中挑了一種,雙方都合適的
  2. 也生成了一個隨機數(shù)
  3. 給了你所需網(wǎng)站的證書

HTTPS 的安全通道尚未建立,但是我們有必要先來看一下這張證書。

證書,一個文件袋

經(jīng)過和少數(shù)派的第一次通信,你擁有了一張證書;或者說是一個文件袋,里面裝滿了各種文件,可供查驗和使用。你可以在任何瀏覽器中看到這張證書。

例如使用 Google Chrome 打開少數(shù)派網(wǎng)站,地址欄的左側(cè)會出現(xiàn)一把小鎖。點擊之后,可以查看證書的詳細情況:

這張證書主要包含以下信息:

  1. 證書頒給了哪個或哪些網(wǎng)站(使用者)
  2. 證書的有效期的起止時間(有效期)
  3. 一個公鑰
  4. 證書是由誰頒發(fā)的(頒發(fā)者)

接下來,你會一一對這些信息進行處理。

第一項很好理解,使用者,就是這張證書對誰有效。你看了一眼,嗯,*.sspai.com,這是一個通配符域名,意思就是對所有?sspai.com?的域名都有效。好的,它確實符合少數(shù)派網(wǎng)站的網(wǎng)址,驗證通過。

第二項,有效期,也很容易。你在自己的電腦上查了一下時間,2021 年 8 月,確實是在有效期區(qū)間內(nèi),好的,驗證通過。

第三項是一個?公鑰,先存下來后面用。

第四項,頒發(fā)者,雖然你知道了這張證書是由一個叫做 RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1 的人頒發(fā)的。但這個人又是誰,他值得信任嗎?

這就要看證書中的最后一項內(nèi)容,證書路徑。在這里,我們可以通過一個樹形圖,清晰地看到我們當(dāng)前這個證書的信任鏈。對于列表中的每一項,都可以通過右下方「查看證書」按鈕,讀取到這一項的證書信息。

也就是說,列表中的每一項其實都是一張完整的證書。在這個例子中:

  • RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1 保證了?*.sspai.com?的證書是可信任的
  • DigiCert 保證了 RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1 的證書是可信任的
  • 瀏覽器,或者操作系統(tǒng),充分信任 DigiCert(瀏覽器或操作系統(tǒng)會維護一個受信任的列表)

因此,隨著一層層的信任關(guān)系你也就信任了?*.sspai.com?這張證書;這種信任帶來的最重要的意義在于——你相信,證書中包含的那個「公鑰」確實是屬于少數(shù)派的,而不是其中任何一個郵差偽造的。

所以,證書帶來的結(jié)果就是:你擁有了一個確信是少數(shù)派的公鑰

HTTPS 的初次加密嘗試

公鑰就像是從證書這個文件袋中捎過來的一個信封,一旦封口,就只有證書擁有者使用私鑰才可以打開;換言之,你只要用這個信封寄送,那么就只有少數(shù)派可以讀到(啊,用于封口的是?一種神奇的膠水,這是由數(shù)學(xué)原理保證的)。

你可以放心地使用從證書中找到的這枚公鑰。如果你決定試一下,便可以生成一個隨機數(shù) 36721,寫在明信片上,然后興致勃勃地把明信片裝進信封,仔細地封好口子。

【這是只有你和少數(shù)派才可以看到的內(nèi)容】

現(xiàn)在,你交給郵局的不再是體無遮攔的明信片,而是一個信封。郵差看不到信件的內(nèi)容,他只知道這封信送往何處;少數(shù)派成功收到了這封信,并使用少數(shù)派的私鑰拆開了信封。最后一個隨機數(shù)成功送達。

整理一下。結(jié)合前面的「問候」過程,現(xiàn)在你和少數(shù)派雙方手上擁有:

  1. 一個雙方都認可的加密算法 TLS_RSA_WITH_AES_256_GCM_SHA384,郵差可以偷看
  2. 一個少數(shù)派生成的隨機數(shù) 785391,郵差可以偷看
  3. 一個你生成的隨機數(shù) 11872,郵差可以偷看
  4. 另一個你生成的隨機數(shù) 36721,只有你和少數(shù)派知道

通過這些信息,你和少數(shù)派會各自使用三個隨機數(shù)和算法,計算出一個稱為「會話密鑰」的密碼。由于隨機數(shù)和算法都已經(jīng)確定,因此你和少數(shù)派計算出的「會話密鑰」必然是一致的;假設(shè)這個計算出來的密碼是 1627638。

你們事實上完成了一件很有意思的事情:在所有聊天內(nèi)容都會被人偷看的情況下,你們成功交換了密碼。這使得后續(xù)的秘密聊天成為可能。交換密鑰的方法也還有很多,這里僅僅展示了其中的一種。

愉快的秘密通信

好了,最后,你們可以使用前面制作的 1627638 這個密碼來進行后面的聊天。

這個密碼用起來就方便多了,只要雙方通過?一個帶密碼鎖的小盒子?來互相通信,那路上的郵差就肯定打不開。

暴力解鎖?密碼復(fù)雜度保證了即使用人類最頂級的計算機,也無法在有生之年把密碼猜出來。(1627638 這只是個例子,實際使用當(dāng)然不可能這么短小)

你把想問的問題(我的私信?)塞進了密碼鎖,并把密碼鎖的密碼設(shè)為 1627638,鎖上之后打亂密碼鎖。

少數(shù)派拿到了這個密碼鎖,通過 1627638 解開密碼鎖。同樣的,少數(shù)派會把你的私信內(nèi)容也用 1627638 鎖上,寄回給你。

最后,你還是用 1627638 解鎖私信內(nèi)容,秘密通信順利完成。

再來回頭看看最開始 HTTP 遇到幾個風(fēng)險,在 HTTPS 中是如何解決的:

  1. 郵差知道了你的私信內(nèi)容、姓名和密碼:在 HTTPS 中,由于通信使用 1627638 這個密碼鎖來加密,所以路上的郵差不可能知道信件的內(nèi)容
  2. 無法確定到底是不是少數(shù)派給出的答復(fù):在 HTTPS 中,證書的信任鏈保證了「公鑰」的可信度,而公鑰和私鑰的匹配認證了少數(shù)派的身份
  3. 搗蛋的郵遞員修改了信件內(nèi)容:在 HTTPS 中,由于使用了密碼鎖,郵差讀不了郵件,也無法寫入信件

所以通過這稍顯復(fù)雜的 HTTPS 通道,我們最終解決了 HTTP 的一些風(fēng)險。

HTTPS 已隨處可見

現(xiàn)在幾乎所有主流的瀏覽器都已經(jīng)用比較強烈的視覺效果區(qū)分了 HTTP 和 HTTPS 網(wǎng)站,例如 Google Chrome,訪問少數(shù)派網(wǎng)站時,地址欄前方的標識是一把寓示著安全的小鎖,點開則提示「連接是安全的」:

而如果訪問一個使用 HTTP 的網(wǎng)站,則會直接顯示「不安全」:

當(dāng)訪問的網(wǎng)站,雖然正常完成了「問候」的過程,但是從服務(wù)器取到的證書存在或多或少的問題時,瀏覽器會阻斷你們之間的通信:

即使通過「高級」按鈕底下的選項堅持訪問,瀏覽器依然會時刻把「不安全」標注為醒目的紅色:

這樣激進的措施曾經(jīng)飽受爭議,但是瀏覽器這樣的強制性的行為卻帶來了非常好的結(jié)果。時至今天,我們已經(jīng)很少見到有哪個網(wǎng)站還只支持 HTTP 訪問,也很少見到證書錯誤的情況。以至于當(dāng)我們說起互聯(lián)網(wǎng)的時候,我們已經(jīng)很難想象,當(dāng)年那樣幾乎完全基于 HTTP 的通信是多么不可靠、不安全。

還有幾個問題值得討論

為什么一定要有「會話密鑰」,直接使用公私鑰對來通信不好嗎?

確實,為了交換一個保險箱密碼我們多花了不少精力。而要取得少數(shù)派的神奇信封,似乎只要向少數(shù)派索取一個證書就可以了。

但這樣做原因很簡單:用保險箱上鎖,只要打亂密碼就可以了,成本低;而神奇信封和用于封口的神奇膠水太貴了。

術(shù)語來講,前者稱為對稱加密,后者稱為非對稱加密。對稱加密更加高效。

為什么有些軟件還是可以讀取 HTTPS 內(nèi)容?

我所知的幾種方法。

第一種,你可以直接通過瀏覽器 F12 的「網(wǎng)絡(luò)」標簽頁來讀取 HTTPS 內(nèi)容。這里,瀏覽器就是通信雙方中的一方(也就是上文中的「你」),自然知道所有的加密要素,所以通過瀏覽器可以讀到明文的數(shù)據(jù)也就不足為奇了;就像你可以知道你發(fā)給少數(shù)派、少數(shù)派發(fā)給你的所有信息一樣自然。

第二種,你信任其中一個郵差,告訴了他密碼鎖的密碼;那郵差就可以讀信給你聽了。

還有一種,是通過安裝私有證書來實現(xiàn)。你信任一個郵差,所以你把郵差的證書加入了自己系統(tǒng)的「受信任列表」;于是:

  1. 你跟郵差之間通信,使用郵差的證書
  2. 郵差收到你的內(nèi)容,轉(zhuǎn)發(fā)給少數(shù)派,使用少數(shù)派的證書
  3. 郵差收到少數(shù)派的內(nèi)容,用少數(shù)派的密碼解密
  4. 郵差把少數(shù)派的答復(fù)轉(zhuǎn)發(fā)給你,用與你之間的密碼加密

所以,只要你保護好自己的「受信任列表」,就不用擔(dān)心 HTTPS 通信被他人偷看,換句話說,如果有網(wǎng)站讓你「添加證書到系統(tǒng)」,為了安全請一定要慎重

自簽名證書安全嗎?

不安全,自簽名證書屬于自欺欺人、掩耳盜鈴、欲蓋彌彰。

有些網(wǎng)站會自己簽發(fā)證書。由于缺少了可靠的證書信任鏈,客戶端無法驗證服務(wù)端的真實身份,因此信件很容易被路上的郵差調(diào)包;如果郵差從最開始的「問候」階段就開始動壞心思,那么整個通信都可以被郵差控制。

當(dāng)使用自簽名證書時,幾乎所有瀏覽器都會給出證書出錯的提示,需要用戶手動確認才可以繼續(xù)訪問。

中間人還可以竊聽到什么信息?

路由器和運營商提供的訪問統(tǒng)計、以安全之名實行的網(wǎng)站攔截,亦或是以大數(shù)據(jù)之名而進行的隱私追蹤,這些在 HTTPS 中依然可以做到嗎?采取了 HTTPS 通信后,作為路上的郵差,還可以偷看到哪些信息呢?

自然,加密信件的全部內(nèi)容都無法獲取。這些內(nèi)容包括:

GET /message/2hzb91qd HTTP/1.1
Host: sspai.com
Connection: keep-alive
Cache-Control: max-age=0
sec-ch-ua: "Chromium";v="92", " Not A;Brand";v="99", "Microsoft Edge";v="92"
sec-ch-ua-mobile: ?0
DNT: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36 Edg/92.0.902.62
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,zh-TW;q=0.5,ja;q=0.4,sl;q=0.3
If-Modified-Since: Wed, 04 Aug 2021 08:54:52 GMT

HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Wed, 04 Aug 2021 08:55:22 GMT
Last-Modified: Wed, 04 Aug 2021 08:54:52 GMT
Access-Control-Allow-Origin: *.sspai.com
Content-Type: text/html
Vary: Accept-Encoding
ETag: W/"610a55dc-1121"
Content-Encoding: gzip

<!DOCTYPE html><html lang=en id=html>
...

 

也就是說,包括主機名、請求體、URL路徑和參數(shù)、返回的頭部和消息體,這些都是加密的。而信件的地址,也就是 IP 地址,必然是會被郵差知道,否則郵差不知道把信送到哪兒去。

唯一的漏網(wǎng)之魚來自于 SNI(Server Name Indication,服務(wù)器名稱指示)。客戶端向服務(wù)端發(fā)起請求的時候,會表明自己想要訪問的網(wǎng)站。例如,前面的例子中,你向少數(shù)派問候時:

我需要訪問私信

而少數(shù)派則回復(fù):

給你私信網(wǎng)站的證書(一個文件袋)

這是因為,同一臺服務(wù)器上,可能部署了多個子網(wǎng)站(例如可能私信、文章區(qū)分了不同的子域名,但是部署在同一個服務(wù)器上),那么就需要客戶端指明所需訪問的網(wǎng)站,服務(wù)器才可以給出合適的證書。

例如,sspai.com?或者?ditu.baidu.com?這樣的域名依然通過「明信片」的形式發(fā)送,郵差們可以隨意查看。但是,?/message/2hzb91qd?這樣表明「查看某條私信」的具體操作,則是安全的。

這也為基于 HTTPS 的網(wǎng)絡(luò)通信過濾提供了方便。前面所說的訪問統(tǒng)計、網(wǎng)站攔截、隱私追蹤,很大一部分都是靠的 SNI 這個參數(shù)。但是就像前述例子中所述,SNI 僅提供域名,而 URL 地址包含在加密的 HTTP 消息中,因此追蹤也相對有限。

事實上,現(xiàn)在也有技術(shù)來保護 SNI 的安全,例如 ESNI 和后來演變成的 ECH 都是非常有效的嘗試。

你可以做些什么

基于前面的討論,我們可以思考如何更安全地在互聯(lián)網(wǎng)上瀏覽。

從一開始就使用 HTTPS

對于支持 HTTPS 的網(wǎng)站,大部分都對 HTTP 進行了跳轉(zhuǎn)。舉例來說,當(dāng)你訪問少數(shù)派網(wǎng)站時,如果直接在瀏覽器中輸入?sspai.com?就敲下回車鍵,那么瀏覽器會自動跳轉(zhuǎn)到?http://sspai.com?而不是 HTTPS 站點。而少數(shù)派網(wǎng)站在收到 HTTP 請求后,會告訴你:我改地址了,請使用 HTTPS 訪問。

致少數(shù)派:我需要訪問首頁,這是我的個人信息

答復(fù):我換地方了,請使用 https://sspai.com/ 重新訪問

于是,你重新發(fā)起了一次聊天,這次,你使用了 HTTPS。

這里有很明顯的問題,當(dāng)你使用 HTTP 訪問時,你已經(jīng)把你需要訪問的內(nèi)容(少數(shù)派首頁)、你的個人信息,都以「明信片」的形式交給了郵差。雖然少數(shù)派提醒了你需要更換地址并拒絕給予任何有實際意義的答復(fù),但是這之前已經(jīng)稍許泄露了信息。

所以最好的做法是,當(dāng)你訪問網(wǎng)站時,直接輸入:?https://sspai.com?而不要偷懶讓瀏覽器自動去跳轉(zhuǎn)。

絕對不要信任不可靠的證書

這些行為包括:

  • 有些銀行網(wǎng)站,會讓你提前安裝「網(wǎng)銀助手」,其中一步就是「把銀行自己的證書安裝到系統(tǒng)中」。這其實并不安全。不過現(xiàn)在這樣做的銀行已經(jīng)越來越少了。
  • 遇到證書過期、域名不匹配、信任鏈存在瑕疵的證書時,瀏覽器會給予全屏提示。此時雖然有小字可以點擊「繼續(xù)訪問」,但是非常不推薦此時繼續(xù)輸入敏感信息。

為自己的網(wǎng)站加上 HTTPS

如果你擁有自己的個人網(wǎng)站或者博客,那么你一定要配置一下 HTTPS 證書。我經(jīng)常使用?Let's Encrypt?提供的免費證書,借助?Certbot?這個一鍵配置工具,簡單幾行命令就可以一勞永逸地配置完成。

Let's Encrypt 的證書有效期只有三個月,但是 Certbot 提供了自動續(xù)期的功能,有效期將近時會自動更新服務(wù)器上所有托管的證書。

本文章來源:少數(shù)派

THE END
主站蜘蛛池模板: 欧美日韩精品一区二区三区高清视频 | 波多野结衣一区在线 | 成人免费xxxxx在线视频 | 操欧美美女 | 中国女人18xnxx视频 | 青青热久久综合网伊人 | 国产17部性孕妇孕交在线 | 在线观看va | 欧美成人中文字幕 | 午夜影院美女 | 日韩一级大片 | 一级特黄性色生活片一区二区 | 欧美在线视 | 91日本在线视频 | 日韩乱码视频 | 国产三级香港在线观看 | 国产dvd毛片在线视频 | 欧美精品1 | 国产精品黄网站免费观看 | 毛片随便看 | 在线91精品国产免费 | 久久国产精品久久 | 精品久久久日韩精品成人 | 中文字幕乱码在线观看 | 久久成人黄色 | 国产精品亚洲精品爽爽 | 国产午夜亚洲精品国产 | 国产福利三区 | 黄色一级毛片网站 | 久久国内视频 | 欧美一级一片 | 国产精品成人观看视频网站 | 亚洲欧美性视频 | 欧美成人网7777视频 | 日韩精品一区二区三区免费观看 | 久久综合中文字幕一区二区 | 国产日本亚洲欧美 | 福利社在线视频 | 午夜毛片免费观看视频 | 国产精品亚洲片在线不卡 | 亚洲一区二区视频 |