歡迎您光臨深圳塔燈網(wǎng)絡(luò)科技有限公司！
余先生：13699882642
余先生：13699882642
8年
專注網(wǎng)站建設(shè)行業(yè)優(yōu)質(zhì)服務(wù)商
余先生：13699882642
為您解碼網(wǎng)站建設(shè)的點(diǎn)點(diǎn)滴滴
發(fā)表日期：2018-01 文章編輯：小燈 瀏覽次數(shù)：73141
1、HTTP 協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）：是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議 。
2、HTTPS 協(xié)議（HyperText Transfer Protocol over Secure Socket Layer）：可以理解為HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL，用于安全的 HTTP 數(shù)據(jù)傳輸。
如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS
SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發(fā)，SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。
TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL，它最初的幾個(gè)版本（SSL 1.0、SSL 2.0、SSL 3.0）由網(wǎng)景公司開發(fā)，1999年從 3.1 開始被 IETF 標(biāo)準(zhǔn)化并改名，發(fā)展至今已經(jīng)有 TLS 1.0、TLS 1.1、TLS 1.2 三個(gè)版本。SSL3.0和TLS1.0由于存在安全漏洞，已經(jīng)很少被使用到。TLS 1.3 改動(dòng)會(huì)比較大，目前還在草案階段，目前使用最廣泛的是TLS 1.1、TLS 1.2。
據(jù)記載，公元前400年，古希臘人就發(fā)明了置換密碼；在第二次世界大戰(zhàn)期間，德國(guó)軍方啟用了“恩尼格瑪”密碼機(jī)，所以密碼學(xué)在社會(huì)發(fā)展中有著廣泛的用途。
1、對(duì)稱加密
有流式、分組兩種，加密和解密都是使用的同一個(gè)密鑰。
例如：DES、AES-GCM、ChaCha20-Poly1305等
2、非對(duì)稱加密
加密使用的密鑰和解密使用的密鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和算法都是公開的，私鑰是保密的。非對(duì)稱加密算法性能較低，但是安全性超強(qiáng)，由于其加密特性，非對(duì)稱加密算法能加密的數(shù)據(jù)長(zhǎng)度也是有限的。
例如：RSA、DSA、ECDSA、 DH、ECDHE
3、哈希算法
將任意長(zhǎng)度的信息轉(zhuǎn)換為較短的固定長(zhǎng)度的值，通常其長(zhǎng)度要比信息小得多，且算法不可逆。
例如：MD5、SHA-1、SHA-2、SHA-256 等
4、數(shù)字簽名
簽名就是在信息的后面再加上一段內(nèi)容（信息經(jīng)過(guò)hash后的值），可以證明信息沒(méi)有被修改過(guò)。hash值一般都會(huì)加密后（也就是簽名）再和信息一起發(fā)送，以保證這個(gè)hash值不被修改。
一、HTTP 訪問(wèn)過(guò)程
抓包如下：
如上圖所示，HTTP請(qǐng)求過(guò)程中，客戶端與服務(wù)器之間沒(méi)有任何身份確認(rèn)的過(guò)程，數(shù)據(jù)全部明文傳輸，“裸奔”在互聯(lián)網(wǎng)上，所以很容易遭到黑客的攻擊，如下：
可以看到，客戶端發(fā)出的請(qǐng)求很容易被黑客截獲，如果此時(shí)黑客冒充服務(wù)器，則其可返回任意信息給客戶端，而不被客戶端察覺(jué)，所以我們經(jīng)常會(huì)聽到一詞“劫持”，現(xiàn)象如下：
下面兩圖中，瀏覽器中填入的是相同的URL，左邊是正確響應(yīng)，而右邊則是被劫持后的響應(yīng)
所以 HTTP 傳輸面臨的風(fēng)險(xiǎn)有：
（1） 竊聽風(fēng)險(xiǎn)：黑客可以獲知通信內(nèi)容。
（2） 篡改風(fēng)險(xiǎn)：黑客可以修改通信內(nèi)容。
（3） 冒充風(fēng)險(xiǎn)：黑客可以冒充他人身份參與通信。
二、HTTP 向 HTTPS 演化的過(guò)程
第一步：為了防止上述現(xiàn)象的發(fā)生，人們想到一個(gè)辦法：對(duì)傳輸?shù)男畔⒓用埽词购诳徒孬@，也無(wú)法破解）
如上圖所示，此種方式屬于對(duì)稱加密，雙方擁有相同的密鑰，信息得到安全傳輸，但此種方式的缺點(diǎn)是：
（1）不同的客戶端、服務(wù)器數(shù)量龐大，所以雙方都需要維護(hù)大量的密鑰，維護(hù)成本很高
（2）因每個(gè)客戶端、服務(wù)器的安全級(jí)別不同，密鑰極易泄露
第二步：既然使用對(duì)稱加密時(shí)，密鑰維護(hù)這么繁瑣，那我們就用非對(duì)稱加密試試
如上圖所示，客戶端用公鑰對(duì)請(qǐng)求內(nèi)容加密，服務(wù)器使用私鑰對(duì)內(nèi)容解密，反之亦然，但上述過(guò)程也存在缺點(diǎn)：
（1）公鑰是公開的（也就是黑客也會(huì)有公鑰），所以第 ④ 步私鑰加密的信息，如果被黑客截獲，其可以使用公鑰進(jìn)行解密，獲取其中的內(nèi)容
第三步：非對(duì)稱加密既然也有缺陷，那我們就將對(duì)稱加密，非對(duì)稱加密兩者結(jié)合起來(lái)，取其精華、去其糟粕，發(fā)揮兩者的各自的優(yōu)勢(shì)
如上圖所示
（1）第 ③ 步時(shí)，客戶端說(shuō)：（咱們后續(xù)回話采用對(duì)稱加密吧，這是對(duì)稱加密的算法和對(duì)稱密鑰）這段話用公鑰進(jìn)行加密，然后傳給服務(wù)器
（2）服務(wù)器收到信息后，用私鑰解密，提取出對(duì)稱加密算法和對(duì)稱密鑰后，服務(wù)器說(shuō)：（好的）對(duì)稱密鑰加密
（3）后續(xù)兩者之間信息的傳輸就可以使用對(duì)稱加密的方式了
遇到的問(wèn)題：
（1）客戶端如何獲得公鑰
（2）如何確認(rèn)服務(wù)器是真實(shí)的而不是黑客
第四步：獲取公鑰與確認(rèn)服務(wù)器身份
1、獲取公鑰
（1）提供一個(gè)下載公鑰的地址，回話前讓客戶端去下載。（缺點(diǎn)：下載地址有可能是假的；客戶端每次在回話前都先去下載公鑰也很麻煩）
（2）回話開始時(shí)，服務(wù)器把公鑰發(fā)給客戶端（缺點(diǎn)：黑客冒充服務(wù)器，發(fā)送給客戶端假的公鑰）
2、那有木有一種方式既可以安全的獲取公鑰，又能防止黑客冒充呢？ 那就需要用到終極武器了：SSL 證書（申購(gòu)）
如上圖所示，在第 ② 步時(shí)服務(wù)器發(fā)送了一個(gè)SSL證書給客戶端，SSL 證書中包含的具體內(nèi)容有：
（1）證書的發(fā)布機(jī)構(gòu)CA
（2）證書的有效期
（3）公鑰
（4）證書所有者
（5）簽名
………
3、客戶端在接受到服務(wù)端發(fā)來(lái)的SSL證書時(shí)，會(huì)對(duì)證書的真?zhèn)芜M(jìn)行校驗(yàn)，以瀏覽器為例說(shuō)明如下：
（1）首先瀏覽器讀取證書中的證書所有者、有效期等信息進(jìn)行一一校驗(yàn)
（2）瀏覽器開始查找操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)CA，與服務(wù)器發(fā)來(lái)的證書中的頒發(fā)者CA比對(duì)，用于校驗(yàn)證書是否為合法機(jī)構(gòu)頒發(fā)
（3）如果找不到，瀏覽器就會(huì)報(bào)錯(cuò)，說(shuō)明服務(wù)器發(fā)來(lái)的證書是不可信任的。
（4）如果找到，那么瀏覽器就會(huì)從操作系統(tǒng)中取出 頒發(fā)者CA 的公鑰，然后對(duì)服務(wù)器發(fā)來(lái)的證書里面的簽名進(jìn)行解密
（5）瀏覽器使用相同的hash算法計(jì)算出服務(wù)器發(fā)來(lái)的證書的hash值，將這個(gè)計(jì)算的hash值與證書中簽名做對(duì)比
（6）對(duì)比結(jié)果一致，則證明服務(wù)器發(fā)來(lái)的證書合法，沒(méi)有被冒充
（7）此時(shí)瀏覽器就可以讀取證書中的公鑰，用于后續(xù)加密了
4、所以通過(guò)發(fā)送SSL證書的形式，既解決了公鑰獲取問(wèn)題，又解決了黑客冒充問(wèn)題，一箭雙雕，HTTPS加密過(guò)程也就此形成
所以相比HTTP，HTTPS 傳輸更加安全
（1） 所有信息都是加密傳播，黑客無(wú)法竊聽。
（2） 具有校驗(yàn)機(jī)制，一旦被篡改，通信雙方會(huì)立刻發(fā)現(xiàn)。
（3） 配備身份證書，防止身份被冒充。
客戶端發(fā)出握手請(qǐng)求(Client Hello)，包含以下信息：
服務(wù)器回復(fù)(Server Hello)，包含以下信息：
客戶端回應(yīng)，包含以下步驟：
服務(wù)器回應(yīng)，服務(wù)器通過(guò)上面的三個(gè)隨機(jī)數(shù)(random_1,random_2,PreMaster Secret)，計(jì)算出本次會(huì)話的『會(huì)話密鑰(session secret)』，然后向客戶端發(fā)送下面信息
至此，服務(wù)器和客戶端的握手階段全部結(jié)束，接下來(lái)，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過(guò)用『會(huì)話密鑰(session secret)』對(duì)內(nèi)容做對(duì)稱加密。
PreMaster Secret 說(shuō)明
PreMaster secret是在客戶端使用RSA或者Diffie-Hellman等加密算法生成的。它將用來(lái)跟服務(wù)端和客戶端在Hello階段產(chǎn)生的隨機(jī)數(shù)結(jié)合在一起生成Master secret。在客戶端使用服務(wù)單的公鑰對(duì)PreMaster secret進(jìn)行加密之后傳送給服務(wù)端，服務(wù)端將使用私鑰進(jìn)行解密得到PreMaster secret。也就是說(shuō)服務(wù)端和客戶端都有一份相同的PreMaster secret和隨機(jī)數(shù)。
關(guān)于Master Secret的計(jì)算
至于為什么一定要用三個(gè)隨機(jī)數(shù)，來(lái)生成Master Secret，由于SSL協(xié)議中證書是靜態(tài)的，因此需要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。SSL協(xié)議不信任每個(gè)主機(jī)都能生成完全隨機(jī)的隨機(jī)數(shù)，所以這里需要服務(wù)器和客戶端共生成3個(gè)隨機(jī)數(shù)，每增加一個(gè)自由度，隨機(jī)性就會(huì)相應(yīng)增加。
同時(shí)需要注意前兩個(gè)隨機(jī)數(shù)都是明文傳輸?shù)模`聽者是可以輕易獲取到的，只有最后一個(gè) PreMaster Secret 是加密傳輸?shù)模挥袚碛蟹?wù)器私鑰才能解密，一旦 PreMaster Secret 泄露，那么本次通信就就完全可被破解了。
HTTPS 的通信過(guò)程中只在握手階段使用了非對(duì)稱加密，后面的通信過(guò)程均使用的對(duì)稱加密。盡管非對(duì)稱加密相比對(duì)稱加密更加安全，但也存在兩個(gè)明顯缺點(diǎn)：
所以公鑰加密目前只能用來(lái)作密鑰交換或者內(nèi)容簽名，不適合用來(lái)做應(yīng)用層傳輸內(nèi)容的加解密。
非對(duì)稱密鑰交換算法是整個(gè) HTTPS 得以安全的基石，充分理解非對(duì)稱密鑰交換算法是理解 HTTPS 協(xié)議和功能的關(guān)鍵。
針對(duì) HTTPS 的攻擊最主要的就是 SSL 劫持攻擊，其分為兩種：
這種方式就是攻擊者充當(dāng)中間人和服務(wù)器通信，然后把相應(yīng)的通信內(nèi)容通過(guò) HTTP 協(xié)議發(fā)送給客戶端，由于 HTTP 協(xié)議是未加密的，于是就可以截獲用戶的訪問(wèn)數(shù)據(jù)。
這種攻擊方式比較簡(jiǎn)單，通過(guò)代理，可以很容易的把 HTTPS 變成 HTTP，這個(gè)一方面需要用戶留意網(wǎng)站是否有從 HTTPS 跳轉(zhuǎn)到 HTTP 的行為，另一方面服務(wù)器也可以通過(guò)配置將所有HTTP的請(qǐng)求強(qiáng)制轉(zhuǎn)移到HTTPS上。
這種方式攻擊者為了獲得 HTTPS 的明文傳輸內(nèi)容，需要充當(dāng)中間人，替換服務(wù)器發(fā)給用戶的包含公鑰的證書。攻擊者既和用戶之間建立了 HTTPS 鏈接，又和服務(wù)器建立了 HTTPS 鏈接。
在上面握手建立的過(guò)程中，由于用戶的公鑰是攻擊者生成的，所以攻擊者可以輕易獲得握手中的數(shù)據(jù)。也就可以獲取到和用戶通信過(guò)程中的對(duì)稱加密的密鑰，攻擊者可以通過(guò)密鑰獲取用戶發(fā)送的數(shù)據(jù)，同時(shí)在使用和服務(wù)器通信的密鑰加密后再發(fā)送給服務(wù)器。
這種攻擊方式也有一個(gè)明顯的問(wèn)題就是攻擊者生成的證書幾乎是不可能被用戶信任的，在這種情況下，用戶瀏覽器通常會(huì)提示該網(wǎng)站的證書不可信，是否繼續(xù)訪問(wèn)，這已經(jīng)對(duì)用戶進(jìn)行了一個(gè)明顯的警告了。
另外我們也可以通過(guò)這種對(duì)基于 HTTPS 的通信進(jìn)行抓包分析。Mac 平臺(tái)著名的抓包工具 Charles 就是基于這種方式，首先要求你信任一個(gè)它的證書，然后自己充當(dāng)中間人對(duì)你與某個(gè)服務(wù)器的 HTTPS 通信進(jìn)行抓包分析。
Http請(qǐng)求是明文通訊的，所有信息可以通過(guò)中間人，代理一覽無(wú)遺， 所以我們需要一種加密后的通訊機(jī)制， 探索過(guò)程中有下面幾種方案：
客戶端發(fā)出握手請(qǐng)求(Client Hello)：
服務(wù)器回復(fù)(Server Hello)：
客戶端回應(yīng)：
服務(wù)器端回應(yīng)
HTTPS詳解
HTTPS干貨
日期：2018-04 瀏覽次數(shù)：6761
日期：2017-02 瀏覽次數(shù)：3435
日期：2017-09 瀏覽次數(shù)：3656
日期：2017-12 瀏覽次數(shù)：3526
日期：2018-12 瀏覽次數(shù)：4816
日期：2016-12 瀏覽次數(shù)：4582
日期：2017-07 瀏覽次數(shù)：13642
日期：2017-12 瀏覽次數(shù)：3505
日期：2018-06 瀏覽次數(shù)：4265
日期：2018-05 瀏覽次數(shù)：4444
日期：2017-12 瀏覽次數(shù)：3556
日期：2017-06 瀏覽次數(shù)：3979
日期：2018-01 瀏覽次數(shù)：3941
日期：2016-12 瀏覽次數(shù)：3908
日期：2018-08 瀏覽次數(shù)：4423
日期：2017-12 瀏覽次數(shù)：3706
日期：2016-09 瀏覽次數(shù)：6404
日期：2018-07 瀏覽次數(shù)：3206
日期：2016-12 瀏覽次數(shù)：3230
日期：2018-10 瀏覽次數(shù)：3378
日期：2018-10 瀏覽次數(shù)：3479
日期：2018-09 瀏覽次數(shù)：3577
日期：2018-02 瀏覽次數(shù)：3595
日期：2015-05 瀏覽次數(shù)：3519
日期：2018-09 瀏覽次數(shù)：3305
日期：2018-06 瀏覽次數(shù)：3433
日期：2017-02 瀏覽次數(shù)：3869
日期：2018-02 瀏覽次數(shù)：4334
日期：2018-02 瀏覽次數(shù)：4173
日期：2016-12 瀏覽次數(shù)：3571
Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.
企業(yè)建站知識(shí)
推廣知識(shí)
小程序
微信營(yíng)銷
APP開發(fā)
