自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

看完這篇 HTTPS,和面試官扯皮就沒問題了

網(wǎng)絡(luò) 網(wǎng)絡(luò)管理
本篇文章我們主要講述了 HTTPS 為什么會出現(xiàn) ,HTTPS 解決了 HTTP 的什么問題,HTTPS 和 HTTP 的關(guān)系是什么,TLS 和 SSL 是什么,TLS 和 SSL 解決了什么問題?如何實現(xiàn)一個真正安全的數(shù)據(jù)傳輸?

下面我們來一起學習一下 HTTPS ,首先問你一個問題,為什么有了 HTTP 之后,還需要有 HTTPS ?我突然有個想法,為什么我們面試的時候需要回答標準答案呢?為什么我們不說出我們自己的想法和見解,卻要記住一些所謂的標準回答呢?技術(shù)還有正確與否嗎?

[[318621]]

一、HTTPS 為什么會出現(xiàn)

一個新技術(shù)的出現(xiàn)必定是為了解決某種問題的,那么 HTTPS 解決了 HTTP 的什么問題呢?

1. HTTPS 解決了什么問題

一個簡單的回答可能會是 HTTP 它不安全。由于 HTTP 天生明文傳輸?shù)奶匦?,?HTTP 的傳輸過程中,任何人都有可能從中截獲、修改或者偽造請求發(fā)送,所以可以認為 HTTP 是不安全的;在 HTTP 的傳輸過程中不會驗證通信方的身份,因此 HTTP 信息交換的雙方可能會遭到偽裝,也就是沒有用戶驗證;在 HTTP 的傳輸過程中,接收方和發(fā)送方并不會驗證報文的完整性,綜上,為了解決上述問題,HTTPS 應(yīng)用而生。

2. 什么是 HTTPS

你還記得 HTTP 是怎么定義的嗎?HTTP 是一種 超文本傳輸協(xié)議(Hypertext Transfer Protocol) 協(xié)議,它 是一個在計算機世界里專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范,那么我們看一下 HTTPS 是如何定義的

HTTPS 的全稱是 Hypertext Transfer Protocol Secure,它用來在計算機網(wǎng)絡(luò)上的兩個端系統(tǒng)之間進行安全的交換信息(secure communication),它相當于在 HTTP 的基礎(chǔ)上加了一個 Secure 安全的詞眼,那么我們可以給出一個 HTTPS 的定義:HTTPS 是一個在計算機世界里專門在兩點之間安全的傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范。HTTPS 是 HTTP 協(xié)議的一種擴展,它本身并不保傳輸?shù)淖C安全性,那么誰來保證安全性呢?在 HTTPS 中,使用傳輸層安全性(TLS)或安全套接字層(SSL)對通信協(xié)議進行加密。也就是 HTTP + SSL(TLS) = HTTPS。

[[318622]]

3. HTTPS 做了什么

HTTPS 協(xié)議提供了三個關(guān)鍵的指標

  • 加密(Encryption), HTTPS 通過對數(shù)據(jù)加密來使其免受竊聽者對數(shù)據(jù)的監(jiān)聽,這就意味著當用戶在瀏覽網(wǎng)站時,沒有人能夠監(jiān)聽他和網(wǎng)站之間的信息交換,或者跟蹤用戶的活動,訪問記錄等,從而竊取用戶信息。
  • 數(shù)據(jù)一致性(Data integrity),數(shù)據(jù)在傳輸?shù)倪^程中不會被竊聽者所修改,用戶發(fā)送的數(shù)據(jù)會完整的傳輸?shù)椒?wù)端,保證用戶發(fā)的是什么,服務(wù)器接收的就是什么。
  • 身份認證(Authentication),是指確認對方的真實身份,也就是證明你是你(可以比作人臉識別),它可以防止中間人攻擊并建立用戶信任。

有了上面三個關(guān)鍵指標的保證,用戶就可以和服務(wù)器進行安全的交換信息了。那么,既然你說了 HTTPS 的種種好處,那么我怎么知道網(wǎng)站是用 HTTPS 的還是 HTTP 的呢?給你兩幅圖應(yīng)該就可以解釋了。

HTTPS

HTTPS 協(xié)議其實非常簡單,RFC 文檔很小,只有短短的 7 頁,里面規(guī)定了新的協(xié)議名,默認端口號443,至于其他的應(yīng)答模式、報文結(jié)構(gòu)、請求方法、URI、頭字段、連接管理等等都完全沿用 HTTP,沒有任何新的東西。

也就是說,除了協(xié)議名稱和默認端口號外(HTTP 默認端口 80),HTTPS 協(xié)議在語法、語義上和 HTTP 一樣,HTTP 有的,HTTPS 也照單全收。那么,HTTPS 如何做到 HTTP 所不能做到的安全性呢?關(guān)鍵在于這個 S 也就是 SSL/TLS 。

二、什么是 SSL/TLS

1. 認識 SSL/TLS

TLS(Transport Layer Security) 是 SSL(Secure Socket Layer) 的后續(xù)版本,它們是用于在互聯(lián)網(wǎng)兩臺計算機之間用于身份驗證和加密的一種協(xié)議。

注意:在互聯(lián)網(wǎng)中,很多名稱都可以進行互換。

我們都知道一些在線業(yè)務(wù)(比如在線支付)最重要的一個步驟是創(chuàng)建一個值得信賴的交易環(huán)境,能夠讓客戶安心的進行交易,SSL/TLS 就保證了這一點,SSL/TLS 通過將稱為 X.509證書的數(shù)字文檔將網(wǎng)站和公司的實體信息綁定到加密密鑰來進行工作。每一個密鑰對(key pairs) 都有一個 私有密鑰(private key) 和 公有密鑰(public key),私有密鑰是獨有的,一般位于服務(wù)器上,用于解密由公共密鑰加密過的信息;公有密鑰是公有的,與服務(wù)器進行交互的每個人都可以持有公有密鑰,用公鑰加密的信息只能由私有密鑰來解密。

什么是 X.509:X.509 是公開密鑰證書的標準格式,這個文檔將加密密鑰與(個人或組織)進行安全的關(guān)聯(lián)。

X.509 主要應(yīng)用如下:

  • SSL/TLS 和 HTTPS 用于經(jīng)過身份驗證和加密的 Web 瀏覽
  • 通過 S/MIME 協(xié)議簽名和加密的電子郵件
  • 代碼簽名:它指的是使用數(shù)字證書對軟件應(yīng)用程序進行簽名以安全分發(fā)和安裝的過程。

通過使用由知名公共證書頒發(fā)機構(gòu)(例如SSL.com)頒發(fā)的證書對軟件進行數(shù)字簽名,開發(fā)人員可以向最終用戶保證他們希望安裝的軟件是由已知且受信任的開發(fā)人員發(fā)布;并且簽名后未被篡改或損害。

  • 還可用于文檔簽名
  • 還可用于客戶端認證
  • 政府簽發(fā)的電子身份證(詳見 https://www.ssl.com/article/pki-and-digital-certificates-for-government/)

我們后面還會討論。

2. HTTPS 的內(nèi)核是 HTTP

HTTPS 并不是一項新的應(yīng)用層協(xié)議,只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。通常情況下,HTTP 會先直接和 TCP 進行通信。在使用 SSL 的 HTTPS 后,則會先演變?yōu)楹?SSL 進行通信,然后再由 SSL 和 TCP 進行通信。也就是說,HTTPS 就是身披了一層 SSL 的 HTTP。(我都喜歡把騷粉留在最后。。。)

SSL 是一個獨立的協(xié)議,不只有 HTTP 可以使用,其他應(yīng)用層協(xié)議也可以使用,比如 SMTP(電子郵件協(xié)議)、Telnet(遠程登錄協(xié)議) 等都可以使用。

三、探究 HTTPS

我說,你起這么牛逼的名字干嘛,還想吹牛批?你 HTTPS 不就抱上了 TLS/SSL 的大腿么,咋這么牛批哄哄的,還想探究 HTTPS,瞎胡鬧,趕緊改成 TLS 是我主,贊美我主。

SSL 即安全套接字層,它在 OSI 七層網(wǎng)絡(luò)模型中處于第五層,SSL 在 1999 年被 IETF(互聯(lián)網(wǎng)工程組)更名為 TLS ,即傳輸安全層,直到現(xiàn)在,TLS 一共出現(xiàn)過三個版本,1.1、1.2 和 1.3 ,目前最廣泛使用的是 1.2,所以接下來的探討都是基于 TLS 1.2 的版本上的。

TLS 用于兩個通信應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。TLS 由記錄協(xié)議、握手協(xié)議、警告協(xié)議、變更密碼規(guī)范協(xié)議、擴展協(xié)議等幾個子協(xié)議組成,綜合使用了對稱加密、非對稱加密、身份認證等許多密碼學前沿技術(shù)(如果你覺得一項技術(shù)很簡單,那你只是沒有學到位,任何技術(shù)都是有美感的,牛逼的人只是欣賞,并不是貶低)。

說了這么半天,我們還沒有看到 TLS 的命名規(guī)范呢,下面舉一個 TLS 例子來看一下 TLS 的結(jié)構(gòu)

(可以參考 https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml)。

  1. ECDHE-ECDSA-AES256-GCM-SHA384 

這是啥意思呢?我剛開始看也有點懵啊,但其實是有套路的,因為 TLS 的密碼套件比較規(guī)范,基本格式就是 密鑰交換算法 - 簽名算法 - 對稱加密算法 - 摘要算法 組成的一個密碼串,有時候還有分組模式,我們先來看一下剛剛是什么意思

使用 ECDHE 進行密鑰交換,使用 ECDSA 進行簽名和認證,然后使用 AES 作為對稱加密算法,密鑰的長度是 256 位,使用 GCM 作為分組模式,最后使用 SHA384 作為摘要算法。

TLS 在根本上使用對稱加密和 非對稱加密 兩種形式。

1. 對稱加密

在了解對稱加密前,我們先來了解一下密碼學的東西,在密碼學中,有幾個概念:明文、密文、加密、解密:

  • 明文(Plaintext),一般認為明文是有意義的字符或者比特集,或者是通過某種公開編碼就能獲得的消息。明文通常用 m 或 p 表示
  • 密文(Ciphertext),對明文進行某種加密后就變成了密文
  • 加密(Encrypt),把原始的信息(明文)轉(zhuǎn)換為密文的信息變換過程
  • 解密(Decrypt),把已經(jīng)加密的信息恢復(fù)成明文的過程。

對稱加密(Symmetrical Encryption)顧名思義就是指加密和解密時使用的密鑰都是同樣的密鑰。只要保證了密鑰的安全性,那么整個通信過程也就是具有了機密性。

TLS 里面有比較多的加密算法可供使用,比如 DES、3DES、AES、ChaCha20、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK 等。目前最常用的是 AES-128, AES-192、AES-256 和 ChaCha20。

DES 的全稱是 Data Encryption Standard(數(shù)據(jù)加密標準) ,它是用于數(shù)字數(shù)據(jù)加密的對稱密鑰算法。盡管其 56 位的短密鑰長度使它對于現(xiàn)代應(yīng)用程序來說太不安全了,但它在加密技術(shù)的發(fā)展中具有很大的影響力。

3DES 是從原始數(shù)據(jù)加密標準(DES)衍生過來的加密算法,它在 90 年代后變得很重要,但是后面由于更加高級的算法出現(xiàn),3DES 變得不再重要。

AES-128, AES-192 和 AES-256 都是屬于 AES ,AES 的全稱是Advanced Encryption Standard(高級加密標準),它是 DES 算法的替代者,安全強度很高,性能也很好,是應(yīng)用最廣泛的對稱加密算法。

ChaCha20 是 Google 設(shè)計的另一種加密算法,密鑰長度固定為 256 位,純軟件運行性能要超過 AES,曾經(jīng)在移動客戶端上比較流行,但 ARMv8 之后也加入了 AES 硬件優(yōu)化,所以現(xiàn)在不再具有明顯的優(yōu)勢,但仍然算得上是一個不錯算法。

(其他可自行搜索)

2. 加密分組

對稱加密算法還有一個分組模式 的概念,對于 GCM 分組模式,只有和 AES,CAMELLIA 和 ARIA 搭配使用,而 AES 顯然是最受歡迎和部署最廣泛的選擇,它可以讓算法用固定長度的密鑰加密任意長度的明文。

最早有 ECB、CBC、CFB、OFB 等幾種分組模式,但都陸續(xù)被發(fā)現(xiàn)有安全漏洞,所以現(xiàn)在基本都不怎么用了。最新的分組模式被稱為 AEAD(Authenticated Encryption with Associated Data),在加密的同時增加了認證的功能,常用的是 GCM、CCM 和 Poly1305。

比如 ECDHE_ECDSA_AES128_GCM_SHA256 ,表示的是具有 128 位密鑰, AES256 將表示 256 位密鑰。GCM 表示具有 128 位塊的分組密碼的現(xiàn)代認證的關(guān)聯(lián)數(shù)據(jù)加密(AEAD)操作模式。

我們上面談到了對稱加密,對稱加密的加密方和解密方都使用同一個密鑰,也就是說,加密方必須對原始數(shù)據(jù)進行加密,然后再把密鑰交給解密方進行解密,然后才能解密數(shù)據(jù),這就會造成什么問題?這就好比《小兵張嘎》去送信(信已經(jīng)被加密過),但是嘎子還拿著解密的密碼,那嘎子要是在途中被鬼子發(fā)現(xiàn)了,那這信可就是被完全的暴露了。所以,對稱加密存在風險。

3. 非對稱加密

非對稱加密(Asymmetrical Encryption) 也被稱為公鑰加密,相對于對稱加密來說,非對稱加密是一種新的改良加密方式。密鑰通過網(wǎng)絡(luò)傳輸交換,它能夠確保及時密鑰被攔截,也不會暴露數(shù)據(jù)信息。非對稱加密中有兩個密鑰,一個是公鑰,一個是私鑰,公鑰進行加密,私鑰進行解密。公開密鑰可供任何人使用,私鑰只有你自己能夠知道。

HTTPS

使用公鑰加密的文本只能使用私鑰解密,同時,使用私鑰加密的文本也可以使用公鑰解密。公鑰不需要具有安全性,因為公鑰需要在網(wǎng)絡(luò)間進行傳輸,非對稱加密可以解決密鑰交換的問題。網(wǎng)站保管私鑰,在網(wǎng)上任意分發(fā)公鑰,你想要登錄網(wǎng)站只要用公鑰加密就行了,密文只能由私鑰持有者才能解密。而黑客因為沒有私鑰,所以就無法破解密文。

非對稱加密算法的設(shè)計要比對稱算法難得多(我們不會探討具體的加密方式),常見的比如 DH、DSA、RSA、ECC 等。

其中 RSA 加密算法是最重要的、最出名的一個了。例如

DHE_RSA_CAMELLIA128_GCM_SHA256。它的安全性基于 整數(shù)分解,使用兩個超大素數(shù)的乘積作為生成密鑰的材料,想要從公鑰推算出私鑰是非常困難的。

ECC(Elliptic Curve Cryptography)也是非對稱加密算法的一種,它基于橢圓曲線離散對數(shù)的數(shù)學難題,使用特定的曲線方程和基點生成公鑰和私鑰, ECDHE 用于密鑰交換,ECDSA 用于數(shù)字簽名。

TLS 是使用對稱加密和非對稱加密 的混合加密方式來實現(xiàn)機密性。

4. 混合加密

RSA 的運算速度非常慢,而 AES 的加密速度比較快,而 TLS 正是使用了這種混合加密方式。在通信剛開始的時候使用非對稱算法,比如 RSA、ECDHE ,首先解決密鑰交換的問題。然后用隨機數(shù)產(chǎn)生對稱算法使用的會話密鑰(session key),再用公鑰加密。對方拿到密文后用私鑰解密,取出會話密鑰。這樣,雙方就實現(xiàn)了對稱密鑰的安全交換。

HTTPS

現(xiàn)在我們使用混合加密的方式實現(xiàn)了機密性,是不是就能夠安全的傳輸數(shù)據(jù)了呢?還不夠,在機密性的基礎(chǔ)上還要加上完整性、身份認證的特性,才能實現(xiàn)真正的安全。而實現(xiàn)完整性的主要手段是 摘要算法(Digest Algorithm)

5. 摘要算法

如何實現(xiàn)完整性呢?在 TLS 中,實現(xiàn)完整性的手段主要是 摘要算法(Digest Algorithm)。摘要算法你不清楚的話,MD5 你應(yīng)該清楚,MD5 的全稱是 Message Digest Algorithm 5,它是屬于密碼哈希算法(cryptographic hash algorithm)的一種,MD5 可用于從任意長度的字符串創(chuàng)建 128 位字符串值。盡管 MD5 存在不安全因素,但是仍然沿用至今。MD5 最常用于驗證文件的完整性。但是,它還用于其他安全協(xié)議和應(yīng)用程序中,例如 SSH、SSL 和 IPSec。一些應(yīng)用程序通過向明文加鹽值或多次應(yīng)用哈希函數(shù)來增強 MD5 算法。

什么是加鹽?在密碼學中,鹽就是一項隨機數(shù)據(jù),用作哈希數(shù)據(jù),密碼或密碼的單向函數(shù)的附加輸入。鹽用于保護存儲中的密碼。例如:

什么是單向?就是在說這種算法沒有密鑰可以進行解密,只能進行單向加密,加密后的數(shù)據(jù)無法解密,不能逆推出原文。

我們再回到摘要算法的討論上來,其實你可以把摘要算法理解成一種特殊的壓縮算法,它能夠把任意長度的數(shù)據(jù)壓縮成一種固定長度的字符串,這就好像是給數(shù)據(jù)加了一把鎖。

HTTPS

除了常用的 MD5 是加密算法外,SHA-1(Secure Hash Algorithm 1) 也是一種常用的加密算法,不過 SHA-1 也是不安全的加密算法,在 TLS 里面被禁止使用。目前 TLS 推薦使用的是 SHA-1 的后繼者:SHA-2。

SHA-2 的全稱是Secure Hash Algorithm 2 ,它在 2001 年被推出,它在 SHA-1 的基礎(chǔ)上做了重大的修改,SHA-2 系列包含六個哈希函數(shù),其摘要(哈希值)分別為 224、256、384 或 512 位:SHA-224, SHA-256, SHA-384, SHA-512。分別能夠生成 28 字節(jié)、32 字節(jié)、48 字節(jié)、64 字節(jié)的摘要。

有了 SHA-2 的保護,就能夠?qū)崿F(xiàn)數(shù)據(jù)的完整性,哪怕你在文件中改變一個標點符號,增加一個空格,生成的文件摘要也會完全不同,不過 SHA-2 是基于明文的加密方式,還是不夠安全,那應(yīng)該用什么呢?

安全性更高的加密方式是使用 HMAC,在理解什么是 HMAC 前,你需要先知道一下什么是 MAC。

MAC 的全稱是message authentication code,它通過 MAC 算法從消息和密鑰生成,MAC 值允許驗證者(也擁有秘密密鑰)檢測到消息內(nèi)容的任何更改,從而保護了消息的數(shù)據(jù)完整性。

HMAC 是 MAC 更進一步的拓展,它是使用 MAC 值 + Hash 值的組合方式,HMAC 的計算中可以使用任何加密哈希函數(shù),例如 SHA-256 等。

HTTPS

現(xiàn)在我們又解決了完整性的問題,那么就只剩下一個問題了,那就是認證,認證怎么做的呢?我們在向服務(wù)器發(fā)送數(shù)據(jù)的過程中,黑客(攻擊者)有可能偽裝成任何一方來竊取信息。它可以偽裝成你,來向服務(wù)器發(fā)送信息,也可以偽裝稱為服務(wù)器,接受你發(fā)送的信息。那么怎么解決這個問題呢?

6. 認證

如何確定你自己的唯一性呢?我們在上面的敘述過程中出現(xiàn)過公鑰加密,私鑰解密的這個概念。提到的私鑰只有你一個人所有,能夠辨別唯一性,所以我們可以把順序調(diào)換一下,變成私鑰加密,公鑰解密。使用私鑰再加上摘要算法,就能夠?qū)崿F(xiàn)數(shù)字簽名,從而實現(xiàn)認證。

HTTPS

到現(xiàn)在,綜合使用對稱加密、非對稱加密和摘要算法,我們已經(jīng)實現(xiàn)了加密、數(shù)據(jù)認證、認證,那么是不是就安全了呢?非也,這里還存在一個數(shù)字簽名的認證問題。因為私鑰是是自己的,公鑰是誰都可以發(fā)布,所以必須發(fā)布經(jīng)過認證的公鑰,才能解決公鑰的信任問題。

所以引入了 CA,CA 的全稱是 Certificate Authority,證書認證機構(gòu),你必須讓 CA 頒布具有認證過的公鑰,才能解決公鑰的信任問題。

全世界具有認證的 CA 就幾家,分別頒布了 DV、OV、EV 三種,區(qū)別在于可信程度。DV 是最低的,只是域名級別的可信,EV 是最高的,經(jīng)過了法律和審計的嚴格核查,可以證明網(wǎng)站擁有者的身份(在瀏覽器地址欄會顯示出公司的名字,例如 Apple、GitHub 的網(wǎng)站)。不同的信任等級的機構(gòu)一起形成了層級關(guān)系。

HTTPS

通常情況下,數(shù)字證書的申請人將生成由私鑰和公鑰以及證書簽名請求(CSR)組成的密鑰對。CSR是一個編碼的文本文件,其中包含公鑰和其他將包含在證書中的信息(例如域名,組織,電子郵件地址等)。密鑰對和 CSR生成通常在將要安裝證書的服務(wù)器上完成,并且 CSR 中包含的信息類型取決于證書的驗證級別。與公鑰不同,申請人的私鑰是安全的,永遠不要向 CA(或其他任何人)展示。

生成 CSR 后,申請人將其發(fā)送給 CA,CA 會驗證其包含的信息是否正確,如果正確,則使用頒發(fā)的私鑰對證書進行數(shù)字簽名,然后將其發(fā)送給申請人。

HTTPS

總結(jié)

本篇文章我們主要講述了 HTTPS 為什么會出現(xiàn) ,HTTPS 解決了 HTTP 的什么問題,HTTPS 和 HTTP 的關(guān)系是什么,TLS 和 SSL 是什么,TLS 和 SSL 解決了什么問題?如何實現(xiàn)一個真正安全的數(shù)據(jù)傳輸?

 

責任編輯:趙寧寧 來源: Java建設(shè)者
相關(guān)推薦

2020-04-07 01:04:18

SessionCookieToken

2020-04-15 12:24:55

Exception Error Java

2020-02-03 17:22:34

垃圾回收原理種類

2020-11-02 08:12:52

finalJava開發(fā)

2020-01-15 08:06:28

HTTP超文本傳輸協(xié)議網(wǎng)絡(luò)協(xié)議

2020-05-15 11:14:58

操作系統(tǒng)面試官運行

2019-05-31 15:30:00

人工智能機器人互聯(lián)網(wǎng)

2018-04-23 11:00:44

PythonRedisNoSQL

2021-05-08 07:53:33

面試線程池系統(tǒng)

2018-04-27 14:46:07

面試簡歷程序員

2021-02-19 10:02:57

HTTPSJava安全

2020-04-16 08:22:11

HTTPS加解密協(xié)議

2019-10-10 11:20:22

MySQL索引數(shù)據(jù)庫

2021-04-30 00:00:50

Semaphore信號量面試官

2020-04-03 14:05:10

面試RedisJava

2021-05-12 08:20:53

開發(fā)

2020-10-09 09:49:18

HTTPS網(wǎng)絡(luò) HTTP

2019-04-15 14:40:46

消息隊列Java編程

2019-04-26 14:12:19

MySQL數(shù)據(jù)庫隔離級別

2020-07-03 15:30:14

rm文件Linux
點贊
收藏

51CTO技術(shù)棧公眾號