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

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