SSL安全協(xié)議(中文版)

/SSL協(xié)議Ｖersion3.03／４／96 翻譯—隋立穎一本文件的地位本文件是一個Iｎtｅrnｅｔ草案。Internet草案是Ｉｎterneｔ工程特遣組(ITEF)及其領域和工作組的工作文件.請注意,其他團體也可以發(fā)布Internｅt草案.Interｎｅt草案自公布之日起至多六個月內(nèi)有效。它可以隨時被修改、被替換，或被其他文件所覆蓋。把Ｉnterneｔ草案作為文獻來引用，除說明是“正在進展中的工作”以外，是不合適的。要了解任何一個Internｅt的當前地位,請查閱如下網(wǎng)址：(美國東海岸），(歐洲），（美國東海岸）以及munnａri。oz.au(環(huán)太平洋地區(qū)）。其中InterneｔDｒaｆtsShａdoｗDirectoriｅs目錄下的1id—aｂsｔracｔ.txt列表可提供這方面的信息。二摘要本文制定了安全套接層協(xié)議第3。0版(ＳSL3．0）規(guī)范.SＳL是一個提供Inｔernet上的通信隱私性的安全協(xié)議.該協(xié)議允許客戶端/服務器應用之間進行防竊聽、消息篡改及消息偽造的安全的通訊。三簡介制定ＳSL協(xié)議的初衷是為通訊雙方提供安全可靠的通訊服務，協(xié)議包含兩個層次：其較低的SSL記錄層協(xié)議位于某一可靠的傳輸協(xié)議（例如TCＰ[TCP］協(xié)議）之上;ＳSL記錄層協(xié)議用來對其上層的協(xié)議進行封裝。握手協(xié)議就在這些被封裝的上層協(xié)議之中,它允許客戶端和服務器彼此認證對方；并且在應用協(xié)議發(fā)出或收到第一個數(shù)據(jù)之前協(xié)商加密算法和加密密鑰。這樣作的原因是保證了應用協(xié)議的獨立性,使低級協(xié)議對高級協(xié)議是透明的。SSL協(xié)議提供的連接安全性具有以下三條屬性連接是安全的。在初始化握手協(xié)議協(xié)商加密密鑰之后傳輸?shù)南⒕鶠榧用艿南?加密的算法為單鑰加密算法(例如DES［DES]，ＲC4[RC４］等）。對方的身份是可以通過非對稱加密算法—即公鑰加密算法（例如RSA［ＲSＡ］,DＳＳ[ＤSS]等）來驗證.連接是可靠的。所傳輸?shù)南⒕焕煤灻借€加密的消息文摘(MAC）,以保證消息的完整性。安全雜湊(hａｓｈ)函數(shù)(例如SHA,ＭＤ5等）被用來產(chǎn)生消息文摘（MＡC）.四目標按它們的優(yōu)先級，SSL協(xié)議3.０的目標是在通訊雙方之間利用加密的SＳL消息建立安全的連接?；ゲ僮餍?。通訊雙方的程序是獨立的,即一方可以在不知道對方程序編碼的情況下利用SSL３.0成功的交換加密參數(shù).注意:并不是所有的SＳL的實例（甚至在同一應用程序內(nèi)）都可以成功的連接.例如,如果服務器支持一特定的硬件令牌(token）,而客戶端不能訪問此令牌，則連接不會成功?？蓴U展性。SSL尋求提供一種框架結(jié)構(gòu),在此框架結(jié)構(gòu)中,在不對協(xié)議進行大的修改的情況下，新的公鑰算法和單鑰算法可以在必要時被加入.這樣做還可以實現(xiàn)兩個子目標避免產(chǎn)生新協(xié)議的需要，因而進一步避免了產(chǎn)生新的不足的可能性。避免了實現(xiàn)一完整的安全協(xié)議的需要.相對的有效性。加密操作,尤其是公鑰加密，對CPＵ來說是一種很耗時的事,因此SSL協(xié)議引入一可選的對話緩存（CACHE）來減少從頭開始的連接的數(shù)目。同時，它還注意減少網(wǎng)絡的活動。五此文檔的目的SSL協(xié)議版本３。0詳細說明書的主要讀者是要實現(xiàn)此協(xié)議的人和進行加密分析的人。此詳細說明書主要是為這兩類人而寫的，所以它時刻注意反映這兩類人的需要。因此在本詳細說明書中(而不是寫在附錄中)以文本方式包含了許多與算法相關的數(shù)據(jù)結(jié)構(gòu)和規(guī)則,使它們易于被訪問.雖然本詳細說明書包含了維護物理安全性所必須的策略，本詳細說明書并不想提供關于服務和界面的定義.六描述語言（Ｐｒeseｎtationlaｎgｕａge）本文檔主要是描述外部表示（externalｒepreseｎtation)的數(shù)據(jù)的格式,所以用到了下列簡單、基礎而有點隨意的定義的表示語法，這些語法在結(jié)構(gòu)上來自不同的出處。雖然這些語法在結(jié)構(gòu)上有點象程序設計語言C、在語法和目標上象XDR［XDR］，但過分的強調(diào)這種類似是有害的。本描述語言的目的僅僅是描述SＳL.６.1基本塊長（Bａｓｉcblocksｉze)所有的數(shù)據(jù)項的表示均是顯式說明的,基本數(shù)據(jù)塊的長度為一字節(jié)(也就是說8比特）多字節(jié)的數(shù)據(jù)項是由從上至下、從左至右的多個字節(jié)連接組成。從字節(jié)流的角度來看,一多字節(jié)的數(shù)據(jù)項(在本例中是一數(shù)字)是通過下述公式形成的：ｖalue=（bｙｔｅ[0]〈〈８＊（n-1))|（byte[1］<＜8*(n-2))｜。。。|byte[n—1］；這種字節(jié)的順序關系是網(wǎng)絡中常用的順序關系即大ｅndｉａn格式.6。2雜項注釋以“/＊"開始，以“＊/”結(jié)束?？蛇x的部分是由將其包含進斜體的括號“[］”中而指定的。單字節(jié)的包含不可解釋的數(shù)據(jù)的實體的類型為ｏpaqｕe6.3向量(Vectｏrs)向量(一維數(shù)組）是一同類型的數(shù)據(jù)元素的流,向量的規(guī)模可以在編寫文檔時說明，也可以留至運行時才指明;不管在哪一種情況下，向量的規(guī)模(即大?。┦怯上蛄恐凶止?jié)的個數(shù)而不是向量中元素的個數(shù)決定的.說明一新類型Ｔ'是一固定長度的類型T的向量的語法為：ＴＴ＇［n］；在這里，T’在數(shù)據(jù)流中占n比特，其中n是Ｔ的所占字節(jié)數(shù)的倍數(shù)。向量中包含數(shù)據(jù)元素的個數(shù)沒有包含在數(shù)據(jù)流之中。在下例中,Datum被定義為三個連續(xù)的協(xié)議無法解釋的字節(jié)的向量；而Daｔa被定義為三個連續(xù)的Ｄａt(yī)ｕm,一共包含9個字節(jié)opaｑueDatuｍ［３]；/*三個協(xié)議無法解釋的字節(jié)＊/DatumDａt(yī)a[9］；/*三個連續(xù)的包含三個字節(jié)的向量*/可變長向量可以通過指明合法長度的范圍，即形如＜最小長度.．最大長度>的形式來定義，在編碼時，在字節(jié)流中實際長度應在向量的內(nèi)容之前,此實際長度是以數(shù)字的形式存儲的，此數(shù)字應能表示此向量的最大長度（ceilinglengtｈ）?？障蛄恐傅氖且粚嶋H長度為零的向量。ＴＴ＇<flｏor．．ceｉling〉；在下例中，mａndatｏｒy是一必須包含300到４00字節(jié)的oｐaｑue類型數(shù)據(jù)的向量,它不能是空向量，其實際長度域占有兩個字節(jié)，即ｕiｎt16，足以表示400(見6。4節(jié)），而longer最多能表示800個字節(jié)，即４00個ｕiｎt１6的數(shù)據(jù)元素,且〈請合法使用軟件>可以是空向量。它的編碼包含一兩字節(jié)的實際長度域。ｏpaquemａｎｄａt(yī)orｙ〈30０.。400>；/＊長度域為兩個字節(jié)，不能為空向量＊／uint16lｏngｅr<0。．８00〉;/*零至400個１6比特的無符號整數(shù)＊／6.4數(shù)字（Ｎumbｅrs）基本的數(shù)字的數(shù)據(jù)類型是無符號字節(jié)(uint8）.其他所有的大的數(shù)字均是由6.1節(jié)中描述的固定長度的字節(jié)流連接而成,且它們均是無符號的。下列數(shù)字類型是預定義的:uｉnｔ8ｕiｎt１6［2］；ｕint8uinｔ24［3］；ｕｉｎt8uｉnt32[4]；uinｔ８uint64[8］；6.5枚舉（Eｎuｍeratｅ）另一類稀疏的數(shù)據(jù)類型是枚舉(enｕm），枚舉類型的數(shù)據(jù)的取值范圍只能是在其定義是聲明的值。每一次定義均定義了一不同的類型。只有相同類型的枚舉數(shù)據(jù)才可以相互賦值和比較,枚舉類型的每個枚舉元素均必須象下例中所示的那樣，被賦一個值。由于枚舉類型這的元素是沒有順序的,所以它們可以取任意順序的不同的值。ｅnuｍ｛e1（v1）,e2（v２）,...，en(vn)，[（n)］｝Ｔｅ；枚舉類型的值在字節(jié)流中占據(jù)的空間的大小是其定義的取值范圍中最大的可能值所占的空間大小。下列定義會使類型Color占有一個字節(jié).ｅnｕm{red（3）,blue（５），ｗhiｔｅ（7)｝Cｏlｏr;你還可以通過指定一個無標簽的值來強制枚舉類型所占的字節(jié)數(shù)，這樣就不需定義一冗余元素了。在下例中,類型Tasｔｅ在字節(jié)流中占兩個字節(jié)但只能在１,2或４中取值。ｅnum{sweet(１），ｓour（2）,bitter(４），（３2０00)｝Tａｓｔe;枚舉類型的元素的名字只在定義的類型中是有效的。在第一個例子中,對類型Colｏr中的第二個元素的完全限定引用為Cｏlor.ｂluｅ。這樣的限定當賦值的目標是被說明的時候時是可以忽略的。Cｏlorcｏlor＝Coloｒ。ｂlue;/＊重復說明,但是合法的＊/Coloｒcoloｒ=ｂlｕｅ;／＊正確，類型是隱含的＊/對于元素的值不會轉(zhuǎn)化為外部表示的枚舉類型，元素的取值信息是可以省略的。enum｛low，mｅｄium，ｈiｇh}Ａｍount;6。6結(jié)構(gòu)(Constructedtype）結(jié)構(gòu)類型可以由基本的數(shù)據(jù)類型方便的建成，每一次說明均聲明了一新的、唯一的類型，定義的語法類似于C語言中結(jié)構(gòu)的定義。sｔｒuct{Ｔ１ｆ1；T2ｆ2；.。.Tnfn;}［T］;在一結(jié)構(gòu)中的各域可以象枚舉中引用元素時的語法一樣用類型名加域名引用，例如Ｔ.ｆ2引用的是上例中的第二個域，結(jié)構(gòu)的定義可以嵌套。6．6．1變體結(jié)構(gòu)(Variant)定義結(jié)構(gòu)時可能根據(jù)環(huán)境的不同而有不同的變體,選擇器必須為枚舉類型的數(shù)據(jù),以定義結(jié)構(gòu)中可能的變體，且必須用case語句將ｓelｅct中聲明的每個枚舉元素不會起來。變體結(jié)構(gòu)的結(jié)構(gòu)體可以有一供其引用的標簽.在運行時如何決定變體的機制并沒有在描述語言中規(guī)定。stｒuct｛Ｔ1f1;T2ｆ2;。．。Tnｆn;select(Ｅ){ｃasｅe１:Te1；cａsee２:Tｅ2;.。.．casｅｅn：Ｔｅn;｝[fｖ]；｝［Ｔｖ］；例如：eｎｕm{ａｐple,oｒange}VariaｎｔＴaｇ;sｔruct{uiｎt16numbｅr;ｏpaquestｒing<0.．10＞;/＊可變的長度＊/｝Ｖ1;ｓtruct{uiｎt32numｂer；opaqｕestｒｉnｇ[1０]；/＊固定的長度＊／}V２;struｃｔ{selｅct（VａrｉanｔＴag）｛／*變體的選擇器是隱含的*/cａseａppｌe：V1；/*VaｒiantBody的定義,標簽＝ａｐpｌe*/casｅｏranｇｅ:V2；／*VariaｎｔBody的定義，標簽=orange*／}vａrｉant_body；/*可選的變體標簽*/｝VarｉaｎtRecoｒd；變體結(jié)構(gòu)可以通過在類型前指定選擇器的值來限定（ｎａrroweｄ)，例如：orａｎｇeＶａrianｔRｅcｏrd是類型ＶarｉantＲecoｒd的一限定，它包含類型為Ｖ2的vａriａnt_body。６．７加密屬性(Ｃｒyptｏgraphｉcａt(yī)tｒibute）數(shù)字簽名、流加密、塊加密和公鑰加密這四項加密操作的加密屬性分別為dｉgｉｔally－ｓigｎeｄ,sｔreａm—cｉphered,ｂlocｋ—cipheｒed和puｂlic-ｋeｙ－ｅncryptｅd.對一個域進行何種加密操作是由在此域的類型說明前的合適的加密屬性（關鍵字）決定的，加密的密鑰是由當前對話狀態(tài)字隱含給出的(見7.1節(jié)）。在數(shù)字簽名中，輸入為一單向哈希函數(shù)（ｏne—wayhａshｆunction）。當用RSA算法進行簽名時，用簽名私鑰對一３6字節(jié)的結(jié)構(gòu)進行簽名,此36字節(jié)的結(jié)構(gòu)是由兩個哈希函數(shù)生成的，一個為ＳＨA,另一個是MD5.當用DSＳ算法進行簽名時，可以直接對由SHA哈希函數(shù)生成的20字節(jié)的結(jié)構(gòu)進行簽名。在流加密中，明文的長度與由密鑰產(chǎn)生的密文的長度是相同的。此密鑰是由偽隨機數(shù)發(fā)生器生成的安全的密鑰，是根據(jù)時間的變化而變化的。在塊加密中，密文的每一塊均被加密成一塊密文。由于明文的長度并不是固定的，所以有可能在對明文(發(fā)出的數(shù)據(jù)）分塊時產(chǎn)生一不滿的塊（塊的長度通常為64比特），此時就需要將此不滿的塊的剩余部分填充數(shù)據(jù)，一般來說是填零.在公鑰加密中，單向限門函數(shù)被用來加密要發(fā)出的數(shù)據(jù),用一給定公鑰加密的數(shù)據(jù)僅能由相應的私鑰解出，同樣用一給定私鑰加密的數(shù)據(jù)僅能由相應的公鑰解出。在下例中：strｅam—cｉpherｅdstｒｕct｛uｉnt8fielｄ１；uｉnt8field2；ｄigｉｔａllｙ－signedopａquehaｓh［２0]；｝UsｅrType；哈希函數(shù)的結(jié)果做為簽名算法的輸入，整個結(jié)構(gòu)ＵserＴｙpe用流加密進行加密.6．８常量(Cｏｎstant）有類型的常量可以通過在常量名前加上所希望的類型，并在常量名后給其賦上所期待的值來定義.未限定的類型（opaque，可變長向量,變體結(jié)構(gòu)及帶有opａｑue的結(jié)構(gòu)）不能被賦值。多元素的結(jié)構(gòu)和向量的所有域均應被賦值。例如:sｔｒuct｛uｉnt8f1;uiｎt８f2;｝Exａmｐｌｅ1;Eｘampｌｅ１eｘ1=｛1，4｝;/＊令f１=１,f２=４*/七、SＳＬ協(xié)議ＳSＬ是一層次化協(xié)議。在每一層，消息均可以包含描述長度、消息的描述及消息的內(nèi)容的域.SSＬ在傳輸消息時，首先將消息分為其可處理的數(shù)據(jù)塊,可以進行壓縮,將其封裝為一帶消息驗證（ＭAＣ）的包，隨之進行加密并傳輸所得到的加密后的消息.在收到消息時,首先解密,然后驗證、解壓縮并重新組合得到原有的消息,將此消息發(fā)向較高的層次。7．1對話及連接狀態(tài)SSL的對話是有狀態(tài)的，是由SSＬ的握手協(xié)議來同步客戶端和服務器的狀態(tài)的，因而允許它們一致的操作而不管它們的協(xié)議狀態(tài)是否是并行的。從邏輯上講，狀態(tài)被提到了兩次，一次是當前的操作狀態(tài)，而另一次是在握手協(xié)議中的未決狀態(tài)。而且,還維持單獨的讀狀態(tài)和寫狀態(tài)。當客戶端或服務器收到cｈangeｃiｐherspec消息時,它將未決讀狀態(tài)復制到當前讀狀態(tài).當客戶端或服務器發(fā)出changeｃiｐherspec消息時，它將未決寫狀態(tài)復制到當前寫狀態(tài)。當握手協(xié)商完畢時,客戶端或服務器將彼此交換ｃhaｎgecｉphｅrspeｃ消息（見7.３節(jié))，這樣它們就可以用新同意的ciｐｈerspec來進行通信了。SSＬ對話可以包含若干次安全連接，而且每一方均可以同時有多個對話.對話狀態(tài)包含下列元素：對話標識一由服務器為標識當前活躍的對話或重新開始的對話而隨機選取的字節(jié)流.對等證書對等方的X509。ｖ３[Ｘ５09］證書,狀態(tài)的此元素可以為空。壓縮方法在加密之前壓縮數(shù)據(jù)所采用的算法。加密說明指出所采用的數(shù)據(jù)加密算法(如沒有采用加密算法，采用ＤＥS等)和作消息文摘的算法（如MD5，SHA等），它還定義象hａsh_sｉze一類的加密的屬性（見附錄A。7）主共享的秘密客戶端和服務器所共享的48比特的共享的秘密.是否可以重開始一標識此對話是否可以用來初始化新的連接的標志。連接狀態(tài)包含下列元素:客戶端和服務器的隨機數(shù)由客戶端和服務器為建立一次連接而隨機選取的一字節(jié)流.服務器的MAC寫共享秘密服務器在對數(shù)據(jù)進行消息驗證（MAC）操作時所使用的共享的秘密.客戶端的MＡC寫共享秘密客戶端在對數(shù)據(jù)進行消息驗證(MAＣ)操作時所使用的共享的秘密。服務器的寫密鑰服務器在對數(shù)據(jù)進行加密時所使用的加密密鑰，此密鑰也是客戶端進行解密時的解密密鑰?？蛻舳说膶懨荑€客戶端在對數(shù)據(jù)進行加密時所使用的加密密鑰，此密鑰也是服務器進行解密時的解密密鑰。初始化向量當用ＣBC方式進行塊加密時，對于每一密鑰系統(tǒng)都將維護一初始化向量（IV）。此域的值是由SSL握手協(xié)議進行初始化的，為以后使用的方便此后的每一記錄的最終的密文塊被保存在記錄的后面。序列號參與連接的每一方都為其發(fā)出的和收到的消息維護一獨立的序列號。當一方發(fā)出或收到ＣhangeCiｐhｅrspｅｃ消息時,其序列號置為零。序列號的類型為Uｎit64,所以序列號不能超過264－1。7.2記錄層SＳＬ記錄層由更高的層次那里接收未加解釋的任意長度的非空塊。７。２．１打包記錄層將信息塊分裂為小于或等于214字節(jié)的SSLPｌainＴexｔ記錄。客戶端消息的界限并不反映至記錄層中（也就是說,具有同樣ContenｔTｙｐe的多個客戶消息可能會合并為一SＳLPlaｉntext記錄）。stｒuct｛ｕint8major,minor；｝PrｏtoｃoｌVｅｒsion；enｕｍ{ｃhaｎge_cipｈer_sｐec(2０),aｌert(２1）,ｈandshake(22），ａppｌｉcａｔiｏn＿dａt(yī)a（23)，（25５）｝CｏｎtenｔＴype；stｒｕct{ＣｏntentTypetype；PrｏｔｏcolVｅrsionｖｅrsioｎ；ｕint１6leｎｇｔh;opaquｅfrａgmenｔ［SSLＰl(wèi)ａｉntext．lｅngｔh]；｝SSLPlainteｘt；其中tｙpe指出采用打包的更高層次的協(xié)議.versｉoｎ協(xié)議的版本號。此文檔所描述的是SSL版本3．０（見附錄A.１。１）．lenｇthSＳLPlａｉｎtｅxｔ的字節(jié)長度，此長度不應超過21４frａｇmeｎt應用數(shù)據(jù)。此數(shù)據(jù)對由Type域中所指出的更高層次的協(xié)議是透明的,并被視為一獨立的塊。注意：不同的SSL記錄層的CenteｎtＴypｅ數(shù)據(jù)可以交叉存取,應用數(shù)據(jù)一般要比其他的ＣontenｔTypｅ數(shù)據(jù)要求更低級的傳輸過程。７.2。２記錄的壓縮和解壓縮所有的記錄均應用在當前的對話狀態(tài)中定義的壓縮算法進行壓縮.一般地，此算法為當前活躍的壓縮算法，但在初始化時它被定義成ＣomprｅssioｎMethｏd。null。壓縮算法將ＳＳLPlaｉnteｘt結(jié)構(gòu)轉(zhuǎn)換為SＳLＣoｍｐreｓsｅｄ結(jié)構(gòu)，當ＣiｐherSｐec變換后,壓縮函數(shù)將刪除其狀態(tài)信息。注意：ＣiｐｈerSpeｃ是在7．１節(jié)中所描述的對話狀態(tài)的一部分，對CｉpherSpｅc中各域的引用在本文檔中是用表示語法來表達的。關于CipherSpｅc的更加詳細的描述見附錄A.7.壓縮必須是無損壓縮且對原文的長度的增加不超過1024比特.如果解壓縮函數(shù)遇到一待解的超過214比特的SSLComprｅsｓed．fragｍｅnｔ,它將產(chǎn)生一終止的decｏｍprｅssioｎ_failuｒe報警（見7.4.2節(jié))。struct｛CoｎtｅｎtTｙpeｔype;／*sameasSＳLPlainｔext。tyｐe*／ProtocoｌVersionversｉon;/*sameasSSLPlaｉntｅxt。versioｎ＊/uint16length；ｏｐaqｕefragmenｔ[SＳLCｏmpreｓsed.lengtｈ］；}SSLCｏmpressed;ｌengtｈSSLComprｅｓsed。ｆragment的長度（單位:字節(jié)）。長度不應超過214+１０２4.fraｇmenｔSＳＬPｌaintext．ｆragmｅnt的壓縮格式。注意：操作CｏmpresｓionMetｈod.nuｌl是一標識性操作，沒有任何一個域的值被改變(見附錄Ａ。4.1). 實現(xiàn)時請注意：解壓縮函數(shù)的責任是保證消息不會造成內(nèi)部的緩沖區(qū)溢出。7．2。3記錄的有效負荷保護和加密說明（ＣipｈｅrSｐec）所有的記錄均用在當前的加密說明（CipherSpｅｃ)中定義的加密算法和消息驗證(ＭAＣ)算法所保護,一般地,在SSL內(nèi)部有一活躍的ＣipheｒSpeｃ,但在初始化時,它的值為SSＬ_NULL_WITH＿NＵLＬ_NULL,從值并不提供任何安全性.只有當握手結(jié)束后，參與雙方共享一用于加密記錄和計算消息驗證碼（MACｓ）的公共秘密。進行加密和消息驗證（MAC）操作的技術有CｉｐheｒSpec定義,并受CiｐｈerSｐec。ｃiｐｈer_ｔｙpe的限制。加密和消息驗證（MAC）函數(shù)將一SSLCompresｓed結(jié)構(gòu)轉(zhuǎn)換為一SSLCｉpｈｅrtext結(jié)構(gòu)，解密函數(shù)作相反的過程。傳輸時將包含一序列號，這樣當包丟失、被改變或包被重復收到時可以及時的發(fā)現(xiàn)。ｓtｒuct｛ＣontentＴypeｔype；PrｏｔocolVersionversioｎ;uint16leｎgtｈ；seleｃｔ（CiｐｈｅrSｐec．cipher_ｔｙpｅ）｛casｅstrｅam：GｅnｅrｉcSｔreamCipher;casｅblｏｃk:GeｎeｒicBlockCiｐher；}frａgment；｝SSＬCｉｐhｅrｔｅxt；ｔyｐe類型域被指定為SSLＣｏmpresｓed。type。versiｏn版本域被指定為SSLＣomｐrｅsｓeｄ。vｅｒsion。lenｇtｈ指明隨后的ＳSLCｉphertext.frａgmｅnt的長度(單位：字節(jié))。長度不應超過214+204８。fragmｅnt包含消息驗證碼（MAＣ）的SＳLCｏmｐｒessｅｄ.fraｇmｅnt加密后的形式。７.2。3.1Ｎull或標準的流加密流加密(包含ＢulkCipheｒAlgorithｍ.ｎｕlｌ–見附錄A.7）將SSLCｏmpressed.ｆragment結(jié)構(gòu)轉(zhuǎn)換為ＳSLCipherteｘt．fragmeｎt流結(jié)構(gòu)，或者反之,將ＳSＬCipｈerｔeｘt。fragment結(jié)構(gòu)轉(zhuǎn)換為SSＬComｐrｅsｓed.fragｍeｎｔ流結(jié)構(gòu)。stream-cipｈeredstruct{ｏpaquecｏｎtent[SＳＬＣompｒessed。lenｇth］；opａqueMAC［CiphｅrSpec.hash_ｓize]；｝ＧenerｉcStrｅamCiphｅr;產(chǎn)生的消息驗證碼(MAＣ）形式為：ｈash(ＭAＣ_wｒitｅ_secreｔ+pad_2＋hash（MAC_ｗrite_seｃｒｅt+ｐaｄ_１+seq＿num+lｅnｇth+cｏｎtｅｎt)）；其中“+"表示將前后連接起來.paｄ_1字符０x3６在MD5算法中重復48次或在SHA算法中重復40次。pａｄ_2字符0x5c，與ｐad＿1一樣的重復。ｓｅｑ_num從消息的序列號。hash由cipher組合所決定的雜湊算法.請注意,消息驗證碼(MAＣ）在加密之前就計算出來了。流加密加密的是包含消息驗證碼（MAC）在內(nèi)的整個塊。對于不用同步向量的流加密方法（如RC4),在記錄后邊的流加密方法的狀態(tài)被簡單的用在隨后的包中,若CipｈｅrSuite是SSL_ＮＵLL＿WITH＿NULＬ_NULL，且加密包含指定的操作(也就是說,數(shù)據(jù)還未被加密且消息驗證碼（MAC)的長度為零，標志著不使用消息驗證碼（ＭAＣ）），則SSＬＣipｈertext的長度是SSＬＣoｍprｅsｓeｄ的長度與ＣｉpheｒＳpｅｃ．haｓh_size的和。7。２．3．2密碼分組鏈接（CＢC)塊加密對于塊加密(象ＲC2或DES)，加密和消息驗證(MAC)函數(shù)將ＳＳＬCｏmpｒｅssed．fraｇｍent結(jié)構(gòu)轉(zhuǎn)換成ＳＳＬCipheｒtexｔ。ｆｒagｍｅnt塊結(jié)構(gòu).ｂlock-ｃｉpheredｓｔruct｛opaqueｃontenｔ［SSLＣｏｍｐresｓeｄ.length];oｐａqueＭAＣ[CipherSpec.hash_siｚe］;uint8padding[ＧｅneｒicBloｃkＣipher。ｐadding_ｌｅngth］；ｕiｎｔ8ｐaｄdiｎg_lｅnｇtｈ；}GenericBlocｋCiｐheｒ；消息驗證（MAC）與7．2。3。１節(jié)中描述的一樣。ｐaddinｇ為了使明文的長度成為加密塊長度的倍數(shù)而添加的隨機字節(jié)。paddiｎｇ＿lｅngth填料的長度必須比加密塊的長度小且可以為零，填料的長度應使結(jié)構(gòu)GenｅricBlockCipher的總長度是加密塊長度的倍數(shù)被加密的數(shù)據(jù)長度（SSＬＣipｈerｔexｔ．length）應比SＳＬCｏmpressed的長度,CiphｅrSpeｃ。hash_ｓiｚe和填料的長度的總和多一。注意：對于CＢC塊加密來說,其第一個記錄的ＣBC塊鏈的初始化向量（IV）是由握手協(xié)議提供的，隨后記錄的IV是前一記錄的最后一密文塊。7。3更改加密說明ciｐhｅｒspec的協(xié)議更改加密說明（ｃipherｓpec）的協(xié)議在加密策略中被用來通知參與各方這一改變。協(xié)議只包含一個在當前（不是未決的）CiphｅrSpec下加密并壓縮過的消息.此消息包含一個字節(jié),其值為1。struｃt{eｎuｍ{ｃhangｅ_ciｐｈeｒ_sｐec（1），（25５）｝type；}ChaｎgeＣipherＳpec;更改ciphｅrspeｃ的消息可以由客戶端或服務器發(fā)出來通知對方隨后的記錄將由剛協(xié)商好的CipherSpｅc和密鑰來保護.收方收到此消息后,將讀未決狀態(tài)復制到當前讀狀態(tài)中。客戶端在密鑰交換握手和證書驗證消息(如果有的話）之后發(fā)出更改cｉpherspec的消息，服務器則在成功的處理了客戶端發(fā)來的密鑰交換消息之后發(fā)出一更改ｃipherspｅc的消息。一意外的更改cipherspec消息應產(chǎn)生一ｕｎexpecteｄ_mｅssａgｅ報警(見7。4。２節(jié))。當重新開始一原有的對話時,更改ｃｉｐherspec消息應在問候消息（hｅｌlｏｍessａgeｓ）之后發(fā)出.7.4報警協(xié)議由SSL記錄層所支持的一種媒體類型為報警類型，報警消息帶有此消息的嚴重程度的編碼和對此報警的描述。最嚴重一級的報警消息將立即終止連接,在這種情況下,本次對話的其他連接還可以繼續(xù)進行，但對話標識符必須無效以防止此失敗的對話重新建立新的連接。象其他的消息一樣,報警消息是利用由當前連接狀態(tài)所指出的算法加密和壓縮的。enum{waｒning(1），fａｔaｌ（2)，（255）}AｌeｒtLeｖel；enuｍ{close_notify(０），uｎexpecｔeｄ_messaｇe（10），baｄ_rｅcord_ｍａc（2０），dｅｃompreｓsion_failure(30）,handsｈake_failurｅ（4０)，no_cｅrtｉfiｃate（41）,ｂad_certiｆiｃaｔe(42），unsupporｔｅd_certｉｆicate(43)，cｅrtｉficate_revoｋed（４4)，certｉｆｉcatｅ_expired（45),ｃertiｆicａt(yī)ｅ_ｕnknown（46），iｌlegal_parameter（47）（2５5)｝AlertDeｓｃｒiptｉｏｎ;ｓｔrｕcｔ｛AｌｅrtＬｅvelｌevel；ＡlertDescripｔionｄeｓｃriptｉoｎ;｝Alｅrｔ；7．4.1關閉報警客戶端和服務器為避免截斷攻擊必須共享連接已關閉這一信息,它們中的任一方均可以初始化關閉信息的交換.ｃlose_noｔify此消息通知收方發(fā)出者不會在此連接內(nèi)再發(fā)任何消息,當一次對話中的所有連接都沒有恰當?shù)腸losｅ_ｎotｉfy消息而終止時，此次對話是不能重新開始的。close_ｎｏｔifｙ消息的嚴重程度是警告級的７.４．2錯誤報警在ＳSL握手協(xié)議中的錯誤處理是很簡單的，當發(fā)現(xiàn)一個錯誤后，發(fā)現(xiàn)方將向?qū)Ψ桨l(fā)一消息。當傳輸或收到最嚴重一級的的報警消息時，連接雙方均立即終止此連接。服務器和客戶端均應忘記前一次對話的標識符、密鑰及有關失敗的連接的共享信息.SSL中定義了下列錯誤報警:ｕneｘpｅcｔed_meｓsaｇｅ收到一意外的消息,此報警通常是致命性錯誤的報警且不應在正常的連接中被觀察到。baｄ_ｒecord_mａc當收到一帶有不正確的ＭAＣ的記錄時，將返回此報警。此報警通常是致命性錯誤的報警.decｏｍpressiｏn＿failurｅ解密函數(shù)收到不合法的輸入(如數(shù)據(jù)太長等），此報警通是致命性錯誤的報警.ｈandsｈake＿failuｒe收到一ｈａndｓｈaｋｅ_fａilｕrｅ報警消息表明發(fā)出者不能接受現(xiàn)有的選項所提供的安全參數(shù)的集合，此報警通常是致命性錯誤的報警。no_cerｔificate當被要求給出證書而沒有合法的證書時,將發(fā)出一no_ｃeｒtifiｃａt(yī)ｅ報警消息.bad_certｉｆicaｔe當一證書被訛用、或者證書中不會的簽名不能被正確的認證等時，發(fā)出此報警。ｕnｓuppoｒteｄ＿ceｒtiｆicatｅ一有不被支持的類型的證書(如包含了用戶自定義的擴展）.cerｔificatｅ_revokｅd一被其發(fā)出者取消的證書.ceｒｔifｉcａt(yī)e＿ｅxｐireｄ一過期了的或不合法證書。ｃｅrtｉｆiｃate_ｕｎknown由一些不明的發(fā)出者發(fā)出的證書所引起的證書的不可接受性。illegal_ｐarameｔｅr在握手中的一個域的值溢出或與其他域的值不一致，此報警是致命性錯誤的報警。7.５握手協(xié)議總攬對話狀態(tài)的加密的參數(shù)是由SSL握手協(xié)議產(chǎn)生的，握手協(xié)議是在ＳＳL記錄層的頂部操作的。當一SSL客戶和服務器首次開始通訊時,它們就協(xié)議版本、加密算法的選擇、是否驗證對方及公鑰加密技術的應用進行協(xié)商以產(chǎn)生共享的秘密，這一處理是由握手協(xié)議完成的,可以總結(jié)如下：其中*表示不是必須發(fā)出的可選的或依賴于環(huán)境的消息客戶端首先發(fā)出客戶問候消息（clienthｅｌｌomｅssage)，服務器收到之后或者發(fā)出服務器問候消息（ｓerｖeｒhｅlloｍessａge），或者發(fā)生一終止性的錯誤然后此次連接將無法建立客戶和服務器問候消息(clienｔhｅllomessａge)被用來在客戶端和服務器之間建立安全的性能的協(xié)商，客戶和服務器的問候消息（cｌienthelｌomessage)將產(chǎn)生了下列屬性:協(xié)議版本號、對話標識符、加密套接字及壓縮方法,而且產(chǎn)生了兩個隨機數(shù)ClientＨelｌo。raｎdoｍ和ServｅｒHｅlｌo.ｒandom并且相互交換.在問候消息之后,若要求驗證身份，服務器將發(fā)出其證書,另外，如果需要的話(例如，如果他們的服務器沒有證書，或者其證書僅用來進行簽名），將發(fā)出一個ｓｅｒｖeｒkeyexchange消息。如果這個服務器已經(jīng)被認證，而且被所選的密碼組（ciｐheｒSUITE）所允許的話,它將向客戶端請求證書?，F(xiàn)在這個服務器將發(fā)出服務器問候結(jié)束消息(sｅｒｖeｒｈellｏｄonemeｓsagｅ），表明握手過程中的問候消息階段已經(jīng)結(jié)束。這個服務器接著將等候客戶端的回答。如果服務器發(fā)出一個cerｔificatｅreqｕeｓt消息，客戶端必須發(fā)出證書消息（certiｆiｃatemessanｇ)，或者一個nｏcertificatｅ報警?，F(xiàn)在，客戶端密鑰交換消息(cｌientkeｙeｘｃhangｅmｅssage）準備發(fā)送，而且消息的內(nèi)容將取決于在客戶端問候消息(ｃliｅntheｌlｏmesｓagｅ)和服務器問候消息(ｓervｅrheｌlｏｍeｓsaｇe）之間所選擇的公鑰算法。如果客戶端已經(jīng)發(fā)出了一個具備簽名能力的證書,一個數(shù)字簽名后的證書驗證消息（cｅrｔiｆicateverifymesｓage）將被發(fā)送以確認此證書的合法性。就這一點而言,一個改變加密說明（cｈangeciｐherｓpｅｃ)消息是被客戶端發(fā)送的，而且客戶端將未決的CiｐhｅrSpec復制到當前CipherＳpec。然后,客戶端立即用協(xié)商的新的算法、密鑰、和共享信息發(fā)出結(jié)束消息。服務器將發(fā)出其自己的改變ｃｉpｈeｒspec消息(chanｇeｃiｐherspecmｅsｓagｅ)作為回應，將未決(penｄｉnｇ)ciｐhｅrspｅc復制到當前CiphｅｒＳpｅc,并用新的cipherspｅc發(fā)出其結(jié)束消息。此時,握手過程結(jié)束，客戶端和服務器可以開始交換應用層數(shù)據(jù)了(見上圖）.注意:為了避免通道延遲，chaｎgｅCipｈｅrspec是一獨立的SSL協(xié)議的媒體類型，而并非一SSＬ握手消息.客戶端客戶端服務器客戶端問候服務器問候changeCipherSpec服務器結(jié)束changeCipherSpec客戶端結(jié)束應用數(shù)據(jù)應用數(shù)據(jù)客戶端首先利用需要重新開始的對話的對話標識符發(fā)出客戶端問候消息(ClｉｅｎtHellomessａｇe）,服務器檢查對話緩存來尋找匹配的對話,若找到匹配的對話，服務器將在指定的對話狀態(tài)下重新建立連接，它將發(fā)出帶有對話標識符的服務器問候消息（SｅｒverＨello）。此時，客戶端和服務器均必須發(fā)出改變cｉpherspec消息(chanｇeciｐhersｐeｃmessage）和結(jié)束消息(ｆinishｅｄｍessaｇe）,只要此重新建立連接一完畢,客戶端和服務器將交換應用層數(shù)據(jù)（見上圖)。若沒找到找到的對話標識符，服務器將產(chǎn)生新的對話標識符,然后ＳＳL客戶和服務器將進行正常的握手過程。每一消息的內(nèi)容和重要性將在以下各節(jié)中詳細的描述。7。6握手協(xié)議SSＬ握手協(xié)議是SＳL記錄協(xié)議(ｒｅcｏrdPｒotocｏl）的一個高級的客戶。此協(xié)議用來協(xié)商一對話的安全參數(shù)，握手消息被傳給ＳSL記錄層,在那里這些消息被封裝在一個或多個SSLＰl(wèi)aintext結(jié)構(gòu)之中，這些SSLPlaintｅxｔ結(jié)構(gòu)由當前活躍的對話狀態(tài)中所指定的參數(shù)進行處理和傳輸。enuｍ{hｅllo＿ｒeｑueｓt（0)，ｃｌiｅｎt_hｅllo（1）,ｓerver_hello(２),cｅｒｔｉficatｅ(11），seｒver＿kｅy_eｘchange（1２），certｉfiｃａt(yī)ｅ_request（１3),seｒver_hｅｌlｏ＿doｎｅ(14）,cｅrｔｉfiｃａｔe_veriｆy（１5)，ｃlienｔ_key＿exchangｅ（16)，fｉnished（20）,(２55）｝HaｎdshａkeType；struct｛HanｄｓhakeTypemsg＿tｙpe；/*握手消息的類型＊/uint２4lengｔh；/＊握手消息體的字節(jié)數(shù)＊/seｌｅct（HandｓｈakeTypｅ）｛cａsehelｌo_rｅqueｓt:HｅllｏRｅquｅsｔ;ｃasｅcｌieｎｔ_helｌo:ＣlieｎtHello；ｃaseserver_hellｏ：SeｒverHｅllｏ；cａｓecertifｉcaｔe:Cerｔifｉcaｔe;ｃaseserveｒ＿key_exｃhange:SeｒveｒKeyExchange；cａsecｅrtｉｆicａt(yī)ｅ_reqｕest:CertｉｆicatｅRequｅsｔ；ｃａseｓeｒｖer＿hellｏ_donｅ:ＳerverＨellｏＤonｅ;casecｅrｔifｉcate_veｒify：ＣeｒtificatｅVeｒify；cａseｃlieｎt＿ｋey_eｘchangｅ:ClientＫeｙExchaｎgｅ；caｓefinｉshed：Finishｅd;｝body;｝Ｈandｓhake;握手協(xié)議的消息必須按指定的順序發(fā)出(此順序如上所示）,若不按此順序發(fā)出,則會重新終止性錯誤.7.６.1問候消息（Helｌｏmessage)問候消息用來在客戶端和服務器之間交換彼此安全系統(tǒng)的性能。當一個對話剛開始時，CipherSpｅｃ中的加密、雜湊(hａsh）和壓縮算法均初始化為Null，當前的CipherSｐec被用來協(xié)商這些參數(shù)。7．6.１。1Hｅlｌoreqｕest要求問候消息(ｈelｌorequestmessagｅ)可以由服務器在任何時間發(fā)出，但若客戶端正在進行握手過程的話，此消息將會被客戶端所忽略.它只是一個簡單的通知,通知客戶端可以在方便的時候發(fā)出一客戶問候消息（clienｔｈelｌｏmｅsｓage)來開始一協(xié)商的過程。注意:由于握手消息是比應用層數(shù)據(jù)的傳輸優(yōu)先級高，所以協(xié)商的時間不應超過最大長度的應用層數(shù)據(jù)消息的傳輸時間的一到兩倍。在發(fā)出要求問候消息之后,在握手協(xié)商未完成之前服務器不應再重復發(fā)出此消息。一處于協(xié)商狀態(tài)中的客戶可以簡單的忽略其收到隨后要求問候消息。要求問候消息的結(jié)構(gòu)如下： struct{｝HｅlloRequeｓt;7。6．1。2客戶問候消息（Clieｎｔhello)當一客戶第一次與服務器進行連接時,它必須發(fā)客戶問候消息（Clienｔｈello)作為它的第一個消息?？蛻粢部梢詫⒋讼⒆鳛閷Ψ掌靼l(fā)來的要求問候消息的回應，還可以作為它自己想重新協(xié)商一已存在的對話的安全參數(shù)的標志發(fā)出此消息?？蛻魡柡蛳ⅲǎ胠ienthello)包含一以后會在協(xié)議中用到的隨機結(jié)構(gòu)strｕct｛uｉnt32ｇmt_unix_tｉme；opaqueranｄｏm_bytes［28］;}Randｏm;gmt_uniｘ＿tiｍe以標準的UNＩX的32位形式表示的發(fā)出者的內(nèi)部時鐘的當前時間和日期。ＳSL協(xié)議中并不要求時鐘必須是準確的，更高級的協(xié)議或應用層協(xié)議可能會對時鐘有更高的要求.raｎdom＿bytes一由安全隨機數(shù)發(fā)生器產(chǎn)生的28字節(jié)的隨機數(shù)?？蛻魡柡蛳ⅲǎ胠ｉentｈelｌo）包含一可變長度的對話標識符,如果此域的值非空，則此值標識了在同一客戶和同一服務器之間的一次對話，此次對話的安全參數(shù)是客戶端想重新使用的。這個對話的標識符也許是來自一個早期的連接，此次連接，或另一個當前活動的連接。如果客戶端僅僅要更新這個隨機結(jié)構(gòu)及一次連接的導出值的話,第二種選擇是有用的，而第三種選擇使得不必完全重復握手協(xié)議而同時建立幾種同步且獨立的安全連接成為可能.對話標識符的實際內(nèi)容由服務器定義。oｐａquｅSessionID<0。。３2＞；注意：服務器不能在對話標識符中放置機密信息,不能使假的對話標識符中的內(nèi)容導致任何泄密。這個包含在由客戶端傳向服務器的客戶問候消息(clｉeｎthｅllｏ）中的加密套接字(CipherＳuｉｔｅ）列表包含了加密算法的組合,此列表是客戶端所支持的的加密算法的列表，且此列表的順序是由客戶端按其自身的偏愛而選定的(列表的第一項是其最喜愛的).每一CｉpheｒＳuiｔe同時定義了一個密鑰交換算法和一個ＣipｈerSpec。服務器將或者選擇一個ＣipherSｕiｔe，或者，如果未給出可接受的選擇,將返回一個haｎdshakefaｉlｕｒe報警并關閉連接。uint8ＣipｈerＳuite［2］；/*加密組選擇器*/此客戶問候消息（clｉentｈello)包含了一個由客戶端支持的壓縮算法的列表,且根據(jù)客戶端的偏好排序.如果服務器不支持客戶端所定義的任何一種壓縮算法，則此次對話失敗。enum{null（0)，(255）｝ＣｏmpｒｅsｓｉｏnMｅtｈod;問題:需要支持哪一種要壓縮算法正處于調(diào)查之中.客戶問候消息（clienｔhello)的結(jié)構(gòu)如下:ｓtruｃｔ{PｒotｏｃｏlVersｉｏｎclient_ｖｅrsion;Ｒａnｄoｍｒａｎdom;ＳｅssionＩDsessｉon_id;CipheｒＳuｉtecｉｐｈｅr_sｕites＜2.。２1６-1>；ComｐresｓｉｏnMeｔhｏdcomprｅssion＿methｏdｓ〈1.。28—1〉;}ＣｌiｅntHelｌo;clｉent_ｖersｉｏn客戶端希望在此次對話中使用的SSL協(xié)議的版本。這應該是被客戶端所支持的最新的版本(最高值)。對于本文所描述的ＳSL協(xié)議,版本號應該是3.０。(關于背景兼容信息請見附錄E)。rａndｏm一個客戶端生成的隨機結(jié)構(gòu)。sｅssion＿id客戶端在此次連接中想使用的對話標識符（ID）。如果沒有可用的ｓeｓｓion-ID或者客戶端想要生成新的加密參數(shù)，這個值應該為空.cipher_ｓuiｔes這是一個由客戶端支持的,由客戶端按其自身的偏愛而選定的加密套接字的列表(列表的第一項是其最喜愛的)，如果sessｉoｎ_id域非空(暗示重新開始一已有的對話)，則此向量必須至少包含來自已有對話的ｃｉpｈer_sｕｉtｅ。加密套接字的值的定義見附錄A。６。compｒessiｏn_methｏds這是一個由客戶端支持的壓縮算法的列表,他根據(jù)客戶端自身的偏愛而選定的（列表的第一項是其最喜愛的）,如果seｓｓion_iｄ域非空（暗示重新開始一已有的對話）,則此向量必須至少包含一個來自已有對話的ｃompression_methoｄs的參數(shù).所有實現(xiàn)均必須支持ＣomｐresｓionMethod.nulｌ。繼發(fā)送cliｅnthelｌｏ消息之后,客戶端等候一個服務器問候消息（serverｈelloｍessage)。除了heｌlｏ消息外,由服務器返回的任何其他握手消息，均被視為致命錯誤(fatalerｒor）.實現(xiàn)時注意:只有當結(jié)束消息(finishｅdmｅssage）發(fā)送之后,應用程序的數(shù)據(jù)才能被發(fā)送。在一個合法的結(jié)束(finisｈｅd)消息被收到之前，就傳輸應用程序的數(shù)據(jù)被認為是不安全的.如果此次連接有一個當前的，非空的加密,則此絕對的限制將被放寬。7。６。１.3服務器問候消息（Serｖerｈellｏ)服務器處理客戶端問候消息（clｉenthｅｌｌo）并且對客戶端問候消息作出握手失敗(handshake_failurｅ）警告或者發(fā)出服務器問候消息(seｒvｅｒｈelｌo）作為響應。strｕct｛ＰroｔocoｌVｅrsioｎｓerｖｅr_veｒsion;Ｒanｄomrａｎdom;SessiｏnIDｓessｉｏｎ＿id；CipｈerSuitｅciphｅｒ_suiｔe；ＣoｍｐresｓiｏnMｅｔhodｃomｐｒession＿ｍetｈod;}ＳeｒveｒHeｌlo;server_vｅrsion這個域?qū)蛻舳嗽诳蛻舳藛柡蛳?clｉenthello)中建議使用的最低版本和被服務器所支持的最高版本.對于使用本詳細說明書的版本來說，版本號應為３．0(關于背景兼容性的詳細信息請見附錄E)ranｄｏm這個結(jié)構(gòu)由服務器產(chǎn)生,且必須與客戶問候消息中的CｌｉｅｎｔHello。ｒａndom不同,并且獨立于CｌienｔＨeｌｌo．random。sessioｎ_id這是對應于此次連接的對話標識.若客戶問候消息中的CliｅｎtHello．sｅssｉｏn_iｄ非空，服務器將在對話緩存器中尋找匹配的對話。如果匹配被找到并且服務器希望利用給定的對話對話狀態(tài)碼建立一個新的連接，服務器將用與客戶問候消息中給定的相同的值響應，這確認了一個重新開始的對話,且對話雙方將在收到對方的直到fｉnished消息之前將繼續(xù)執(zhí)行下去。否則，這個域?qū)粋€與客戶問候消息中的session_iｄ不同的值以標志一個新的對話。服務器可以返回一個空對話標識（sesｓioｎ_iｄ）用來表示這個對話將不會被緩存,而且因此不能被重新開始。Cipｈeｒ_ｓuitｅ由服務器從客戶端問候消息中的ＣｌｉｅnｔHello.cipｈer_suites列表中選擇一個加密套接字而得到的。對于重新開始的對話,此域的值是從重新開始的對話狀態(tài)字中得到的。coｍpｒession_method由服務器從客戶端問候消息中的comｐreｓs＿method列表中選擇的一壓縮算法。對于重新開始的對話此域的值是從重新開始的對話狀態(tài)字中得到的.7．6.2服務器的證書(Sｅｒvｅrｃeｒｔiｆicate)如果服務器要求被認證（通常都是這么要求的)，則服務器在發(fā)出服務器問候消息（seｒveｒhelｌomesｓage)之后接著發(fā)出服務器證書。證書的類型必須是由被選擇的加密套接字中密鑰交換算法所支持的,通常是X。509.版本3的證書（或是一在Fortｅｚｚa［FＯR]下的修改過的Ｘ.509證書.客戶端的證書的類型與服務器的證書類型相同。opａｑｕeASＮ．1Cerｔ〈１。。224－1〉;stｒuct｛ASN．1Cerｔcｅrｔificａｔe＿ｌist〈1。.22４—１＞;}Ceｒtificate；cerｔｉficatｅ＿list證書鏈中包含一序列X.50９。版本３的證書，這些證書的順序是首先是要驗證的一方的證書，然后是發(fā)出前一個證書的一方的證書…最后是根的證書。注意:由于沒有使用ＰKCS＃6［PＫＣS6］擴充證書,所以PKCS#7［ＰKCＳ７]也不能做為證書向量的格式來使用。且PKCS#7定義了一個集合而不是一個序列，從而使解析證書列表的任務更為復雜.7．6。3服務器密鑰交換消息（Serveｒkeyexchａngeｍesｓage）若服務器沒有證書，或只有供其簽名用的公鑰證書（例如DSS［DＳS]證書，只供簽名的RSＡ[RSA]證書)，或使用了Fｏrtezzａ/ＤMＳ密鑰交換,則服務器發(fā)出服務器密鑰交換消息（ｓerverkｅｙｅxcｈangeｍessａｇe）。當服務器的證書中包含Diｆfie-Heｌlmaｎ［ＤＨ1](即公鑰加密)參數(shù)時，則不發(fā)出此消息。注意:根據(jù)當前的美國出口法律，在軟件中用于密鑰交換的超過512比特的RＳA模塊是不允許出口的。對于此消息，長的RSA密鑰可以做為只用作簽名的證書來簽用作密鑰交換的臨時的短的RＳA密鑰。enｕm｛ｒsa，ｄiffie_hellman，ｆorｔezｚa_dmｓ｝KeyExcｈaｎｇeＡlgoritｈm；struct{opａquersａ_moｄulｕs<1。.２16—１>;opａｑuersa＿exponeｎt<１。。216-1〉；}ServerRSAPａｒams；其中：rｓa_moｄｕlus服務器的臨時的RSA密鑰的模數(shù).rsa_eｘponｅｎt服務器的臨時的RＳA密鑰的公開指數(shù)。struct{opaquedh＿p<1..2１6-１〉;ｏpaquｅdh_g<１.。２1６—１>；oｐaqueｄh_Ys〈1.．216-１>；｝SeｒverDHＰaｒａｍs;/*短期的DH參數(shù)*/其中：dh_pDifｆie—Ｈelｌｍan操作中用到的質(zhì)模數(shù)。ｄh＿gDiｆfie-Hellman操作中用到的發(fā)生器。ｄh＿Ｙ服務器的Ｄiffｉe-Hｅllmａｎ公開值（ｇXｍodp）.sｔｒuｃt{opaquer＿ｓ［128］；｝ServerＦoｒtezｚaPａraｍs;其中：r_ｓ服務器為密鑰交換算法而生成的隨機數(shù)。digitａｌly-siｇnedsｔrｕｃt｛seｌecｔ（SignatureAlｇoriｔhm)｛cａｓeanｏｎymoｕｓ：struct｛};caｓeｒsａ：opaquｅmd5_hash[16];ｏｐaｑｕesｈａ＿haｓh［２0];cａsedsa：?ｏpaquｅsha_haｓh[20］;｝;｝Ｓignatｕｒe;ｓtrｕct{sｅlｅｃt(KeyＥxchangｅＡlgorｉthm)｛cａsｅｄifｆｉｅ_hellman：SerｖｅrDHPａｒamｓpaｒamｓ；Signatuｒesiｇneｄ_ｐaraｍs;ｃａｓersa：SｅrｖerRSAＰarａmsｐａrａｍs；Sｉｇnaturesigneｄ_params；cａｓeforteｚza_dms：ＳerｖｅrＦortezｚａPaｒamsparａms；｝；｝SerｖerKeyExchaｎge；其中：paｒaｍs ?? 服務器的密鑰交換參數(shù)。siｇneｄ_paraｍｓ ?相應的參數(shù)值的哈希值，及對此哈希值的簽名。ｍｄ5_hashMD５(ClｉｅntHｅｌlo。rａnｄom+Serverｈelｌo。randoｍ+ＳervｅrＰaｒａmｓ)；sha_hasｈSＨA（ClienｔＨello.ｒandｏm+SerｖeｒＨｅllo。ｒａｎdｏm＋ＳｅrverParams);enum｛ａnonyｍous，rsa，dsａ}Sigｎａt(yī)ｕreAlgorithm；７．６．４證書請求（Ｃertifｉcateｒｅqｕesｔ）如果選擇的加密套接字允許的話，一非匿名的服務器可以向客戶端要求客戶端的證書。ｅｎum{rsa＿siｇn（1)，dss_sｉｇn（2)，rsa＿fixｅd＿ｄh（3),dｓs_fixeｄ_dh（4），ｒsa_epｈｅmeral_dｈ(5），dｓs_ephemｅrａl_dh(6),foｒtｅzza_ｄmｓ（20）,(255)｝CliｅntＣｅｒtiｆicａｔeType;oｐaqueＤｉstinguishedNａme<3.。２1６-１>;struct{ＣｌientCeｒｔificateTypeceｒtificate_ｔypes＜1．。２8-１＞;DｉstinguishｅdNamecertificatｅ_aｕｔhｏrities＜3。．216—1>；｝ＣertiｆｉcateＲｅｑuesｔ;cｅｒtｉfｉcate_tｙpes此域的值是一被請求的證書的類型的列表，此列表是按服務器的偏好的先后順序排序的.ｃｅrtificaｔｅ＿authorities是可接受的證書授權當局的唯一的辨別名的列表.注意：唯一的辨別名是由［X509］中導出的.注意:對于一匿名的服務器來說，請求客戶端發(fā)出客戶端的證書是一致命的握手失敗報警。7。６.5服務器問候結(jié)束(Serverhelｌodone）由服務器發(fā)出的服務器問候結(jié)束消息（serｖｅrｈeｌlodoneｍessagｅ）是表明服務器問候和其相關的消息的結(jié)束。當服務器發(fā)出此消息后，它將等待客戶端的回應。struct{｝ＳｅrvｅrHｅllｏDonｅ；當客戶端收到服務器問候結(jié)束消息（seｒvｅrhｅlｌｏdoｎemeｓsagｅ)后，若它要求的話,它將驗證服務器的證書是否合法,并且檢查在服務器問候消息中的參數(shù)是否是可接受的。7．６。6客戶端的證書（Clieｎｔcertificate）客戶端證書是客戶端收到服務器問候結(jié)束消息(ｓerｖerheｌｌｏdoｎｅｍessage）后所能發(fā)出的第一個消息。只有當服務器要求客戶端的證書時客戶端才發(fā)出此消息。如果客戶端沒有合適的證書，則它發(fā)出沒有證書報警（ｎocerｔｉficatｅａlert)，此報警僅僅是一個警告，若服務器要求客戶端認證，則服務器回應一握手失敗的致命性的報警。客戶端的證書的格式的定義件７。6．２節(jié)。注意：客戶端的Ｄiｆfie－Hｅｌlｍａn證書必須與服務器指定的Diffie－Hellmａn參數(shù)相匹配.７.6．７客戶端密鑰交換消息（Ｃlｉenｔkeyexchａngｅmesｓａge)是否選擇發(fā)出此消息依賴于在密鑰交換算法定義中選擇的公鑰算法（見7。６.３節(jié))strｕct｛select（KeyＥxｃhangｅAlｇｏｒithｍ）｛caseｒsa:EnｃryptedPreＭａsteｒSecret；caseｄiffie_hellｍａn:CｌieｎtDiｆｆｉeＨｅｌlmanPuｂlic；cａsefｏrtezｚa_dmｓ:ＦortezzaＫeｙs;｝eｘchange_keyｓ;｝ClientKeyEｘcｈaｎge;選擇合適的記錄結(jié)構(gòu)的信息在未決的對話狀態(tài)字中(見7.1節(jié)）。7。6．7。1RSA加密的預主秘密消息(RＳAｅncryptedｐrｅｍasteｒsecretmesｓagｅ）若在密鑰一致性及認證時使用的是ＲSＡ算法，則客戶端產(chǎn)生一48比特的預主秘密(pre－mａｓｔerseｃret），并用服務器證書中的公鑰或一由服務器密鑰交換消息中得到的臨時RSA密鑰對其進行加密，然后將加密的結(jié)果用一加密的預主秘密（eｎｃryｐtedｐremaｓtｅrsecreｔ）消息發(fā)給服務器。

sｔrucｔ｛ProtoｃolVersioｎｃlｉent＿version；opaｑuerａndｏｍ[46］;}PreMasterＳecrｅt；clieｎt_ｖeｒsioｎ客戶端所支持的最新的ＳＳL版本,此域用來發(fā)現(xiàn)版本重算攻擊（veｒsｉonrｏll—ｂackatｔacｋs）。ranｄom 46比特安全產(chǎn)生的隨機數(shù)。sｔｒuct｛pｕｂlic－ｋｅy—enｃryptedPreMａsｔerＳecrｅｔ prｅ_masteｒ_secret；｝EnｃrypｔedPreMasteｒＳecrｅt；pre_mａster_ｓeｃret由客戶端產(chǎn)生的此隨機數(shù)是用來產(chǎn)生8.1節(jié)中說明的主秘密(masteｒsecret)的。7.6.7.２Ｆoｒtezza密鑰交換消息(Fｏrｔezｚaｋｅyexcｈaｎgｅｍessagｅ）在ＦortｅｚｚaDＭS下,客戶端利用Fortezｚa密鑰交換算法(ＫEA）得到一標記加密密鑰（TokenEncryptionKey(ＴEK）)?？蛻舳死梅掌髯C書中的服務器公鑰和其自身的標記參數(shù)來計算KEＡ，并且利用其自身的參數(shù)發(fā)出供服務器產(chǎn)生TEK的公開參數(shù).客戶端產(chǎn)生對話密鑰，用TＥＫ封裝后發(fā)給服務器；客戶端還產(chǎn)生對話密鑰的初始向量(ＩV）和TＥK,并將它們發(fā)給服務器；它還初始一48比特的隨機的預主秘密，用TEK加密后發(fā)給服務器。struct｛opaqｕey_c<0..128>；opaquｅr_ｃ［1２8］；opaqｕey_signaｔｕre[20］；ｏpaqueｗraｐｐed_ｃlient_write＿key［1２];opａquewrappeｄ＿seｒver_write＿kｅy［1２］;opaquecｌienｔ_ｗｒiｔｅ_IＶ［24］;opaqueｓerver_wｒiｔｅ_IV[２4］;opaquemaｓteｒ_secｒet_IV[24］；bｌock－ciphｅreｄｏpaqueeｎcrypteｄ_pre_masteｒ_ｓecrｅt［4８]；｝ＦortezｚaKeys;ｙ_sigｎａｔｕｒey_signａt(yī)ure是KEA公鑰的簽名,是用客戶端的DSS私鑰簽的名.y_c在KEA計算中用到的客戶端的Yc值（公鑰）。若客戶端已發(fā)出其證書且ＫEA公鑰是合適的，則由于證書中已有此值，此域可以為空。當客戶端發(fā)出一密鑰合適的公鑰的證書的時候,就要有y_ｃ，且y_siｇnaｔure是用客戶端DSS私鑰簽署的KEＡ公鑰的簽名。它必須在６4至12８比特之間。r_c客戶端為計算KEA的Rc值。ｗrａpped_ｃｌiｅnt＿wｒite_keｙ這是客戶端的寫密鑰，是由ＴＥK封裝的。wrapped_ｓerｖeｒ_write＿kｅy這是服務器的寫密鑰,是由TEK封裝的。cｌiｅnｔ_ｗrite＿IV這是客戶端的寫密鑰的初始化向量。sｅｒver_ｗritｅ_IV這是服務器的寫密鑰的初始化向量。mａｓter_secreｔ_IV這是用來加密預主秘密的TEK的初始化向量。ｐｒe_master_secret這是一個由客戶端產(chǎn)生的隨機數(shù)，用來產(chǎn)生8。1節(jié)中所描述的主秘密。在上述結(jié)構(gòu)中，它是用TEＫ加密過的。7。6。7.３客戶端Diffｉe—Heｌlmaｎ公開值(ＣliｅnｔDiffie—Helｌｍａnｐubｌicvaｌue）若客戶端的Diffie—Hellman公開值(Yc)未包含在客戶端的證書中的話，此結(jié)構(gòu)將傳送它。Yc使用的編碼方式是由枚舉類型ＰuｂliｃVaｌｕeEncoding．所決定的。enum｛iｍplicit,explicit}PｕｂlicValueEncｏdｉｎｇ;其中:iｍpｌicｉt若客戶端的證書中已包含此公開值，則它是隱含的，所以Yc不需再傳了。EｘpliｃitYc需要被傳送。struct｛sｅlect（ＰublicValｕｅＥncｏdiｎg)｛cａseimplｉcit：stｒucｔ{};ｃasｅeｘplicit:ｏpaqueｄｈ_Ｙc＜1．。216—1>;｝dh_public；｝CliｅntDｉffiｅＨｅllmaｎPublic;其中：dｈ_Yc客戶端的Difｆie-Ｈellｍan公開值（Yｃ）。７．6。8證書驗證（Ｃｅrtifｉｃaｔevｅrｉfy）此消息被用來對客戶端的證書提供明顯的驗證。此消息僅在有簽名能力的客戶端證書（即沒有包含固定的Dｉffie－Ｈｅｌｌmaｎ參數(shù)的所有證書）發(fā)出之后才被發(fā)出。strｕｃt{Signaturｅsigｎatｕre；｝CertｉｆiｃaｔeＶeriｆy；CertificatｅＶeｒify.signature。md5_hａsｈMD5（mａster＿ｓecrｅt＋pａd2+MＤ5(haｎdｓhａｋｅ_ｍessageｓ+mａｓter＿secret＋ｐad1)）;Certificate．signａt(yī)ｕre。ｓｈａ_hasｈSHA(mａster_sｅcret+ｐaｄ2+ＳHA（ｈandshakｅ_mｅｓｓagｅs＋mａｓtｅｒ_secret＋pad１）);在這里，握手消息(ｈaｎdshake_messａgｅs）