安全協(xié)議工程之SSL協(xié)議分析及鉆井工程承包合同

HYPERLINK""安全協(xié)議工程題目：SSL協(xié)議分析系別：專業(yè)：學生姓名：學號：指導教師：2021年6月23日摘要目前，隨著Internet的快速發(fā)展，人們在使用互聯(lián)網(wǎng)的場地越來越多，范圍越來越廣泛，互聯(lián)網(wǎng)上的信息安全越來越引起人們的關(guān)注。特別是近年來網(wǎng)上銀行、電子商務(wù)和電子政務(wù)的快速發(fā)展，如何保證用戶的傳輸信息，特別是交易信息的保密性、完整性已成為迫切需要解決的問題。為此人們研究越來越多的措施來保護用戶的信息，所以有了很多的安全協(xié)議，其中安全套接層協(xié)議(SecuritySocketLayerProtocol,簡稱SSL)是Internet上進行保密通信的一個安全協(xié)議。關(guān)鍵詞：Internet；信息安全；保密性；完整性；安全套階層協(xié)議目錄引言…………………41.SSL簡介…………42.SSL工作原理……………………43.SSL協(xié)議提供的服務(wù)………………54.SSL記錄層協(xié)議……………………55.SSL握手協(xié)議………76.SSL的應(yīng)用…………107.SSL的安全性分析…………………11引言網(wǎng)絡(luò)的迅速發(fā)展，逐漸普及到各個領(lǐng)域，但是有利也有弊，發(fā)展越快，出現(xiàn)的問題也就越多。而最終的的還是信息方面的安全保證，特別是在傳輸過程中，為此諸多杰出的人員也加入到這個研究中，研究怎么樣最大程度保護信息的安全傳輸。傳輸層在TCP/IP協(xié)議族中具有重要地位，它加強和彌補了IP層的服務(wù)。從服務(wù)類型看，IP層是點到點的，而傳輸層提供端到端的服務(wù)；從服務(wù)質(zhì)量看，傳輸層提高了可靠性，使得高層應(yīng)用不必關(guān)注可靠性問題，而僅需解決與自身應(yīng)用功能相關(guān)的問題；從協(xié)議依賴關(guān)系看，應(yīng)用層協(xié)議直接構(gòu)建于傳輸層之上。應(yīng)用層協(xié)議直接與用戶交互，因此它們的安全性也會受到最直接的關(guān)注。舉個直觀的例子，電子商務(wù)系統(tǒng)通常采用B/S結(jié)構(gòu)，用戶通過瀏覽器訪問電子商務(wù)網(wǎng)站、購買商品并進行網(wǎng)上支付。在這類應(yīng)用中，機密性、完整性、服務(wù)器身份認證、不可否認性和可用性都是用戶所需的。此外，在進行文件和郵件傳輸時，用戶也有類似的安全需求。遺憾的是，常用的HTTP、FTP等協(xié)議都無法滿足這些安全需求。雖然HTTP、等協(xié)議提供了基于口令的身份認證機制，但在互聯(lián)網(wǎng)這個開放的環(huán)境中，這種簡單的保護顯得微不足道。改變這種現(xiàn)狀的途徑之一就是為每個應(yīng)用層協(xié)議都增加安全功能。對于應(yīng)用設(shè)計者而言，這是一個并不輕松的工作；對于應(yīng)用使用者而言，部署多個安全應(yīng)用時，勢必會消耗大量的系統(tǒng)資源。另一種途徑就是從傳輸層人手。既然高層應(yīng)用都是基于傳輸層的，那么增強這個層次的安全性顯得更具備通用性。它可以把高層應(yīng)用從安全性這個復雜的命題中解放出來，使用者也可用較小的開銷獲得所需的安全服務(wù)。1.SSL簡介SSL和TLS，它們分別是安全套接層(SecureSocketLayer)和傳輸層安全（TransportLayerSecurity）的縮寫，是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議TLS與SSL，在傳輸層對網(wǎng)絡(luò)連接進行加密。SSL首先由網(wǎng)景公司提出，最初是為了保護Web安全，最終卻為提高傳輸層安全提供了一個通用的解決方案。在SSL獲得了廣泛應(yīng)用之后，IETF斟于SSLv3，制定TLS標準。TLSv1與SSLv3幾乎完全一致。SSL協(xié)議位于與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。SSL協(xié)議可分為兩層：SSL記錄協(xié)議（SSLRecordProtocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。SSL握手協(xié)議（SSLHandshakeProtocol）：它建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份認證、協(xié)商加密算法、交換加密等。2.SSL工作原理SSL的工作原理：當一個使用者在Web上用Netscape瀏覽器漫游時，瀏覽器利用HTTP協(xié)議與Web服務(wù)器溝通。例如，瀏覽器發(fā)出一個HTTPGET命令給服務(wù)器，想下載一個首頁的HTML檔案，而服務(wù)器會將檔案的內(nèi)容傳送給瀏覽器來響應(yīng)。GET這個命令的文字和HTML檔案的文字會通過會話層（Socket）的連接來傳送，Socket使兩臺遠程的計算機能利用Internet來通話。通過SSL，資料在傳送出去之前就自動被加密了，它會在接收端被解密。對沒有解密鑰的人來說，其中的資料是無法閱讀的。SSL采用TCP作為傳輸協(xié)議提供數(shù)據(jù)的可靠傳送和接收。SSL工作在Socket層上，因此獨立于更高層應(yīng)用，可為更高層協(xié)議，如Telnet、提供安全業(yè)務(wù)。SSL提供的安全業(yè)務(wù)和TCP層一樣，采用了公開密鑰和私人密鑰兩種加密體制對Web服務(wù)器和客戶機（選項）的通信提供保密性、數(shù)據(jù)完整性和認證。在建立連接過程中采用公開密鑰，在會話過程中使用私人密鑰。加密的類型和強度則在兩端之間建立連接的過程中判斷決定。在所有情況下，服務(wù)器通過以下方法向客戶機證實自身：給出包含公開密鑰的、可驗證的證明；演示它能對用此公開密鑰加密的報文進行解密。為了支持客戶機，每個客戶機都要擁有一對密鑰，這要求在Internet上通過Netscape分配。由于Internet中的服務(wù)器數(shù)遠少于客戶機數(shù)，因此能否處理簽字及密鑰管理的業(yè)務(wù)量是很重要的，并且與客戶聯(lián)系比給商家以同樣保證更重要。3.SSL協(xié)議提供的服務(wù)（1）用戶和服務(wù)器的合法性認證使得用戶和服務(wù)器能夠確信數(shù)據(jù)將被發(fā)送到正確的客戶機和服務(wù)器上。客戶機和服務(wù)器都有各自的識別號，由公開密鑰編排。為了驗證用戶，安全套接層協(xié)議要求在握手交換數(shù)據(jù)中做數(shù)字認證，以此來確保用戶的合法性。（2）加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)安全套接層協(xié)議采用的加密技術(shù)既有對稱密鑰，也有公開密鑰。具體來說，就是客戶機與服務(wù)器交換數(shù)據(jù)之前，先交換SSL初始握手信息。在SSL握手信息中采用了各種加密技術(shù)，以保證其機密性和數(shù)據(jù)的完整性，并且經(jīng)數(shù)字證書鑒別，這樣就可以防止非法用戶破譯。（3）維護數(shù)據(jù)的完整性安全套接層協(xié)議采用密碼雜湊函數(shù)和機密共享的方法，提供完整信息性的服務(wù)，來建立客戶機與服務(wù)器之間的安全通道，使所有經(jīng)過安全套接層協(xié)議處理的業(yè)務(wù)，在傳輸過程中都能完整、準確無誤地到達目的地。4.SSL記錄層協(xié)議SSL記錄層協(xié)議限定了所有發(fā)送和接收數(shù)據(jù)的打包，它提供了通信、身份認證功能，它是一個面向連接的可靠傳輸協(xié)議，如TCP/IP提供安全保護。在SSL中所有數(shù)據(jù)被封裝在記錄中。一個記錄由兩部分組成：記錄頭和非零長度的數(shù)據(jù)。記錄頭可以是2字節(jié)或3字節(jié)（當有填充數(shù)據(jù)時使用）。SSL握手層協(xié)議的報文要求必須放在一個SSL記錄層的記錄里，但應(yīng)用層協(xié)議的報文允許占用多個SSL記錄來傳送。1．SSL記錄頭格式SSL記錄頭可以是2個或3個字節(jié)長的編碼。SSL記錄頭包含的信息有記錄頭的長度、記錄數(shù)據(jù)的長度，以及記錄數(shù)據(jù)中是否有填充數(shù)據(jù)，其中填充數(shù)據(jù)是在使用塊加密（blocken-cryption）算法時，填充實際數(shù)據(jù)，使其長度恰好是塊的整數(shù)倍。最高位為1時，不含有填充數(shù)據(jù)，記錄頭的長度為2個字節(jié)，記錄數(shù)據(jù)的最大長度為32767個字節(jié)；最高位為0時，含有填充數(shù)據(jù)，記錄頭的長度為3個字節(jié)，記錄數(shù)據(jù)最長為16383個字節(jié)。2字節(jié)頭記錄2字節(jié)頭記錄記錄頭類型記錄頭類型記錄長度MACMAC數(shù)據(jù)3字節(jié)頭3字節(jié)頭記錄記錄頭類型EScap記錄頭類型EScape位記錄長度填充長度MAC數(shù)MAC數(shù)據(jù)填充數(shù)據(jù)SSL記錄層結(jié)構(gòu)當數(shù)據(jù)頭長度是3個字節(jié)時，次高位有特殊的含義。次高位為1時，表示所傳輸?shù)挠涗浭瞧胀ǖ臄?shù)據(jù)記錄；次高位為0時，表示所傳輸?shù)挠涗浭前踩瞻子涗洠ū槐Ａ粲糜趯韰f(xié)議的擴展）。記錄頭中數(shù)據(jù)長度編碼不包括數(shù)據(jù)頭所占用的字節(jié)長度。記錄頭長度為2個字節(jié)時，記錄長度的計算公式為：記錄長度?（（Byte[0]&0x7f）<<8）|Byte[1]。其中Byte[0]、Byte[1]分別表示傳輸?shù)牡谝粋€、第二個字節(jié)。記錄頭長度為3個字節(jié)時，記錄長度的計算公式是：記錄長（（Byte[0]&0x3f<<8））|Byte[1]。其中Byte[0]、Byte[1]的含義同上。判斷是否是安全空白記錄的計算公式是：（Byte[0]&0x40）！?0。填充數(shù)據(jù)的長度為傳輸?shù)牡谌齻€字節(jié)。SSL記錄數(shù)據(jù)格式SSL記錄數(shù)據(jù)部分有3個分量：MAC-DATA、ACTUAL-DATA和PADDING-DATA。MAC數(shù)據(jù)用于數(shù)據(jù)完整性檢查。計算MAC所用的散列函數(shù)由握手協(xié)議中的CIPHER-CHOICE消息確定。若使用MD2和MD5算法，則MAC數(shù)據(jù)長度是16個字節(jié)。MAC的計算公式為：MAC數(shù)據(jù)=Hash[密鑰,實際數(shù)據(jù),填充數(shù)據(jù),序號]。當會話的客戶端發(fā)送數(shù)據(jù)時，密鑰是客戶的寫密鑰（服務(wù)器用讀密鑰來驗證MAC數(shù)據(jù)）；而當會話的客戶端接收數(shù)據(jù)時，密鑰是客戶的讀密鑰（服務(wù)器用寫密鑰來產(chǎn)生MAC數(shù)據(jù)）。序號是一個可以被發(fā)送和接收雙方遞增的計數(shù)器，每個通信方向都會建立一對計數(shù)器，分別被發(fā)送者和接收者擁有。計數(shù)器有32位，計數(shù)值循環(huán)使用，每發(fā)送一個記錄，計數(shù)值遞增一次，序號的初始值為0。ACTUAL-DATA是被傳送的應(yīng)用數(shù)據(jù)，PADDING-DATA是當采用分組碼時所需要的填充數(shù)據(jù)，在明文傳送下只有第二項。3．記錄協(xié)議的作用記錄協(xié)議層封裝了高層協(xié)議的數(shù)據(jù)，協(xié)議數(shù)據(jù)采用SSL握手協(xié)議中協(xié)商好的加密算法及MAC算法來保護。記錄協(xié)議傳送的數(shù)據(jù)包括一個序列號，這樣就可以檢測消息的丟失、改動或重放。如果協(xié)商好了壓縮算法，那么SSL記錄協(xié)議還可以執(zhí)行壓縮功能。SSLV3版的高層由記錄傳遞的消息組成，這包括改變密碼規(guī)范協(xié)議、警報協(xié)議和握手協(xié)議。改變密碼規(guī)范協(xié)議指明對使用的密碼規(guī)范的改變，協(xié)議中還包括了一個用當前密碼規(guī)范加密的單獨消息?？蛻艉头?wù)器都要發(fā)送改變密碼規(guī)范消息來表明它們準備使用一個新的密碼規(guī)范和密鑰。警報協(xié)議傳送與事件相關(guān)的消息，包括事件嚴重性及事件描述。這里的事件主要是指錯誤情形，如錯誤的MAC碼、證書過期或是非法參數(shù)。警報協(xié)議也用于共享有關(guān)預計連接終止的信息。5.SSL握手協(xié)議握手協(xié)議是關(guān)于客戶和服務(wù)器如何協(xié)商它們在安全信道中要使用的安全參數(shù)，這些參數(shù)包括要采用的協(xié)議版本、加密算法和密鑰。另外，客戶要認證服務(wù)器，服務(wù)器則可以選擇認證/不認證客戶。PKI在客戶—服務(wù)器認證階段就開始運作了，這就是握手協(xié)議的實質(zhì)。1．握手協(xié)議工作過程①客戶（client）端發(fā)送ClientHello信息給服務(wù)器（Server）端，Server回答ServerHello。這個過程建立的安全參數(shù)包括協(xié)議版本、“佳話”標識、加密算法、壓縮方法。另外，還交換兩個隨機數(shù)：C1ientHello.Random和ServerHello.Random，用于計算機“會話主密鑰”。②Hello消息發(fā)送完后，Server端會發(fā)送它的證書和密鑰交換信息。如果Server端被認證，它就會請求Client端的證書，在驗證以后，Server就發(fā)送HelloDone消息，以示達成了握手協(xié)議，即雙方握手接通。③Server請求Client證書時，Client要返回證書或返回沒有證書的指示，這種情況用于單向認證，即客戶端不裝有證書。然后，Client發(fā)送密鑰交換消息。④服務(wù)器Server此時要回答“握手完成”消息（Finished），以示完整的握手消息交換已經(jīng)全部完成。⑤握手協(xié)議完成后，Client端即可與Server端傳輸應(yīng)用加密數(shù)據(jù)，應(yīng)用數(shù)據(jù)加密一般是用第②步密鑰協(xié)商時確定的對稱加/解密密鑰，如DES、3DE等。目前，商用加密強度為128位，非對稱密鑰一般為RAS，商用強度為1024位，用于證書的驗證。ClientHelloCertificateClientKeyExchange*ClientHelloCertificateClientKeyExchange*CertificateVerify（ChangeCipherSpec）FinishedApplicationDataServerHelloCertificateServerKeyExchangeCertificateVerifyServerHelloDoneFinishedApplicationData完整的握手協(xié)議消息交換過程完整的握手協(xié)議消息交換過程其中，帶*號的命令是可選的，或依據(jù)狀態(tài)而發(fā)的消息，而改變加密算法協(xié)議（ChangeCipherSpec）并不在實際的握手協(xié)議之中，它在第③步與第④步之間，用于Client與Server協(xié)商新的加密數(shù)據(jù)包時而改變原先的加密算法。2．握手協(xié)議的作用SSL中的握手協(xié)議，將公鑰加密技術(shù)與對稱密鑰加密技術(shù)的應(yīng)用有效、巧妙地結(jié)合在一起，有機地組成了互聯(lián)網(wǎng)（或其他網(wǎng)絡(luò)）上信息安全傳輸?shù)耐ǖ?。這種信息安全通道，有其實用價值，比如，利用對稱加密技術(shù)比公鑰加密技術(shù)對大容量信息的加/解密速度要快，而公鑰技術(shù)卻提供了更好的身份認證技術(shù)。SSL的握手協(xié)議可以非常有效地讓客戶與服務(wù)器之間完成身份認證。通過SSL客戶端與服務(wù)器傳送自己的數(shù)字證書，互驗合法性，特別是驗證服務(wù)器的合法性，可以有效地防止互聯(lián)網(wǎng)上虛假網(wǎng)站的網(wǎng)上釣魚事件；同時，服務(wù)器端也可以嚴格驗證客戶端的真實身份。其作用如下：①客戶端的瀏覽器向服務(wù)器傳送客戶端SSL協(xié)議的版本號、加密算法的種類、產(chǎn)生的隨機數(shù)，以及其他服務(wù)器和客戶端之間通信所需要的各種信息。②服務(wù)器向客戶端傳送SSL協(xié)議的版本號、加密算法的種類、隨機數(shù)及其他相關(guān)信息，同時，服務(wù)器還將向客戶端傳送自己的證書。③客戶利用服務(wù)器傳過來的信息驗證服務(wù)器的合法性。服務(wù)器的合法性包括：證書是否過期，發(fā)行服務(wù)器證書的CA是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實際域名相匹配。如果合法性驗證沒有通過，則通信將斷開；如果合法性驗證通過，則將繼續(xù)進行第④步。④客戶端隨機產(chǎn)生一個用于后面通信的“對稱密碼”，然后用服務(wù)器的公鑰（從步驟②中服務(wù)器的證書中獲得）對其加密，再將加密后的“預主密碼”傳給服務(wù)器。⑤如果服務(wù)器要求客戶的身份認證（在握手過程中為可選），用戶則可以建立一個隨機數(shù)，然后對其進行數(shù)字簽名，將這個含有簽名的隨機數(shù)和客戶自己的證書，以及加密過的“預主密碼”一起傳給服務(wù)器。⑥如果服務(wù)器要求客戶的身份認證，服務(wù)器則必須檢驗客戶證書和簽名隨機數(shù)的合法性。具體的合法性驗證包括：客戶的證書使用日期是否有效，為客戶提供證書的CA是否可靠，發(fā)行CA的公鑰能否正確解開客戶證書的發(fā)行CA的數(shù)字簽名，檢查客戶的證書是否在證書撤銷列表（CRL）中。檢驗如果沒有通過，則通信立刻中斷；如果驗證通過，則服務(wù)器將用自己的私鑰解開加密的“預主密碼”，然后執(zhí)行一系列步驟來產(chǎn)生主通信密碼（客戶端也將通過同樣的方法產(chǎn)生相同的主通信密碼）。⑦服務(wù)器和客戶端用相同的主密碼，即“通話密碼”，一個對稱密鑰用于SSL協(xié)議的安全數(shù)據(jù)通信的加/解密通信。同時，在SSL通信過程中還要完成數(shù)據(jù)通信的完整性，以防止數(shù)據(jù)通信中的任何變化。⑧客戶端向服務(wù)器端發(fā)出信息，指明后面的數(shù)據(jù)通信將使用步驟⑦中的主密碼為對稱密鑰，同時通知服務(wù)器客戶端的握手過程結(jié)束。⑨服務(wù)器向客戶端發(fā)出信息，指明后面的數(shù)據(jù)通信將使用步驟⑦中的主密碼為對稱密鑰，同時通知客戶端服務(wù)器端的握手過程結(jié)束。⑩SSL的握手部分結(jié)束，SSL安全通道的數(shù)據(jù)通信開始，客戶和服務(wù)器開始使用相同的對稱密鑰進行數(shù)據(jù)通信，同時進行通信完整性的檢驗。證書各部分的含義Version證書版本號，不同版本的證書格式不同SerialNumber序列號，同一身份驗證機構(gòu)簽發(fā)的證書序列號唯一AlgorithmIdentifier簽名算法，包括必要的參數(shù)Issuer身份驗證機構(gòu)的標識信息PeriodofValidity有效期Subject證書持有人的標識信息Subject’sPublicKey證書持有人的公鑰Signature身份驗證機構(gòu)對證書的簽名證書的格式認證中心所發(fā)放的證書均遵循X.509V3標準，其基本格式如下：證書版本號（CertificateFormatVersion）含義：用來指定證書格式采用的X.509版本號。證書序列號（CertificateSerialNumber）含義：用來指定證書的唯一序列號，以標識CA發(fā)出的所有公鑰證書。簽名（Signature）算法標識（AlgorithmIdentifier）含義：用來指定CA簽發(fā)證書所用的簽名算法。簽發(fā)此證書的CA名稱（Issuer）含義：用來指定簽發(fā)證書的CA的X.500唯一名稱（DN，DistinguishedName）。證書有效期（ValidityPeriod）起始日期（notBefore）終止日期（notAfter）含義：用來指定證書起始日期和終止日期。用戶名稱（Subject）含義：用來指定證書用戶的X.500唯一名稱（DN，DistinguishedName）。用戶公鑰信息（SubjectPublicKeyInformation）算法（algorithm）算法標識（AlgorithmIdentifier）用戶公鑰（subjectPublicKey）含義：用來標識公鑰使用的算法，并包含公鑰本身。證書擴充部分（擴展域）（Extensions）含義：用來指定額外信息。X.509V3證書的擴充部分（擴展域）及實現(xiàn)方法如下：CA的公鑰標識（AuthorityKeyIdentifier）公鑰標識（SET未使用）（KeyIdentifier）簽發(fā)證書者證書的簽發(fā)者的甄別名（CertificateIssuer）簽發(fā)證書者證書的序列號（CertificateSerialNumber）X.509V3證書的擴充部分（擴展域）及實現(xiàn)CA的公鑰標識（AuthorityKeyIdentifier）公鑰標識（SET未使用）（KeyIdentifier）簽發(fā)證書者證書的簽發(fā)者的甄別名（Certificat簽發(fā)證書者證書的序列號（CertificateSerialN含義：CA簽名證書所用的密鑰對的唯一標識用戶的公鑰標識（SubjectKeyIdentifier）含義：用來標識與證書中公鑰相關(guān)的特定密鑰進行解密。證書中的公鑰用途（KeyUsage）含義：用來指定公鑰用途。用戶的私鑰有效期（PrivateKeyUsagePeriod）起始日期（NoteBefore）終止日期（NoteAfter）含義：用來指定用戶簽名私鑰的起始日期和終止日期。CA承認的證書政策列表（CertificatePolicies）含義：用來指定用戶證書所適用的政策，證書政策可由對象標識符表示。用戶的代用（SubstitutionalName）含義：用來指定用戶的代用名。CA的代用名（IssuerAltName）含義：用來指定CA的代用名?；局萍s（BasicConstraints）含義：用來表明證書用戶是最終用戶還是CA。在SET系統(tǒng)中有一些私有擴充部分（擴展域）HashedRootKey含義：只在根證書中使用，用于證書更新時進行回溯。證書類型（CertificateType）含義：用來區(qū)別不同的實體。該項是必選的。商戶數(shù)據(jù)（MerchantData）含義：包含支付網(wǎng)關(guān)需要的所有商戶信息。持卡人證書需求（CardCertRequired）含義：顯示支付網(wǎng)關(guān)是否支持與沒有證書的持卡人進行交易。SET擴展（SETExtensions）含義：列出支付網(wǎng)關(guān)支持的支付命令的SET信息擴展。CRL數(shù)據(jù)定義版本（Version）含義：顯示CRL的版本號。CRL的簽發(fā)者（Issuer）含義：指明簽發(fā)CRL的CA的甄別名。CRL發(fā)布時間（thisUpdate）預計下一個CRL更新時間（NextUpdate）撤銷證書信息目錄（RevokedCertificates）CRL擴展（CRLExtension）CA的公鑰標識（AuthorityKeyIdentifier）CRL號（CRLNumber）6.SSL的應(yīng)用1．單向認證：又稱匿名SSL連接，這是SSL安全連接的最基本模式，它便于使用，主要的瀏覽器都支持這種方式，適合單向數(shù)據(jù)安全傳輸應(yīng)用。在這種模式下客戶端沒有數(shù)字證書，只是服務(wù)器端具有證書，以不在認用戶訪問的是自己要訪問的站點。典型的應(yīng)用就是用戶進行網(wǎng)站注冊時彩ID＋口令的匿名認證，過去網(wǎng)上銀行的所謂“大眾版”就是這種??因子認證。2．雙方認證：是對等的安全認證，這種模式通信雙方都可以發(fā)起和接收SSL連接請求。通信雙方可以利用安全應(yīng)用程序（控鍵）或安全代理軟件，前者一般適合于B/S結(jié)構(gòu)，而后者適用于C/S結(jié)構(gòu)，安全代理相當于一個加密/解密的網(wǎng)關(guān)，這種模式雙方皆需安裝證書，進行雙向認證。這就是網(wǎng)上銀行的B2B的專業(yè)版等應(yīng)用。顧客3．電子商務(wù)中的應(yīng)用。電子商務(wù)與網(wǎng)上銀行交易不同，因為有商戶參加，形成客戶――商家――銀行，兩次點對點的SSL連接?？蛻?，商家，銀行，都必須具證書，兩次點對點的雙向認證，如圖所示。顧客銀行商家銀行商家7.SSL協(xié)議的安全性分析SSL協(xié)議所采用的加密算法和認證算法使它具有較高的安全性，但也存在一些問題。1．SSL協(xié)議采用的加密算法和認證算法（1）加密算法和會話密鑰SSLV2協(xié)議和SSLV3協(xié)議支持的加密算法包括RC4、RC2、IDEA和DES，加密一般分三類：對稱加密、非對稱加密和單向散列函數(shù)；對稱加密：分組密碼（DES,RC5,IDEA）和序列密碼（RC4），其中CBC（cipherblockchaining）是分組密碼的一類，是指一個明文分組在被加密之前要與前一個的密文分組進行異或運算，當加密算法用于此模式的時候除密鑰外，還需協(xié)商一個初始化向量（IV），這個IV沒有實際意義，只是在第一次計算的時候需要用到而已，采用這種模式的話安全性會有所提高；單向散列函數(shù)：由于信道的破壞，一個通用的方法就是加入校驗碼。單向散列函數(shù)可用于此用途，一個典型的例子是MD5，它產(chǎn)生128位的摘要，在現(xiàn)實中用的更多的是安全散列算法（SHA），SHA的早期版本存在問題，目前用的實際是SHA-1，它可以產(chǎn)生160位的摘要，因此比128位散列更能有效抵抗窮舉攻擊。由于單向散列的算法是公開的，所以其它人可以先改動原文，再生成另外一份摘要，解決這個問題的方法可以通過HMAC，它包含了一個密鑰，只有擁有相同密鑰的人才能鑒別這個散列（2）認證算法認證算法采用X.509電子證書標準，是通過RSA算法進行數(shù)字簽名來實現(xiàn)的。服務(wù)器的認證在上述的兩對密鑰中，服務(wù)器方的寫密鑰和客戶方的讀密鑰、客戶方的寫密鑰和服務(wù)器方的讀密鑰分別是一對私有、公有密鑰。對服務(wù)器進行認證時，只有用正確的服務(wù)器方寫密鑰加密，ClientHello消息形成的數(shù)字簽名才能被客戶正確地解密，從而驗證服務(wù)器的身份。若通信雙方不需要新的密鑰，則它們各自所擁有的密鑰已經(jīng)符合上述條件。若通信雙方需要新的密鑰，首先服務(wù)器方在ServerHello消息中的服務(wù)器證書中提供了服務(wù)器的公有密鑰，服務(wù)器用其私有密鑰才能正確地解密由客戶方使用服務(wù)器的公有密鑰加密的MASTER-KEY，從而獲得服務(wù)器方的讀密鑰和寫密鑰?？蛻舻恼J證同上，只有用正確的客戶方寫密鑰加密的內(nèi)容才能被服務(wù)器方用其讀密鑰正確地解開。當客戶收到服務(wù)器方發(fā)出的REQUEST-CERTIFICATE消息時，客戶首先使用MD5消息散列函數(shù)獲得服務(wù)器方信息的摘要，服務(wù)器方的信息包括：KEY-MATERIAL-0、KEY-MATERIAL-1、KEY-MATERIAL-2、CERTIFICATE-CHALLENAGE-DATA（來自于REQUEST-CERTIFICATE消息）、服務(wù)器所賦予的證書（來自于ServerHello）消息。其中KEY-MATERIAL-l、KEY-MATERIAL-2是可選的，與具體的加密算法有關(guān)。然后客戶使用自己的讀密鑰加密摘要形成數(shù)字簽名，從而被服務(wù)器認證。2．SSL安全優(yōu)勢（1）監(jiān)聽和中間人式攻擊SSL使用一個經(jīng)過通信雙方協(xié)商確定的加密算法和密鑰，對不同的安全級別應(yīng)用都可找到不同的加密算法，從而用于數(shù)據(jù)加密。它的密鑰管理處理比較好，在每次連接時通過產(chǎn)生一個密碼雜湊函數(shù)生成一個臨時使用的會話密鑰，除了不同連接使用不同密鑰外，在一次連接的兩個傳輸方向上也使用各自的密鑰。盡管SSL協(xié)議為監(jiān)聽者提供了很多明文，但由于采用RSA交換密鑰具有較好的密鑰保護性能，以及頻繁更換密鑰的特點，因此對監(jiān)聽和中間人式攻擊而言，具有較高的防范性。（2）流量數(shù)據(jù)分析式攻擊流量數(shù)據(jù)分析式攻擊的核心是通過檢查數(shù)據(jù)包的未加密字段或未加保護的數(shù)據(jù)包屬性，試圖進行攻擊。在一般情況下該攻擊是無害的，SSL無法阻止這種攻擊。（3）截取再拼接式攻擊對需要較強的連接加密，需要考慮這種安全性。SSLV3.0基本上可阻止這種攻擊。（4）報文重發(fā)式攻擊報文重發(fā)式攻擊比較容易阻止，SSL通過在MAC數(shù)據(jù)中包含“系列號”來防止該攻擊。3．SSL協(xié)議存在的問題（1）密鑰管理問題設(shè)計一個安全秘密的密鑰交換協(xié)議是很復雜的，因此，SSL的握手協(xié)議也存在一些密鑰管理問題。SSL的問題表現(xiàn)在：客戶機和服務(wù)器在互相發(fā)送自己能夠支持的加密算法時，是以明文傳送的，存在被攻擊修改的可能。SSLV3.0為了兼容以前的版本，可能降低安全性。所有的會話密鑰中都將生成MASTER-KEY，握手協(xié)議的安全完全依賴于對MASTER-KEY的保護，因此在通信中要盡可能少地使用MASTER-KEY。（2）加密強度問題Netscape依照美國內(nèi)政部的規(guī)定，在它的國際版的瀏覽器及服務(wù)器上使用40位的密鑰。以SSL所使用的RC4演繹法所命名的RC4法規(guī)，對多于40位長的加密密鑰產(chǎn)品的出口加以限制，這項規(guī)定使Netscape的128位加密密鑰在美國之外的地方變成不合法。一個著名的例子是一個法國的研究生和兩個美國柏克萊大學的研究生破譯了一個SSL的密鑰，才使人們開始懷疑以SSL為基礎(chǔ)的系統(tǒng)安全性。Microsoft公司想利用一種稱為私人通信技術(shù)（PCT,PrivateCommunicationTechnology）的SSLsuperset協(xié)議來改進SSL的缺點。PCT會衍生出第二個專門為身份驗證用的密鑰，這個身份驗證并不屬于RC4規(guī)定的管轄范圍。PCT加入比目前隨機數(shù)產(chǎn)生器更安全的產(chǎn)生器，因為它也是SSL安全鏈中的一個弱環(huán)節(jié)。這個隨機數(shù)產(chǎn)生器提供了產(chǎn)生加密密鑰的種子數(shù)目（SeedNumber）。（3）數(shù)字簽名問題SSL協(xié)議沒有數(shù)字簽名功能，即沒有抗否認服務(wù)。若要增加數(shù)字簽名功能，則需要在協(xié)議中打“補丁”。這樣做，在用于加密密鑰的同時又用于數(shù)字簽名，這在安全上存在漏洞。后來PKI體系完善了這種措施，即雙密鑰機制，將加密密鑰和數(shù)字簽名密鑰二者分開，成為雙證書機制。這是PKI完整的安全服務(wù)體參考文獻:[1]羅新星等:電子支付系統(tǒng)的安全性研究及其設(shè)計[J].武漢理工大學學報,2021,25(1)[2]代曉紅:基于SSL協(xié)議的電子商務(wù)安全性分析[J].工業(yè)技術(shù)經(jīng)濟,2021,23(6)[3]黃勁潮:SSL安全通信在電子商務(wù)中的應(yīng)用[J].中國科技信息,2021(12)[4]姜慶娜:基于Internet的電子商務(wù)安全支付系統(tǒng)的研究[D].山東師范大學,2021[5]寇曉蕤：網(wǎng)絡(luò)安全協(xié)議[J].高等教育出版社，2021（1）

鉆井工程承包合同甲方：＿＿＿＿＿＿＿

乙方：＿＿＿＿＿＿＿

雙方經(jīng)充分協(xié)商，達成如下協(xié)議：

第一條總則

第一、井位

１．鉆井施工地點：＿＿＿＿?。撸撸撸呤校撸撸撸呖h＿＿＿＿鄉(xiāng)

２．地形圖

３．井位設(shè)計圖

４．地層構(gòu)造圖

第二、國家、部、局對鉆進工程施工的批準投資計劃、工程項目，設(shè)計任務(wù)書等文件號及影印件。

第三、井別：

第四、鉆井口數(shù)：

第五、井深結(jié)構(gòu)：

第六、質(zhì)量：

１．井身質(zhì)量合格率

２．固井質(zhì)量合格率

第七、價格

１．調(diào)整井單價＿＿＿元／米，合計金額＿＿＿＿＿萬元

２．開發(fā)井單價＿＿＿元／米，合計金額＿＿＿＿＿萬元

第二條工程期限本合同鉆井工程自＿＿＿＿年＿＿月＿＿日開鉆至＿＿＿＿年＿＿月＿＿日全部鉆完。在組織鉆井工程施工中，如遇下列情況，得順延工期，雙方應(yīng)及時進行協(xié)商，并通過書面形式確定順延期限；第一、因天災或人力不能抗拒的原因被迫停工者；第二、因甲方提出變更計劃或更變施工圖而不能繼續(xù)施工者；第三、因甲方不能按期提供技術(shù)文件、技術(shù)圖紙和鉆井施工條件，被迫停工或不能繼續(xù)施工者。第三條鉆前準備第一、甲方在開鉆前應(yīng)辦妥征地拆遷和井場道路的墊方；清除施工場地及進出道路范圍內(nèi)影響施工的原有建筑物、構(gòu)筑物、管線、樹木、青苗等阻礙物。解決施工用的水、電和鉆機安裝搬運的道路。第二、甲方按時向乙方交付井位設(shè)計、完鉆井深、層位和完井要求，負責鉆井區(qū)塊的斷層分布圖；斷層數(shù)據(jù)；小層平面圖；構(gòu)造圖和鄰井圖壓力資料數(shù)據(jù)，并向乙方進行地質(zhì)和工程技術(shù)要求交底。第三、乙方在開鉆前應(yīng)組織有關(guān)技術(shù)人員學習和熟悉各種設(shè)計圖紙，參加地質(zhì)設(shè)計交底，編好施工圖預算，負責安排鉆機運行計劃，施工方案，做好一切施工準備。第四條工程款結(jié)算第一、按不同的機型、井別、井深、另加風險金，確定承包費用。對承包范圍以外的費用，按規(guī)定結(jié)算。第二、本合同自簽訂生效之日起，甲方應(yīng)在＿＿＿＿日內(nèi)按工程費用總額＿＿＿＿元的百分之＿＿＿＿一次撥給乙方，作為乙方備料及施工費。第五條施工與設(shè)計變更第一、乙方在組織施工中，必須為油田開發(fā)著想，嚴格按照部、局頒發(fā)的施工驗收規(guī)范和質(zhì)量檢驗標準，以及設(shè)計要求組織施工。