丨第一章網(wǎng)絡(luò)協(xié)議和web接口6講02為穿上盔甲https

在一開始的時(shí)候，HTTP的設(shè)計(jì)者并沒有把專門的加密安全傳輸放進(jìn)協(xié)議設(shè)計(jì)里面。因此單獨(dú)使用HTTP進(jìn)行明文的數(shù)據(jù)傳輸，一定存在著許多的安全問題。比方說，現(xiàn)在有一份數(shù)據(jù)需要使用HTTP協(xié)議從客戶端A發(fā)送到服務(wù)端B，而第C嘗試來做點(diǎn)壞事，于是就Interception：。傳輸?shù)南⒖梢员恢虚g人C截獲，并數(shù)據(jù)Spoofing：。A和B都可能被C冒名頂替，因此消息傳輸變成了C發(fā)送到B，或者A發(fā)送到C。Falsification：篡改。CBRepudiation：CABA發(fā)送了，但之后A否認(rèn)這件事發(fā)生過；或者B其實(shí)收到了消息，但是否認(rèn)他收到過。的安全協(xié)議直接拿過來套用，最好它位于呈現(xiàn)層（PresentationLayer），因此正好加塞在HTTP所在的應(yīng)用層（ApplicationLayer）下面，這樣這個(gè)過程對(duì)于HTTP本身透明，也不影響原本HTTP以下的協(xié)議（例如TCP）。SSL/TLS，它使得上面四大問題中，和傳輸本身密切相關(guān)的前三大問題都可以得到解決（第四個(gè)問題還需要引入數(shù)字簽名來解決）。于是，HTTP搖身一變成了HTTP+SSL/TLS=這里涉及到的兩個(gè)安全協(xié)議，SSL和TLSSSL指的是SecureSocketLayer，而TLS指的是TransportLayerSecurity，事實(shí)上，一開始只有SSL，但是在3.0版本之后，SSL被標(biāo)準(zhǔn)化并通過RFC2246以SSL為基礎(chǔ)建立了TLS的第一個(gè)版本，因此可以簡(jiǎn)單地認(rèn)為SSL和TLS是具備父子衍生關(guān)系的同一類安全TLS介紹了最基本的概念，我們?cè)賮砜纯碒TTPS是怎樣，讓客戶端和服務(wù)端相互信任的，TLS連接又是怎樣建立起來的。還記得上一講的選修課堂嗎？我們學(xué)了怎樣抓包。今天我們就能讓所學(xué)派上用場(chǎng)！自己動(dòng)手，我們抓TLS連接握手的報(bào)文來分析。命令行執(zhí)行抓包命令，指明要抓http 他HTTPS地址），注意HTTPS的默認(rèn)端口是443（-i指定的interface可能因?yàn)椴煌牟僮飨到y(tǒng)有所區(qū)別，在我的Mac上是en0）：1sudotcpdump-ien0-v andport443'-w再新建一個(gè)命令行窗口，使用curl命令來主頁curlCTRL+Ctcpdump:listeningonen0,link-typeEN10MB(Ethernet),capturesize262144^C49packets719packetsreceivedby0packetsdroppedbyWiresharkhttps.capfiltertls，得到如下請(qǐng)求和響應(yīng)的“ApplicationData”了。握手的過程略復(fù)雜，接下來我會(huì)盡可能用通俗的語言把最主要對(duì)稱性加密（ymmetricCryptoraphy），指的是加密和使用相同的密鑰。這種方式相對(duì)簡(jiǎn)單，加密速度快，但是由于加密和需要使用相同的密鑰，如何安全地傳遞密鑰，往往成為一個(gè)難題。非對(duì)稱性加密（AsymmetricCryptography），指的是數(shù)據(jù)加密和需要使用不同的密鑰。通常一個(gè)被稱為公鑰（PublicKey），另一個(gè)被稱為私鑰（PrivateKey），二者一般Step .客戶端產(chǎn)生的隨機(jī)數(shù)Step2:Servero.服務(wù)端也很有禮貌，向客戶端回了個(gè)招呼：服務(wù)端產(chǎn)生的隨機(jī)數(shù)B； Step3:,ServerKeyExchange,ServeroDone.服務(wù)端在招呼之后也接著客戶端再生成一個(gè)隨機(jī)數(shù)C（Pre-masterSecret），于是現(xiàn)在共有隨機(jī)數(shù)A、B和C，根據(jù)約好的加密方法組合，三者可生成新的密鑰X（MasterSecret），而由X可繼續(xù)生成真正用于后續(xù)數(shù)據(jù)進(jìn)行加密和的對(duì)稱密鑰。因?yàn)樗窃诒敬蜹LS會(huì)話中生成的，所以也被稱為會(huì)話密鑰（SessionSecret）。簡(jiǎn)言之：ABPre-masterSecretCPre-masterSecretRSAPre-masterSecret過KeyExchange發(fā)回服務(wù)端。ECDHEPre-masterSecret要通過KeyExchange和ServerKeyExchange兩者承載的參數(shù)聯(lián)合生成。Step4:KeyExchange,ChangeCipherSpec,EncryptedHandshakeMessage.接著客戶端告訴服務(wù)端：KeyExchange，本質(zhì)上它就是上面說的這個(gè)C，但使用了服務(wù)端通過發(fā)來的ChangeCipherSpec，客戶端同意正式啟用約好的加密方法和密鑰了，后面的數(shù)據(jù)傳輸全部都使用密鑰X來加密；EncryptedHandshakeMessage，快速驗(yàn)證：這是客戶端對(duì)于整個(gè)進(jìn)行 服務(wù)端收到消息后，用自己私鑰上面的KeyExchange，得到了C，這樣它和客戶端一樣，也得到了A、B和C，繼而到X，以及最終的會(huì)話密鑰。因此，我們可以看到：TLS（公鑰加這種通過較嚴(yán)格、較復(fù)雜的方式建立起消息交換，再通過相對(duì)簡(jiǎn)單且性能更高的方式來實(shí)際完成主體的數(shù)據(jù)傳輸，并且前者具有長效性（即公鑰和私鑰相對(duì)穩(wěn)定），后者具有一過性（密鑰是臨時(shí)生成的），這樣的模式，我們還將在全棧的知識(shí)體系中，繼續(xù)見到。Step5:ChangeCipherSpec,EncryptedHandshakeMessage.服務(wù)端最后也告知客ChangeCipherSpec，服務(wù)端也同意要正式啟用約好的加密方法和密鑰，后面的數(shù)據(jù)傳輸全部都使用X來加密。EncryptedHandshakeMessage，快速驗(yàn)證：這是服務(wù)端對(duì)于整個(gè)進(jìn)行 HTTPSSSL/TLS們之間的關(guān)系，還通過自己動(dòng)手抓包的方式，詳細(xì)學(xué)習(xí)了TLS連接建立的步驟。TLS有位程序員朋友注意到，自己在使用支付功能時(shí)，是使用HTTPS加密的，在介紹TLS/SSL連接建立的過程當(dāng)中，我提到了，握手過程是使用非對(duì)稱加密實(shí)現(xiàn)的，你能回答上面的問題嗎？如果可以，我相信你已經(jīng)理解了HTTPS安全機(jī)制建立的原理。在講解“握手過程”的step3時(shí)，我提到了客戶端在收到服務(wù)端發(fā)送過來的時(shí)，需要這就是我們抓包中，服務(wù)器發(fā)來的部分的截圖。我們可以看到，這不是單個(gè)，而是一個(gè)鏈，包含了兩個(gè)，每個(gè)都包含版本、發(fā)布機(jī)構(gòu)、有效期、數(shù)字簽名等基本內(nèi)容，以及一個(gè)公鑰。實(shí)際上，這兩個(gè)服務(wù)端傳回來的，和瀏覽器內(nèi)置的根聯(lián)合起來，組成了一個(gè)單向、完整的鏈：上圖中的第三行，就是攜帶著服務(wù)器公鑰的，它是從發(fā)布機(jī)構(gòu)（CA,Authority）申請(qǐng)得來的，也就是圖中第二行的GTSCA1O1。在申請(qǐng)的時(shí)候，我們提在當(dāng)時(shí)申請(qǐng)的時(shí)候，發(fā)布機(jī)構(gòu)對(duì)做生成，并使用它自己的私鑰為該加密，生成數(shù)字簽名（DigitalSignature），而這個(gè)數(shù)字簽名也隨一起發(fā)布。這個(gè)發(fā)布+私鑰→數(shù)字簽名 ，得到P1；使用發(fā)布機(jī)構(gòu)的公鑰對(duì)它的數(shù)字簽名進(jìn)行，得到P2。數(shù)字簽名+公鑰→如果P1和P2一致，就說明未被篡改過，也說明這個(gè)服務(wù)端發(fā)來的是真實(shí)有效好，問題來了，發(fā)布機(jī)構(gòu)使用非對(duì)稱性加密和數(shù)字簽名保證了的有效性，那么CA是分級(jí)管理的，每一級(jí)CA都根據(jù)上述同樣的原理，由它的上一級(jí)CA來加密和生成數(shù)字簽名，來保證其真實(shí)性，從而形成一個(gè)單向的信任鏈。同時(shí)，標(biāo)志著別CA的根數(shù)量非常少，且一般在瀏覽器或操作系統(tǒng)安裝的時(shí)候就被預(yù)置在里面了，因此它們是被我們完全信任的，這就使得真實(shí)性的鑒別遞歸有了最終出口。也就是說，遞歸自下而上驗(yàn)證的過程，如果一直正確，直至抵達(dá)了頂端——瀏覽器內(nèi)置的根，就說明服務(wù)端送過被檢測(cè)的數(shù)字簽名，如果順利，并且得到的和被檢測(cè)做得到的指HOWHTTPSWORKSHTTPSTheFirstFewMillisecondsofanHTTPSConnection：如果你想深究你抓到的TLS文中介紹了兩種生成Pre-masterSecret的方法，其中第二種的方法是 ?歸科技所有，不得售賣。頁面已增加防盜追蹤，將依法其上一 01|網(wǎng)絡(luò)互聯(lián)的昨天、今天和明天：HTTP協(xié)議的演下一 03|換個(gè)角度解決問題：服務(wù)端推送技言言飯團(tuán)作者回復(fù):1）結(jié)論正確，但是解釋不太妥當(dāng)。HTTPS可以達(dá)到數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中的可靠性，HTTPS端、服務(wù)端，因此HTTPS的安全性結(jié)論無法推廣到整個(gè)支付過程和支付行為的安全性結(jié)論。4 TLSRepudiation（否認(rèn)），請(qǐng)注意