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

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