openssl握手源代碼分析

AThesisSubmittedinPartialFulfillmentoftheRequirementsfortheDegreeofMasterofEngineeringyzeonSourceCodeofOpenSSLHandshake :Xie :Prof.QinZhongHuazhongUniversityofScience&TechnologyWuhan430074,P.R.China華技大學(xué)華技大學(xué)隨著Internet的迅速發(fā)展和廣泛應(yīng)用,網(wǎng)絡(luò)與的重要性和緊迫性日益突出。Netscape公司提出了接層協(xié)議SSL(SecureSocketLayer),該協(xié)議基于公開密鑰技術(shù),可保證兩個(gè)實(shí)體間通信的性和可靠性,是目前Internet上通我們目前使用的很多軟件是在編寫的。過去曾對(duì)加密算法的出口有所限制。雖然2000年1月放寬了出口限制，高強(qiáng)度的加密算法已經(jīng)允許出口，但是我們并不能保證在我們使用的軟件中都集成了這樣高強(qiáng)度的算法。在SSLTLSOpenSSL是對(duì)SSL協(xié)議的實(shí)現(xiàn)，其公開的文檔在OpenSSL發(fā)布，其文檔也OpenSSL命令行工具用法，APIOpenSSL源代碼SSL握手過程作了理論上的分析，這是它們能夠保證通信安全的基礎(chǔ)。理論，深入研究了SSL握手的過程是如何實(shí)現(xiàn)的，其中包括SSL會(huì)話的密鑰是如何在握手過程中生成的，即密鑰導(dǎo)出函數(shù)。最后，通過ssldump軟件了SSL連接中的所有消息，分析了SSL的握手的三種模式：、雙向認(rèn)證、會(huì)話恢復(fù)。 接層協(xié) 握 密鑰導(dǎo)出函WiththerapiddevelopmentandtheextensiveapplicationofInternet,theimportanceandtheurgencyofthenetworkandinformationsecurityhave eincreasinglyprominent.NetscapeCompanyhasputforwardtheSecureSocketLayerprotocolSSL(SecureSocketLayer)basedonpublic-keytechnology,thereforeitcanguaranteetheityandthereliabilityofthecommunicationsbetweentwoentities.TheSSLprotocolistheIndustryStandardforsecurecommunicationsviaManysoftwareproductsweareusingnowarewrittenintheUSA.TheUSAlimitedtheexportofencryptionalgorithmsinthepast.AlthoughinJanuary2000,theUSArelaxedthislimitationandexportofencryptionalgorithmswithhighintensitywerenolongerforbidden,wecannotmakesurethatthehighintensityalgorithmshavebeenintegratedintothesoftwareproductsweemploy.ItisstillthebestchoicetouseourownencryptionalgorithmsinSSLandTLSprotocols.TheOpenSSLisanopensourceproductimplementingSSLprotocol.ItssarepublishedontheofficialwebsiteofOpenSSL.ThesofOpenSSLarelimitedincommandlinetoolandAPISpecifications,butitisdifficulttosearchthepublishedliteraturesabouttheysisofthesourcecodesofOpenSSL.Thefirststepistodeeplyysethehandshakeprocess.ItisthefoundationonwhichSSLandTLScanensurecommunicationsecurity.Thehandshakeprocesscontainstheexchangeofmanykindsofmessages.Itisnecessarytocomprehendtheirorder,structure,contentandeffewellasKDFhiddenbehindthem.thenbasedonthesourcecodesofOpenSSL.WedeeplystudyhowtorealizeSSLcommunication.Intheend,accordingtotrackingtheclientandservercommunicationsofOpenSSLbyssldump,thewholeprocessofyzingontheSSLshakehandandencryptionofapplicationdatahasbeencompleted. ............................................................................................................I 緒課題背 本文的主要工 SSL協(xié)議概SSL協(xié)議的體系結(jié) SSL協(xié)議的基本特性及功 SSL協(xié)議的分層模 小 SSL握手理SSL握手目 SSL握手消 SSL握手過程分 小 SSL握手過程實(shí)現(xiàn)的分OPENSSL連接建立的過 OPENSSL握手消息結(jié) SSL連接實(shí)現(xiàn)細(xì) 一次真實(shí)的SSL連 小 SSL連接分測(cè)試內(nèi)容和目 測(cè)試環(huán) 測(cè)試過程和結(jié)果分 小 結(jié)束工作總 進(jìn)一步的工 致 參考文 課題背景當(dāng)我們享受著網(wǎng)絡(luò)所帶來的各種各樣便利的同時(shí)，這樣或那樣的安全也緊跟而來[1]。也越來越被受關(guān)注。SSL及其后繼者TLS是兩個(gè)已經(jīng)被廣泛應(yīng)用的HTTP協(xié)議的。如果與別的應(yīng)用層協(xié)議相結(jié)合，它們的應(yīng)用將更為廣泛，例如FTP。SSL經(jīng)過了幾次版本變更，出現(xiàn)了不同的變種。國外已經(jīng)有很多支持或者實(shí)現(xiàn)SSL與TLS的產(chǎn)品。商業(yè)產(chǎn)品有的IE瀏覽器，IIS服務(wù)器，網(wǎng)景公司的Netscape瀏覽器，SunJSSEC/C＋＋的工具箱。還有很多實(shí)SSL的開源軟件或者軟件包：著名的openSSL，Tomcat服務(wù)器，Apache服務(wù)器和最近很受歡迎的FireFox瀏覽器。由于眾多計(jì)算機(jī)軟件都是在編寫的，的出口限制對(duì)通信安全系統(tǒng)的設(shè)計(jì)有著戲劇性的影響。199891998年9月，加密經(jīng)過修訂，可以允許出口56位加密和1024位的鑰交換。在20001月，這些限制大大的放松。開源軟件的代碼可以簡(jiǎn)單地放到網(wǎng)絡(luò)上。盡管零售軟件仍然要經(jīng)過技術(shù)復(fù)查，但BXA(出口管理局)已經(jīng)允許許多具有高強(qiáng)度加密的產(chǎn)品的出口[3]。雖然目前有了這些自由，但是，SSLVersion3.01996年發(fā)布的，而TLSVersion1.0(SSLVersion3.1)1999年發(fā)布的。從上面的時(shí)間段可以看到，那時(shí)正是加密算法出口受到限制或者是剛剛放寬的時(shí)候。許多協(xié)議都包含設(shè)計(jì)用于在可出口環(huán)境中工作的功能，當(dāng)然SSLTLS也不例外。它們之中的加密套件就有是否可出口(IsExportable)SSLTLS說明的加密現(xiàn)和限制。也就是說，我們?nèi)绻玫某隹诋a(chǎn)品，很可能就不能使用高強(qiáng)度的加密算法，因?yàn)檫@種算法沒有被到出口的產(chǎn)品中，盡管現(xiàn)在這種限制目前在1999Eurocrypt上，AdiShamire描述了一種稱作“Twinkle”RSA密們所擁有的技術(shù)和硬件性能，512位RSA并不足夠的安全。SSL/TLS，我們就可以集成自行開發(fā)的加密本文的主要工作SSL協(xié)議的探討主要局限在理論研究和實(shí)際應(yīng)用，從實(shí)現(xiàn)源碼的角度去分析SSL協(xié)議的很少。然而這并不是代表OpenSSL源碼十分安全，不存在人為設(shè)SSL連接建立的過程，主要從三個(gè)層次去分析驗(yàn)證這一過程的安理論分析：探討了SSL連接建立的理論，重點(diǎn)分析了SSL握手過程，為后續(xù)源碼分析：以O(shè)penSSL版本0.9.8.e為基礎(chǔ)，以SSL_accept和消息分析：通過ssldump軟件SSL連接建立過程中的協(xié)議消息，分SSLSecureSocketsLayer(接字層，簡(jiǎn)稱SSL)協(xié)議是由Netscape公司為制定0RSA算法之外的其他算法的支持和一些安全特性，并且修SSLTLS10TransportLayerSecurity)版本，Netscape公司宣布支數(shù)據(jù)完整性、及信息性等安全措施。該協(xié)議通過在應(yīng)用程序進(jìn)行前交換SSL初始握手信息來實(shí)現(xiàn)有關(guān)安全特性的。在SSL握手信息中采用了DES,MD5等加密技術(shù)來實(shí)現(xiàn)性和數(shù)據(jù)完整性，并采用X.509的數(shù)字實(shí)現(xiàn)鑒別。InternetIntranet的服務(wù)器產(chǎn)品和客戶端產(chǎn)品中。如Netscape公司、微軟公司、IBM公司等Internet/Intranet網(wǎng)SSL協(xié)議的體系結(jié)構(gòu)從一般的看來，在應(yīng)用層進(jìn)行安全處理是最容易理解的，而且不需要對(duì)網(wǎng)全機(jī)制，不僅需對(duì)系統(tǒng)的框架完全了解。而且要對(duì)應(yīng)用程序進(jìn)行改造。因此，圖 SSLOR模型中，SSL介于傳輸層(TCP/IP和應(yīng)密、客戶端與服務(wù)器端驗(yàn)證等功能。它的主要目標(biāo)是在兩個(gè)通信應(yīng)用之間提供私有性和可靠性[7]。SSL的體系結(jié)構(gòu)如圖2.2所示。圖 協(xié)議的基本特性及功能SSL協(xié)議基本特性SSL協(xié)議提供的安全連接具有以下幾個(gè)基本特性連接是安全的，在初始化握手結(jié)束后，SSL使用加密方法來協(xié)商一個(gè)的密鑰，數(shù)據(jù)加密使用對(duì)稱密鑰技術(shù)(如DES,RC4等)?？梢酝ㄟ^非對(duì)稱(公鑰)加密技術(shù)(如RSA,DSA等)認(rèn)證對(duì)方的連接是可靠的，傳輸?shù)臄?shù)據(jù)包含有數(shù)據(jù)完整性的，使用安全的函數(shù)(如SHA,MD5等)計(jì)算SSL協(xié)議基本功能數(shù)據(jù)加密(DataDiffie-man算法，Diffie-man算法將一個(gè)非常大的質(zhì)數(shù)作為數(shù)據(jù)加密使用，由此質(zhì)數(shù)導(dǎo)出另一個(gè)非常大的質(zhì)數(shù)作為使用。數(shù)字簽名(Digital除了數(shù)據(jù)加密之外，SSL也支持?jǐn)?shù)字簽名，其主要目的在于確保發(fā)送信息者確實(shí)為發(fā)送該信息的來源，以防止網(wǎng)絡(luò)者利用他人或的服務(wù)器發(fā)送假信修改(數(shù)據(jù)完整性)。SSLSSLHTTP通信協(xié)議最大的不同在于，HTTP屬于無狀態(tài)連接。每一個(gè)客戶端HTTPWeb服務(wù)器，服務(wù)器端仍無法判別是否來自同一客戶端。而SSL為了確?？蛻舳说陌踩玈SL協(xié)議的分層模型SSL協(xié)議是一個(gè)分層的協(xié)議，共有兩層組成。處于SSL協(xié)議的底層的是SSL記錄層協(xié)議(SSLRecordProtocol)，它位于可靠的傳輸層協(xié)議(TCP/IP)之上，用于封裝協(xié)議的數(shù)據(jù)。協(xié)議主要包括SSL握手協(xié)議(SSLHandshakeProtocol)、改變加定協(xié)議(ChangeCipherSpecProtocol)、協(xié)議(AlertProtocol)等。據(jù)之前協(xié)商出一個(gè)加密算法和會(huì)話密鑰，是SSL協(xié)議的[9]。圖 記錄層協(xié)議SSL記錄協(xié)議可為SSL連接提供性業(yè)務(wù)和消息完整性業(yè)務(wù)。性業(yè)務(wù)是SSL負(fù)載的單鑰加密。消息完整性業(yè)務(wù)是通過握手協(xié)議建立一個(gè)用于計(jì)算MAC的共享密鑰。SSL協(xié)議將被發(fā)送的數(shù)據(jù)分為可供處理的數(shù)據(jù)段，它沒有必要去解釋這些據(jù)，處理過程與上相反，即、驗(yàn)證、解壓縮、重新拼裝，然后發(fā)送到更的2.4SSL記錄層協(xié)議的整個(gè)執(zhí)行過程[10]。圖 分SSL明文記記錄塊的壓縮和解壓)而且不能使壓縮后數(shù)據(jù)長(zhǎng)度增加超過1024字節(jié)[11](在原來數(shù)據(jù)就已經(jīng)是壓縮數(shù)據(jù)時(shí)，再使用壓縮算法就可能因添加了縮信息而增大)記錄負(fù)載的保都會(huì)有一個(gè)激活的加定，但是在初始化時(shí)，加定被定義為空，這意味著并一旦握手成功，通信雙方就共個(gè)會(huì)話密鑰，這個(gè)會(huì)話密鑰用來加密記錄，并計(jì)算它們的信息(MAC)。加密算法和MAC函數(shù)把SSL壓縮記錄轉(zhuǎn)換成SSL主要版本(8比特)SSL的主要版本。對(duì)于SSLV30字段值3壓縮長(zhǎng)度(16比特：文數(shù)據(jù)片以字節(jié)為單位的長(zhǎng)度(如果使用壓縮就是壓縮數(shù)據(jù)片)。的記錄層(recordlayer)里完成的。正是在記錄層對(duì)數(shù)據(jù)進(jìn)行了加密、和認(rèn)證[12]。圖 改變加定協(xié)改變加定協(xié)議(changecipherspecprotocol)是最簡(jiǎn)單的特定于SSL的協(xié)議，它的存在是為了使策略能得到及時(shí)[13]。該協(xié)議只有一個(gè)消息，是一個(gè)字而不是改變后的加定?？蛻舴胶头?wù)器方都會(huì)發(fā)出改變加定消息，通知接收方面發(fā)送的記錄將使用剛剛協(xié)商的加定來保護(hù)?？蛻舴皆诎l(fā)送握手密鑰交換和檢驗(yàn)消息后發(fā)送一個(gè)意外的改變加定消息將導(dǎo)致一個(gè)UnexpectedMessage警報(bào)。當(dāng)恢復(fù)之前的會(huì)話時(shí)，改變加定消息將在問候消息后發(fā)送。警報(bào)協(xié)議SSLSSL記錄層支持的協(xié)SSL握手協(xié)議中的錯(cuò)誤處理：警報(bào)消息當(dāng)任何一方檢測(cè)到一個(gè)錯(cuò)誤時(shí)，檢測(cè)的一方就向另一方發(fā)送一個(gè)消息。如果警報(bào)消息有一個(gè)致命的，則通信的雙方應(yīng)警報(bào)、缺少警報(bào)、已破壞警報(bào)、不支持格式警報(bào)、已作廢警報(bào)、握手協(xié)議SSL握手協(xié)議在SSL記錄層之上，是SSL協(xié)議中最復(fù)雜的協(xié)議。服務(wù)器和客戶端使用這個(gè)協(xié)議相互鑒別對(duì)方的、協(xié)商加密算法和MAC算法以及在SSL記錄建立SSL連接首先應(yīng)該執(zhí)行的協(xié)議，必須在傳輸任何數(shù)據(jù)之前完成。小本章詳細(xì)講SSL安全傳輸協(xié)議的體能，還分SSL分層模型，包括記錄層協(xié)議、握手協(xié)議、改變加定協(xié)議、告警協(xié)議等各個(gè)組成協(xié)議進(jìn)行了深入的分析；然后，又講解了會(huì)話與連接、加密套件、驗(yàn)證等SSL協(xié)議中的重要概念；最后，分析了SSL協(xié)議的安全性。SSLSSLSSL握手實(shí)現(xiàn)對(duì)服務(wù)器、客戶端(可選)的認(rèn)證SSL握手些消息與哪幾步相對(duì)應(yīng)，圖3.1描述了各條消息。 圖 握手的第二步對(duì)應(yīng)一系列SSL握手消息，服務(wù)器發(fā)送的第一條消息為Servero，其中包含了它所選擇的算法，接著再在消息中發(fā)送其。最后，服務(wù)器發(fā)送ServeroDone消息以表示這一握手階段的完成。需要ServeroDone的原因是一些更為復(fù)雜的握手變種還要在之后發(fā)送其他一些消息。當(dāng)客戶端接收到ServeroDone消息時(shí)，它就知道不會(huì)再有其他類似消息的MAC值。然而，由于Finish消息是以磋商好的算法加以保護(hù)的，所以也要與新磋商的MAC密鑰一起計(jì)算消息本身的MAC值。 o：當(dāng)客戶端第一次連接到服務(wù)器時(shí)，應(yīng)將Cliento作為第一條信息發(fā)給服務(wù)器。Cliento包含了客戶端支持的所加密算法，有壓縮算法，Servero：Servero信息的結(jié)構(gòu)類似Cliento，它是服務(wù)器對(duì)客戶端的Cliento信息的回復(fù)。該消息包含了SSL服務(wù)端從客戶問候消息中選擇的本次會(huì)話使用的加密算法和壓縮算法同時(shí)還有SSL服務(wù)端確定的會(huì)話ID和本次連接SSLServer：如果要求驗(yàn)證服務(wù)器，則服務(wù)器立刻在Servero信息后發(fā)送其()。的類型必須適合密鑰交換算法，通常為X.509v3版的。ServerKeyExchange：SSL服務(wù)器端向客戶端發(fā)送SSL服務(wù)端密鑰交換消息，該消息包含了密鑰交換算法，如從密鑰集中選擇DESRSASHA這對(duì)組合，加密算法采用DES；密鑰交換算法采用RSA；計(jì)算消息算法采用SHA。 Request)。該消息包含了SSL服務(wù)端可鑒別的類型和可信任的CA序列SSL客戶端返回的必須符合其中的某項(xiàng)類型和由其中的某個(gè)CA頒發(fā)。ServeroDone：服務(wù)器發(fā)出該信息表明Servero結(jié)束，然后等待客戶端響應(yīng)，客戶端收到該信息后檢查服務(wù)器提供的是否有效，以及服務(wù)器的o參數(shù)是否可接受。Client：該信息是客戶端收到服務(wù)器的ServeroDone后可以發(fā)送的，則發(fā)送沒有的警告信息，如果服務(wù)器要求有客戶端驗(yàn)證，則收到ClientKeyExchange：信息的選擇取決于采用何種公開密鑰算法，密鑰交換消息的內(nèi)容會(huì)根據(jù)本次會(huì)話選擇的密鑰交換算法而有所不同。如果本次會(huì)話選擇的是RSA算法，那么本消息包含的是經(jīng)RSA公鑰加密過預(yù)加密主密鑰。如果選擇的是Verify：該消息用于提供Certificat的驗(yàn)證，它僅在具有簽名能力的客戶端傳送之后傳送。ChangeCipherSpec：客戶端改變加密規(guī)范的過程是：用服務(wù)端的公鑰加密ClientKeyExchange的內(nèi)容并發(fā)給服務(wù)器端。隨后的服務(wù)端改變加密規(guī)范的過程是用自己的私鑰客戶端的密文，并得到ClientKeyExchange的內(nèi)容。FinishedChangeCipherSpec之后發(fā)送，以證明密鑰交換和驗(yàn)證的過順利進(jìn)行，發(fā)方在發(fā)出Finished信息后可立即開始傳送數(shù)據(jù)，收方在收到FinishedHash值是SSL握手過程分析SSL連接的建立包含兩個(gè)階段：握手和數(shù)據(jù)傳輸。在握手階段，客戶端和服務(wù)數(shù)據(jù)。SSL握手協(xié)議位于記錄層協(xié)議之上，在客戶端與服務(wù)器真正傳輸應(yīng)用數(shù)據(jù)前，由它們協(xié)商出協(xié)議版本，加密套件，一系列共享密鑰等[17]。SSL協(xié)議的握手步驟如圖3.2所示。圖 報(bào)文組成，一個(gè)Cliento報(bào)文，一個(gè)是Servero報(bào)文，協(xié)議的發(fā)起由客戶端執(zhí)如果服務(wù)器需要被鑒別，這個(gè)階段將以服務(wù)器給客戶端發(fā)送自己的開始執(zhí)行。這個(gè)階段，服務(wù)器可能向客戶端發(fā)送的信息包括或鏈報(bào)文、密鑰交換報(bào)文、客戶請(qǐng)求報(bào)文以及完成報(bào)文。除了最后一個(gè)報(bào)文，并非所有報(bào)受到服務(wù) ，報(bào)文(或者無告警信息)、客戶密鑰交換報(bào)文和驗(yàn)證報(bào)文中的一個(gè)或多義報(bào)文將掛起的算法族定義到當(dāng)前的算法族定義。然后客戶立刻接著發(fā)送在新的算法、密鑰和下的完成報(bào)文。服務(wù)器對(duì)這兩個(gè)報(bào)文的響應(yīng)是發(fā)送自己的改變算法定義報(bào)文將掛起狀態(tài)到當(dāng)前狀態(tài)，并發(fā)送完成報(bào)文[21]。到此為止，握手協(xié)SSL連接進(jìn)行安全小SSL握手協(xié)議在SSL記錄層之上，是SSL協(xié)議中最復(fù)雜的協(xié)議。服務(wù)器和客戶端使用這個(gè)協(xié)議相互鑒別對(duì)方的、協(xié)商加密算法和MAC算法以及在SSL記錄建立SSL連接首先應(yīng)該執(zhí)行的協(xié)議，必須在傳輸任何數(shù)據(jù)之前完成。華技大學(xué)華技大學(xué) 握手過程實(shí)現(xiàn)的分析本章將從OpenSSL源代碼的角度，深入分析SSL握手過程是如何實(shí)現(xiàn)的，并結(jié)合前兩章的理論分析驗(yàn)證SSL握手過程的實(shí)現(xiàn)是否與理論相符。OpenSSL目前版本0.9.8.e[24]三個(gè)主要的功能部分：算法庫、SSL協(xié)議庫以及應(yīng)用程序。OpenSSL的結(jié)構(gòu)也是圍繞這三個(gè)功能部分進(jìn)行規(guī)劃的，如表4.1所示[25]。表 名功能描述 檔以及SSL協(xié)議API說明文檔。 OpenSSL軟件包非常龐大，本文深入分析的是SSL握手過程的實(shí)現(xiàn)，而SSL握手屬于SSL協(xié)議，所以我們研究的重點(diǎn)集中在SSL下的源代碼。OpenSSL連接建立的過程初始化SSL環(huán)境SSL連接、服務(wù)器端接受連接請(qǐng)求之前，都需要對(duì)上下文(context)進(jìn)行初始化，建立上下文對(duì)象。然后再利用這個(gè)上下文對(duì)象來為每個(gè)新的SSL連接華技大學(xué)華技大學(xué)初始化ssl庫，其作用是可用的和消息算法SSLCTXmethod是所用的連接方法。下面三組函數(shù)用于創(chuàng)建各種SSL_MEHTOD，它們都沒有參數(shù)，都返回SSL_METHOD結(jié)構(gòu)的指針：SSLv2_method()，SSLv2_server_method()，SSLv2_client_method()使用這些函數(shù)返回的SSL_METHOD結(jié)構(gòu)建立的SSL結(jié)構(gòu)(代表SSL連接)只能理解sslv2協(xié)議。SSLv2_server_method(void)用于服務(wù)器端，SSLv2_client_method(void)用于客戶端，SSLv2method(void)用于既是客戶又是服務(wù)器的情況，SSLvoidSSL_set_connect_state(SSL*ssl)voidSSL_set_accept_state(SSL*ssl)來指定是作為客戶還是服務(wù)器。SSLv3_method()，SSLv3_server_method()，SSLv3_client_method()TLSvl_method()，TLSvl_server_method()，TLSvl_client_method()SSL_CTX_set_verify(SSLCTX*ctx，int用于設(shè)置驗(yàn)證方式。mode是以下值的邏輯或：SSL_VERIFY_NONE證;SSL_VERIFY_PEER用于客戶端時(shí)要求服務(wù)器必須提供，用于服務(wù)器時(shí)服務(wù)器會(huì)發(fā)出請(qǐng)求消息要求客戶端提供(但客戶端也可不提供)SSL_VERIFY_FAIL_IF_NO_PEER_CERT只適用于服務(wù)器且必須與的回調(diào)函數(shù)，如果沒有特殊的需要，傳入NULL表示使用OpenSSL提供的缺省驗(yàn)證SSL_CTX_load_verify_locations(SSL_CTX*ctx，char*CAfile，char*用于加載受信任的CACAfile如果不為NULL，則它指向的文件包含PEM編碼格式的一個(gè)或多個(gè)CA。CApath如果不為NULL，則它指向一個(gè)包含PEM格式的CA的，中每一個(gè)文件包含一份CA，文件名是中CA名的HASH值，可使用OpenSSL華技大學(xué)華技大學(xué)SSL_CTX_use__fi1e(SSLCTX*ctx，constchar*file，int用于加載自已的.file指向文件，type指定文件的編碼類型：SSLFILETYPEPEMSSLFILETYPEASN1.1表示成功，返回0表示失敗。SSL_CTX_use_PrivateKey_file(SSL_CTX*ctx，constchar*file，int用于加載自已I均私鑰file指向私鑰文件，typeSSL_FILETYPE_PEMSSL_FILETYPE_ASN1返回1表示成功，返回0表示失SSLCTXcheck_private_key(SSLCTX*設(shè)置允許使用的組，成功返回1，失敗返回0。str表示允許使用的組列表，TLS_RSA_WITH_RC4_128_SHA和TLS_RSA_WITH_3DES_EDE_CBC_SHA。SSL連一旦SSL完成了對(duì)SSL上下文對(duì)象的初始化后，它已經(jīng)為連接到服務(wù)器做好準(zhǔn)建立連接的過程也就是握手的過對(duì)于一個(gè)SSL上下文對(duì)象可以建立多個(gè)SSL連SSLTLS/SSLTLS/SSL連接需要的SSL結(jié)構(gòu).SSLSSLctx繼承設(shè)置.SSL重新進(jìn)行設(shè)置以取代從SSL環(huán)境中繼承的缺省設(shè)置，新作的設(shè)置只對(duì)該SSL結(jié)構(gòu)有效，與從同一環(huán)境創(chuàng)建的其他SSL結(jié)構(gòu)無關(guān).必須為每一個(gè)SSL結(jié)構(gòu)設(shè)置底層的通信通道.SSL_set_fd(SSL*ss1，intfdss1的輸入輸出設(shè)備(即通信通道)I/0都將通過fd進(jìn)行通常，fd是一己經(jīng)建立的套接字連接的套接字描述符ssl繼fdfdss1fd是阻塞的缺省，則ss1也是阻塞的.SSL_set_fd()1表示成功，返回0表示失敗。TLS/SSL連接，也可以直接進(jìn)行讀寫操作，由讀寫操作去建立TLS/SSL連接要顯式建立連接。服務(wù)器端調(diào)用：intSSL_accept(SSL*ss1)，客戶端調(diào)用：intSSL_accept(SSL*ss1)。要重試.intSSL_get_error(SSL*ss1，intret)ret為SSL_acceptSSL_connect()的返回值，若需要重試SSL_get_error返回SSL_ERROR_WANT_READ或SSL_ERROR_WANT_WRITE。傳送數(shù)據(jù)intSSL_read(SSL*sslchar*huf，intnum)intSSL_write(SSL*ssT，char*huf，intnum)bufnum字節(jié)數(shù)據(jù)寫ssl.這兩個(gè)函數(shù)成功時(shí)返回實(shí)際讀寫的字節(jié)數(shù)。若0或負(fù)數(shù)，則表示調(diào)用失敗或需要重試.若需要重試，SSL_get_error()調(diào)用將返回SSL_ERROR_WANT_BEAD或SSL_ERROR_WANT_WRITE。如果TLS/SSL連接尚末建立，則SSLread()或SSL_write()調(diào)用將自動(dòng)建立TLS/SSL連接。如果連接的對(duì)方要求重新協(xié)商，SSLread()SSLwrite()調(diào)用也會(huì)自動(dòng)處理。在阻塞模式下，SSL_read)或SSL_write()調(diào)用直到成功執(zhí)行或發(fā)生錯(cuò)誤時(shí)才返回，除非需要重新協(xié)商連接參數(shù)SSL_read()SSL_write()調(diào)用也會(huì)立即返回并產(chǎn)生SSL_ERROR_WANT_READ或SSL_ERROR_WANT_WRITE，表示需要重試.要使阻塞模式下的SSL_read()SSL_write調(diào)用自動(dòng)處理重試，可使用SSL_MODE_AUTO_RETRY標(biāo)志調(diào)用SSL_CTX_set_mode()或SSL_set_mode()。SSL連關(guān)閉TLS/SSL連接。SSL_free(SSL*ssl)釋放SSL結(jié)構(gòu)。SSL_CTX_freeSSL_CTX*ctx)釋放SSL_CTX結(jié)構(gòu)。OpenSSLSSLSSLSSL連接的實(shí)現(xiàn)細(xì)節(jié)是復(fù)雜的，OpenSSL提供給調(diào)用者的編程接口很成功封裝了這些復(fù)雜的細(xì)節(jié)，在下一節(jié)，深入討論這些復(fù)OpenSSL握手消息結(jié)構(gòu)每一種SSL握手消息都由一個(gè)簡(jiǎn)單的頭信息以及依賴與消息類型的消息體組成，下面的枚舉類型描述了OpenSSL的消息取值定義[27]。enumo_request(0),client_o(1),server_o(2)(11),server_key_exchange(12),_request(13),server_done(14), _verify(15),client_key_exchange(16),finished(20),(255)}段表示剩余握手消息的長(zhǎng)度(不包括類型與長(zhǎng)度字段)，余下的消息內(nèi)容完全有賴于msg_type字段。嚴(yán)格來講，長(zhǎng)度字段并不是必需的，因?yàn)榭梢詮母鹘M成部分來判斷單一的一條握手消息可以多條記錄，但在實(shí)際應(yīng)用中卻不會(huì)出現(xiàn)這樣的情況[28]Uinit24length;Select(HandshakeType) Caseclient_o:Client Caseserver_o:Server Case Case華技大學(xué)華技大學(xué)Casefinished:Cliento消當(dāng)客戶端第一次連接到服務(wù)器時(shí)，客戶端必需初始化一個(gè)Cliento消息，將Cliento作為第一條信息發(fā)給服務(wù)器。該消息的內(nèi)容是向服務(wù)器提供關(guān)于客戶端縮方法。該消息也可以作為客戶端對(duì)一個(gè)o請(qǐng)求(來自服務(wù)器)的響應(yīng)，或者由客戶端版本號(hào)(clientversion)SSL隨機(jī)數(shù)(random)：該域中包含一個(gè)由客戶端生成的隨機(jī)結(jié)構(gòu)，它將用于4字節(jié)的日期/28字節(jié)數(shù)據(jù)是隨機(jī)生成的。日期/時(shí)間戳有助于防止重放[31]。組(ciphersuite)：該域中包含一個(gè)客戶端支持的算法組合的列表。該列表按照客戶端優(yōu)先選擇的次序排列(也就是第一選擇優(yōu)先)。該列表用于使服務(wù)器了解客戶端所支持的組，但是最終卻是由服務(wù)器來決定使用何種算法。并關(guān)閉該。壓縮算法(compressionmethods)：與組域相似，該域列出客戶端已知的返回一個(gè)握手失敗警告并關(guān)閉該。發(fā)送一個(gè)Cliento消息之后，客戶端等待一個(gè)Servero消息。如果服務(wù)華技大學(xué)華技大學(xué)Servero消Servero信息的結(jié)構(gòu)類似Cliento，它是服務(wù)器對(duì)客戶端的Cliento消息來響應(yīng)。Servero消息的內(nèi)容與Cliento消息的內(nèi)容相似。服務(wù)器版本號(hào)(serverversion)：該域中包含由服務(wù)器決定的版本號(hào)；該版本則服務(wù)器決定使用SSLV3.0。后面的學(xué)計(jì)算。然而，它必須獨(dú)立于客戶端生成的隨機(jī)數(shù)，并且必須與之不相會(huì)話(sessionid)：該域提供了與當(dāng)前連接相對(duì)應(yīng)的會(huì)話的標(biāo)識(shí)信息。如果從組(ciphersuite)：該域標(biāo)識(shí)由服務(wù)器從客戶端提供的列表中選擇出來的壓縮方法(compressionmethod)：與組消息相似，該域標(biāo)識(shí)由服務(wù)器從客Server消或者鏈以便用于認(rèn)證。 必須使用合適的類型，通常是X.509。該消息也可以使客戶端得到服ServerKeyExchange消明中的組，它為客戶端提供了為繼續(xù)通信而需要的算法變量。這些值依賴于所Request消息為了認(rèn)證的目的，可以用一個(gè)可選的Request消息來向客戶端請(qǐng)求一個(gè)。它由兩個(gè)參數(shù)組成：一個(gè)參數(shù)表明可以接受的類型；二個(gè)參數(shù)表明可以接受的CA的特定名稱(DN)。該消息僅用于非服務(wù)器(沒有使用Diffie-man的服務(wù)器)。如果服務(wù)器是的，則在請(qǐng)求客戶端時(shí)會(huì)ServeroDone消服務(wù)器向客戶端發(fā)送ServeroDone消息，以表明Servero的結(jié)束，以表響應(yīng)。接收到ServeroDone消息后，客戶端應(yīng)該驗(yàn)證服務(wù)器發(fā)送的和任何鏈，應(yīng)該驗(yàn)證接收到的所有Servero參數(shù)是否是可以接受的。Client消Client消息是客戶端在接收到一個(gè)Servero消息之后可以發(fā)送的第一個(gè)消息，并且僅僅在服務(wù)器請(qǐng)求一個(gè)時(shí)才發(fā)送該消息。如果客戶端沒有一個(gè)合適的可供發(fā)送，客戶端就應(yīng)該發(fā)送一個(gè)無(no)，如果服務(wù)器要ClientKeyExchange消ServerKeyExchange消息相似，ClientKeyExchange消息允許客戶端向服務(wù)ServerKeyExchangeRSA：客戶端生成一個(gè)48字節(jié)的預(yù)主(pre-mastersecret)，它要么使用服務(wù)器中的公鑰加密，要么使用一個(gè)ServerKeyExchange中的臨時(shí)RSA密鑰加密。然后將結(jié)果發(fā)送給服務(wù)器用來計(jì)算主密鑰。臨時(shí)或者Diffie-man：客戶端向服務(wù)器提供它自己的Diffie-man的Verify消息Verify消息用于提供對(duì)客戶端的顯式認(rèn)證。它僅在具有簽名能力認(rèn)證。該消息中包含有經(jīng)客戶端私鑰簽名的預(yù)主密鑰。服務(wù)器不需要向客戶端認(rèn)證它自己。因?yàn)轭A(yù)主是使用服務(wù)器的公鑰發(fā)送給服務(wù)器的，只有合法的服務(wù)器使用相應(yīng)的私鑰才可以它。Finished的Finished消息。此時(shí)握手協(xié)議完成，雙方可以安全地傳輸應(yīng)用數(shù)據(jù)了。任何握手消息被篡改過。由于在此之前的握手消息均以明文傳輸，所以者可以方便地篡改消息里的內(nèi)容。比說，者可以修改Cliento中的加密套件，使用低強(qiáng)度的加密套件等等。Finished消息的思想是對(duì)之前所有的握手消息進(jìn)行消息摘要。通信雙方各自計(jì)算并與收到的進(jìn)行比較，如果相同，則可斷定通信沒這里值得注意就是，F(xiàn)inished消息里的只來源于“握手”消息，并不包括ChangeCipherSpec消息。而且第二條Finished消息進(jìn)行的內(nèi)容，必須是包括頭一條Finished消息。在標(biāo)準(zhǔn)的分組中，并沒有填充長(zhǎng)度字節(jié)，只記錄了填充字節(jié)的總數(shù)。例如，要8個(gè)字節(jié)，SSL是“0707070707070707”，最后一個(gè)“07”表示的是填充08080808088發(fā)送Finished消息時(shí)用剛剛協(xié)商的算法、密鑰和保護(hù)的消息。因此，通信Finished消息之后，雙方可以開始發(fā)送加密的數(shù)據(jù)。Finished消息的接結(jié)束會(huì)話和連接消息在通信結(jié)束之前，客戶端和服務(wù)器必須共享如下知識(shí):該連接將結(jié)束。這種安排可以防止可能的截?cái)啵眠@種，一個(gè)者可以試圖通過過早地結(jié)束通信來危及安全性。任何一方在關(guān)閉自己的寫會(huì)話之前，都可以通過發(fā)送一個(gè)closenotify消息來終止會(huì)話。當(dāng)收到這樣的一個(gè)警告時(shí)，另一方必須發(fā)送它自己closenotify警告并立即關(guān)閉會(huì)話，同時(shí)丟棄任何未決的寫操作。SSL連接實(shí)現(xiàn)細(xì)節(jié)上一節(jié)分析了通過OpenSSL建立SSL連接的函數(shù)接可以推斷出SSL_acceptSSL_connectSSLSSL連接客戶端實(shí)現(xiàn)細(xì)節(jié)SSL_connect()這個(gè)函數(shù)完成SSL協(xié)商的客戶端操作，該函數(shù)位于 {if(s->handshake_func==0)}華技大學(xué)華技大學(xué){ssl_clear_cipher_ctx(s);}ssl2[3]_connect()SSLv[2][3]_client_method()函數(shù)中定義的，如對(duì)于SSLv23方法，處理函數(shù)為ssl23_connect()函數(shù)，其它SSLv2和SSLv3方法分別對(duì)應(yīng)ssl2_connect()和后也是調(diào)用ssl2_connect()ssl3_connect()。掌握了服務(wù)器端的accept過程，理解客戶端的connect過程就簡(jiǎn)單了。圖 華技大學(xué)華技大學(xué)ssl23_get_server_o()函數(shù)依據(jù)客戶端握手消息確定了服務(wù)器端的SSL協(xié)SSL_connect()ssl2_connect()或ssl3_connect()，如果服務(wù)器端所采用SSL協(xié)議為SSLv2則服務(wù)器端調(diào)用ssl2_connect()，如果服務(wù)器端所采用SSL協(xié)議為SSLv3TLS則服務(wù)器端調(diào)用ssl3_connect()。這兩個(gè)函數(shù)的實(shí)現(xiàn)細(xì)節(jié)類似，在此僅分析ssl3_connect()函數(shù)。ssl3_connect()函數(shù)位于ssl下的s3_clnt.c文件中。ssl3_connect封裝客戶端實(shí)現(xiàn)SSL握手的全部細(xì)節(jié)，為了更有說服力，我們直接從源代碼中提取狀態(tài)名(如SSL_ST_CONNECT)和函數(shù)名(如ssl23_client_o)繪制如圖4.5所示的狀態(tài)圖，這里的狀態(tài)圖反映了在模式握手過程中，客戶端的狀態(tài)遷 SSL連接服務(wù)器端實(shí)現(xiàn)細(xì)節(jié)SSL_accept()函數(shù)完成SSL握手協(xié)商的服務(wù)器端操作，函數(shù)位于 if(s->handshake_func==0)SSL_set_accept_state(s);}SSLSSL_set_accept_state(s)函數(shù)初始化{ssl_clear_cipher_ctx(s);}SSLv23ssl23_accept()SSLv2和SSLv3方法分別對(duì)應(yīng)ssl2_accept()和ssl3_accept()，只是后兩者就沒有SSL協(xié)議版本協(xié)商過程了，ssl23_accept()實(shí)際在SSL協(xié)議版本協(xié)商確定后也還是調(diào)用圖 ssl23_get_client_o()函數(shù)依據(jù)客戶端握手消息確定了服務(wù)器端的SSL協(xié)議本，然后再進(jìn)SSL_accept()，實(shí)際就是調(diào)ssl2_accept()ssl3_accept()，如果客戶SSLSSLv2ssl2_accept()SSLSSLv3TLSssl3_accept()。這兩個(gè)函數(shù)的實(shí)現(xiàn)細(xì)節(jié)類似，在此僅分析ssl3_accept()函數(shù)。ssl3_accept()ssls3_srv.c文件中。ssl3_pt封裝服務(wù)器端實(shí)現(xiàn)SSL握手的全部細(xì)節(jié)，為了更有說服力，我們直接從源代碼中提取狀態(tài)名(如SS_ST_ACCEPT)和函數(shù)名(如ssl23_get_client_o)繪制如圖4.5所示的狀態(tài)圖，這里的狀態(tài)圖反映了在模式握手過程中，服務(wù)器端的狀態(tài)遷移變化。圖 密鑰生成服務(wù)器MAC寫共享密鑰：服務(wù)器在對(duì)數(shù)據(jù)進(jìn)行消息驗(yàn)證(MAC)操作時(shí)客戶端MAC寫共享密鑰：客戶端在對(duì)數(shù)據(jù)進(jìn)行消息驗(yàn)證(MAC)操作時(shí) 客戶端的寫密鑰(clientwritekey)：客戶端在對(duì)數(shù)據(jù)進(jìn)行加密時(shí)所使用的加密密鑰，此密鑰也是服務(wù)器進(jìn)行時(shí)的密鑰。初始化向量:當(dāng)用CBC方式進(jìn)行塊加密時(shí)，對(duì)于每一密鑰系統(tǒng)都將一個(gè)初始化向量(IV。此域的值是SSL握手協(xié)議進(jìn)行初始化的，為以后使用的方便此encrypted_pre_master_secretpre_master_secret則是該消息的明文內(nèi)容，48PreMasterSecret的字節(jié)串。這里加密的算法就是Servero中所選定的加密套件中的密鑰交換算法。SSLv3.0中有RSA，master_secret是從pre_master_secret中導(dǎo)出的，同為48字節(jié)。它將參與其余密ClientKeyExchange后，隨即進(jìn)行所有密鑰導(dǎo)出的計(jì)算，master_secret的計(jì)算在兩個(gè)協(xié)議中是不一樣的。SSLv3.0中的計(jì)算如下MD5(pre_master_secret+SHA('A'+pre_master_secret+Cliento.random+Servero.random))+MD5(pre_master_secret+SHA('BB'+pre_master_secret+Cliento.random+Servero.random))+MD5(pre_master_secret+SHA('CCC'+pre_master_secret+Cliento.random+Servero.random));TLSv1.0PRF(pseudo-randomfunction)的函數(shù)。PRF的定義和master_secret的計(jì)算如下：P_hash(secret,seed)=HMAC_hash(secret,A(1)+seed)HMAC_hash(secret,A(2)+seed)+HMAC_hash(secret,A(3)+seed)+...A()定義為A(0)=A(i)=HMAC_hash(secret,A(i-1)PRF(secret,label,seed)=P_MD5(S1,label+seed)⊕P_SHA-1(S2,label+seed)；master_secretPRF(pre_master_secret,mastersecret"，Cliento.random+Servero.random)[0..47]；[0..47]表示取結(jié)果的0到47字節(jié)。化向量(IV)。我們稱其整體地稱為密鑰分組(key_block)，因?yàn)閷?shí)際上，他們是被整時(shí)候采用了不同的計(jì)算。密鑰分組生成的過程如圖4.6所示。圖 一旦擁有了分組，就可按下列順序來抽取密鑰：client_write_MAC_secret、具體過程如圖4.7所示。key_blockMD5(master_secret+SHA("A"+master_secretServero.random+Cliento.random))+MD5(master_secret+SHA("BB"+master_secretServero.random+Cliento.random))+MD5(master_secret+SHA("CCC"+master_secretCliento.random))+對(duì)于標(biāo)記為可出口的加密套件，SSLv3.0final_client_write_key=MD5(client_write_keyCliento.random+Servero.random);Servero.random+Cliento.random)client_write_IV=MD5(Cliento.random+Servero.random);server_write_IV=MD5(Servero.random+Cliento.random)TLSv1.0key_block=PRF(master_secret,"keyserver_random+client_random)final_client_write_keyclient_random+server_random);final_server_write_keyclient_random+server_random);iv_block=PRF("","IVblock",SecurityParameters.client_random華技大學(xué)華技大學(xué)圖 盡管我們是在ClientKeyExchange消息之后在通信雙方進(jìn)行密鑰導(dǎo)出的整個(gè)計(jì)stateChangeCipherSpec消息時(shí)，我們會(huì)討論加密狀態(tài)的改這里值得的是，ClientKeyExchange消息是SSLv3.0與TLSv1.0之間存在消NetscapeSSLv3.0實(shí)現(xiàn)中存pre_master_secret5121024位等，在SSLv3.0規(guī)范中，得到的密文是一個(gè)變長(zhǎng)的字節(jié)串。上文曾提到，發(fā)送文的長(zhǎng)度隱含地由ClientKeyExchange消息和服務(wù)器RSA密鑰的長(zhǎng)度決定的。而TLSv1.0對(duì)其進(jìn)行了修正，發(fā)送了密文的長(zhǎng)度。一次真實(shí)的SSL連接華技大學(xué)華技大學(xué)發(fā)送的第一條消息為Cliento，其中包含了客戶端所推薦的加密參數(shù)，其中服務(wù)器以三條消息進(jìn)行響應(yīng)：首先發(fā)送選擇加密與壓縮算法的Servero,這條消息接下來服務(wù)器發(fā)送消息，其中包含服務(wù)器的公用密鑰，這里是息都將使用的剛剛商定的進(jìn)行加密的ChangeCipherSpec消息。Finish消息包含圖 交互小SSL握手在客戶端與服務(wù)器之間磋商加密算法并確立密鑰資料?？蛻舳颂峁┛捎妹荑€。pre_master_secret以服務(wù)器的公用密鑰進(jìn)行加密，而使用密鑰導(dǎo)出函數(shù)將pre_master_secret轉(zhuǎn)換為提供連接使用的加密密鑰。上關(guān)閉而實(shí)施截?cái)郤SL使用了非常簡(jiǎn)單的應(yīng)用程序接口(API)SSL的復(fù)雜處理過程對(duì)上層應(yīng)用程序透明化,而且雖然是用C編寫的,但編程思想是絕對(duì)面向?qū)ο蟮?將各種對(duì)象都完整的封裝起來,使得調(diào)用者在編程時(shí)只需考慮用其外部接口而不用考慮其SSL連接分為了深入分析SSLssldump軟件對(duì)真實(shí)的SSL連接進(jìn)行測(cè)試內(nèi)容和目的會(huì)話恢復(fù)模式：是一種能減少握手性能開銷的SSL測(cè)試環(huán)境操作系統(tǒng)：RedHatLinuxSSL客戶端：c_client程序(OpenSSL范例程序)SSL服務(wù)端：s_server程序(OpenSSL范例程序)協(xié)議分析工具：ssldump(OpenSSL自帶協(xié)議分析工具測(cè)試過程和結(jié)果分析模式SSLv3協(xié)議中默認(rèn)的認(rèn)證方式是。是只有客戶端對(duì)服務(wù)器進(jìn)行認(rèn)證，而服務(wù)器不對(duì)客戶端進(jìn)行認(rèn)證。服務(wù)器對(duì)客戶端提供自己的，該必須包含與期望的服務(wù)器的相關(guān)聯(lián)的。下面的數(shù)據(jù)顯示了一次模式中的ssldump信息我們截取了8條不到十進(jìn)制數(shù)字小數(shù)點(diǎn)后四位。下一個(gè)是表示記錄發(fā)送方向的指示：C>S 0.0134(0.0134)C>S ciphersuites20.0415(0.0280)S>CServer442737lalb8664a4c6c9fdc92560546475e37a5ff7ae342aedc252388e7ec4ffsession442737la92544fdlcf23f250a38126c1705e6f5beac26a164574c270438e6bcipherSuiteTLS_RSA_WITH_RC4_128_MD5compressionMethodNULL 0.0722(0.0306) b9bf8a109e4283bfc8b5ce6240a6e8ab7e067bdl98332a04a4b9fb7bb254ff242957819ebe35798427c945d8Ofb52b81c4865676b2a58d6b24329c3204d44530f846a272522ab43fb142fbOaeb3015flf3fe8ae33b3360d9cf033c28ce269327e4ba64a9ff1d0822f5華技大學(xué)華技大學(xué)Of3345d4ed189cOa239622f662c788 0.1497(0.0379)S>CV3.1(1) 0.3401(0.1903)S>CV3.1(32) 0.3423(0.0022)C>SV3.1(1040)application_圖 客戶端發(fā)出巧個(gè)支持的套件供服務(wù)器選擇。由于是首次連接，所以客戶端發(fā)出的Session_id為空。32字節(jié)的Session_id。同時(shí)在客戶端提供的套件中選擇TLS_RSA_WITH_RC4_128_MD5加NULL，提供自己的客戶端在ClientKeyExchange中包含一個(gè)128字節(jié)的雙向認(rèn)證模式在SSL中雙向認(rèn)證又叫客戶端認(rèn)證，這在服務(wù)器想要限制只有某些客戶端才能存取的服務(wù)是非常有用。在這里我們通過給s_serverr選項(xiàng)來實(shí)現(xiàn)，對(duì)客戶端認(rèn)證，即要求客戶端出示。只有在使用客戶端認(rèn)證的時(shí)候才需要對(duì)客戶端進(jìn)行認(rèn)證。對(duì)于其他情況，客戶端完全是的。10.0545(0.0545)C>SC>SClientoVersion3.1cipher20.1637(0.1091) 442751f4c056b056bb8ffcas8625beal714a8398ca39918a79227c2f76b7session_442751f49464cf7a33f3fl02cdfc89lade55dlOece49Od66cle058a87411fccipherSuiteTLS_RSA_WITH_RC4_128_MD5_types_types_307831Ob300906035504061302434e.Of30Od06035504 e58311030Oe0603550407130754616959616e3112301006035504Oa13094564636174696f6e3125302306035504Oblc436f6d707574657220616e642053667477617265205363686f6f6c31Ob090603550403130243 30.5563(0.3925)b9bf8a109e4283bfc8b5ce6240a6e812cea893if3618la29ee05fc26942d1744633147658c0056ab2777513aOebebd608504e8ef7d845ala4d6561085a6dOd2aOd41418976e434alc772al2047908dff42ead05082d7455bacd505Idb5153e6fb82e88e247ec518a3bc0Oe7505a206bb791681ad8c295ca9a9f941.0199(0.4636) 162759a92d0463ef8898acbd4da283bbelObf95f45e0d701lb25004b89c2a4c4d07ad53d01aeOad52b09dla64fd2bf8e4bf92b94d7b8da3e816dleOd3e75eb0379f29b0bb45e64ff2905d8914129b5719dl9046do9311do729a436bd9deba40Oc64Oaa51690cf9f4d5e4aca36118108c47781719f1e655dbbofcde61.0204(0.0004)1.0385(0.0180)C>S1.0403(0.0018)1.1648(0.1245)101.4237(1.4237)S>CTCP111.4318(0.2608)S>Capplication證多出三條信息:Request和客戶端發(fā)送用于傳送的消息以及對(duì)自身進(jìn)行認(rèn)證的Verify消息。如上所示，Request消息指示服受的簽名算法，在上面的信息中Request指示了rsasign、dss_sign兩種方式。authorities列表是服務(wù)器列出的自己信任的認(rèn)證機(jī)構(gòu)。圖 客戶端發(fā)送消息含有客戶端的。Verify完成客戶端的實(shí)所含公鑰來驗(yàn)證客戶端聲稱實(shí)體的。會(huì)話恢復(fù)模式SSLSSL會(huì)話是在SSL協(xié)議，這種連接是對(duì)等的、暫時(shí)的，每個(gè)SSL在握手期間的開銷非常巨大[36]。為了減少這種開銷并提高性能，客戶端和如果在Cliento和Servero過程中可以確定協(xié)議的客戶端和服務(wù)器所共享的一ID的話，就可以跳過整個(gè)握手階段而直接進(jìn)行數(shù)據(jù)傳輸，同時(shí)在密鑰生成過程可以重用先前的master_secret。懷疑該會(huì)話有可能已經(jīng)或可能已經(jīng)過期或被吊銷，則應(yīng)該強(qiáng)行進(jìn)行一個(gè)完整的握手過程。因?yàn)橐粋€(gè)獲得主密鑰(master_secret)的者知道相應(yīng)的session_idSSLsession_id的生存周期不24小時(shí)，同時(shí)不應(yīng)該把session_id寫入磁盤里。10.0136(0.0136) 4427536d344807a6be029802Oc46c26e9181cca9fbd8049026e2b86c2115resume442751f49464cf7a33f3fl02cdfc89lade55dlOece49Od66c1e058a87411fcciphersuites20.1877(0.1740) 4427520435e28bc24fee4e05lb18b4f0fl81Od64b1c88b9cfl623e731dfefcd3session_442751f49464cf7a33f3fl02cdfc89lade55dlOece49Od66c1e058a87411fccipherSuiteTLS_RSA_WITH_RC4_128_MD50.3380(0.1502)S>C0.3380(0.0000)S>C0.3452(0.0072)C>S0.3545(0.0093)C>S0.3555(0.0010)C>Sapplication-圖 接中在服務(wù)器的Servero信息中的session_id[32]=442751f49464cf7a33f3fl02cdfc89lade55dlOece49Od66c1e058a87411而在本次連接中的Cliento也包含如下idresume[32]=442751f49464cf7a33f3fl02cdfc8914lade55dlOece49Od66c1e058a87411華技大學(xué)華技大學(xué)會(huì)話恢復(fù)是通過Cliento和Servero的session_id字段來實(shí)現(xiàn)的。在客戶端和服務(wù)器執(zhí)行初始握手期間，由于客戶端沒有緩存任何會(huì)話，所以session_id字如果服務(wù)器愿意恢復(fù)這個(gè)會(huì)話，它就在Servero中使用相同的session_id予以回應(yīng)，然后再跳過其他的過程發(fā)送一條ChangeCipherSpec消息。使用的master_secretkey_block，這樣所有的密鑰均小本小節(jié)主要就、雙向認(rèn)證、會(huì)話恢復(fù)這三種模式的SSL連接的輸出進(jìn)行了討論。依據(jù)ssldump到的信息，我們重點(diǎn)分析了這三種模式SSL連接建立結(jié)束語工作總結(jié)SSL的研究工作遠(yuǎn)遠(yuǎn)不像對(duì)當(dāng)前流行的編程技術(shù)和平臺(tái)的研究和討論一樣普遍和為人所關(guān)注，例如J2EE或者.Net[39]。從我們看到的書籍、文章或者中可以看出，即使人們討論SSL協(xié)議，的注意力是放在怎樣在工程上應(yīng)用它們來編程、保障通信安全，而不是針對(duì)SSL協(xié)議的本身。而本文的工作是研究和分析SSL與TLS協(xié)議的本身，關(guān)注其的通信過程、消息結(jié)構(gòu)和作用。門和，畢竟SSL協(xié)議的制定者OpenSSL軟件的編寫者都不是國人。目前，我國、軍等眾多部門和單位的網(wǎng)絡(luò)建設(shè)信息交流與的，而我國計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)研究和技術(shù)防范相對(duì)滯后，技術(shù)安全方面的壓力越來越大[40]。為了緩解這一現(xiàn)狀，我們有必要從源碼深入分析SSLSSL連接建立的過程，主要從三個(gè)層次去分析驗(yàn)證這一過程的安理論分析：探討了SSL連接建立的理論，重點(diǎn)分析了SSL握手過程，為后續(xù)源碼分析：以O(shè)penSSL版本0.9.8.e為基礎(chǔ)，以SSL_accept和消息分析：通過ssldump軟件SSL連接建立過程中的協(xié)議消息，分SSL握手在客戶端與服務(wù)器之間磋商加密算法并確立密鑰資料?？蛻舳颂峁┛捎妹荑€。pre_master_secret以服務(wù)器的公用密鑰進(jìn)行加密，而使用密鑰導(dǎo)出函數(shù)將pre_master_secret轉(zhuǎn)換為提供連接使用的加密密鑰。消息的消息，從而者對(duì)握手進(jìn)行篡改SSL協(xié)議的所有安全都依賴于master_secret的。如果某個(gè)會(huì)話的pre_master_secretKDF生成。而客戶master_secret之前交換的，所以在握手過程中它們必定是以明文傳輸。因此唯一一條用來產(chǎn)生master_secret的信息就是進(jìn)一步的工作SSL與TLS幾乎不能脫離而存在。的實(shí)際上是一個(gè)字節(jié)串。但如何把這一個(gè)字節(jié)串分解成為里的各種字段，是往后值得研究的一個(gè)方面。X.509第三版定義了很多標(biāo)準(zhǔn)的擴(kuò)展，這些擴(kuò)展是什么，含義是什么，如何使用，也是很值得研究的。的驗(yàn)證也是一個(gè)重要的環(huán)節(jié)。最后就是的撤銷。這里面涉及的內(nèi)容，包含撤銷列表(CRL，RevocationList)，如何獲得SSL所涉及到的應(yīng)用和相關(guān)的技術(shù)領(lǐng)域非常廣泛，而其本身也有很多可以深入兩年的生活是我一生中難忘的經(jīng)歷，在此期間，在敬愛的導(dǎo)師覃中平教授的精