第七講傳輸層安全提綱TCP/IP安全方法SSLTLSHTTPSSSHTCP/IP安全方法TCP/IP協(xié)議棧中的安全設(shè)施的相對(duì)位置Ipsec的好處是對(duì)終端用戶和應(yīng)用是透明的，能提供一種一般性的解決方案SSL或TLS都是可執(zhí)行協(xié)議軟件包的一部分，從而對(duì)應(yīng)用是透明的，Netscape進(jìn)而IE都配置了SSL。大部分Web服務(wù)器都實(shí)現(xiàn)了該協(xié)議。SSL(SecureSocketLayer)SSL(SecuritySocketLayer安全套接層)最初1994年Netscape開發(fā),專門用于保護(hù)Web通訊.保護(hù)瀏覽器和服務(wù)器之間的通信,在客戶和服務(wù)器之間提供服務(wù)器鑒別、可選客戶鑒別和加密通信信道。使用TCP提供一種可靠的端對(duì)端的安全服務(wù)。版本和歷史1.0，不成熟2.0，基本上解決了Web通訊的安全問題Microsoft公司發(fā)布了PCT(PrivateCommunicationTechnology)，并在IE中支持3.0，1996年發(fā)布，增加了一些算法，修改了一些缺陷TLS1.0(TransportLayerSecurity傳輸層安全協(xié)議,也被稱為SSL3.1)，1997年IETF發(fā)布了Draft，同時(shí)，Microsoft宣布放棄PCT，與Netscape一起支持TLS1.01999年，發(fā)布RFC2246(TheTLSProtocolv1.0)功能客戶端驗(yàn)證服務(wù)器客戶段與服務(wù)器選擇彼此支持的算法服務(wù)器驗(yàn)證客戶端（可選）使用公開密鑰算法產(chǎn)生共享的密鑰SSL連接建立VersionSourceDescriptionBrowserSupportSSLv2.0VendorStandard(fromNetscapeCorp.)[SSL2]FirstSSLprotocolforwhichimplementationsexist-NSNavigator1.x/2.x-MSIE3.x-Lynx/2.8+OpenSSLSSLv3.0ExpiredInternetDraft(fromNetscapeCorp.)[SSL3]Revisionstopreventspecificsecurityattacks,addnon-RSAciphersandsupportforcertificatechains-NSNavigator2.x/3.x/4.x-MSIE3.x/4.x-Lynx/2.8+OpenSSLTLSv1.0ProposedInternetStandard(fromIETF)[TLS1]RevisionofSSL3.0toupdatetheMAClayertoHMAC,addblockpaddingforblockciphers,messageorderstandardizationandmorealertmessages.-Lynx/2.8+OpenSSLSSL協(xié)議的版本SSL3.0增加了對(duì)證書鏈加載的支持。使服務(wù)器可以將自己的服務(wù)器證書和發(fā)行者的證書一起傳給瀏覽器。證書鏈的加載，使得客戶機(jī)即使沒有安裝過服務(wù)器的中間證書，也可以來驗(yàn)證服務(wù)器證書的有效性，因?yàn)榉?wù)器的中間證書被放在證書鏈中一起發(fā)送給了客戶機(jī)。SSL2.0協(xié)議只適用RSA密鑰交換方式，而SSL3.0不僅支持RSA密鑰交換（在使用證書的情況下），還支持Diffie-Hellman密鑰交換（在沒有使用證書或者沒有客戶端和服務(wù)器之間通信密鑰之前的情況下。）7層模型的第4層(傳輸層）實(shí)際上在四層的上部:TCP不需要更改操作系統(tǒng)TCP提供了可靠的消息傳輸SSL協(xié)議的位置SSL協(xié)議可用于保護(hù)正常運(yùn)行于TCP之上的任何應(yīng)用協(xié)議，如HTTP、FTP、SMTP或Telnet的通信，最常見的是用SSL來保護(hù)HTTP的通信。協(xié)議的使用https://與shttp://SSLArchitecture包括SSL記錄協(xié)議和三個(gè)高層協(xié)議（握手協(xié)議、密鑰更改規(guī)格協(xié)議、報(bào)警協(xié)議）SSL記錄協(xié)議對(duì)各種更高級(jí)的協(xié)議提供基本的安全服務(wù)。SSLconnectionatransient,peer-to-peer,communicationslinkassociatedwith1SSLsessionSSLsessionanassociationbetweenclient&servercreatedbytheHandshakeProtocoldefineasetofcryptographicparametersmaybesharedbymultipleSSLconnections

避免每條連接需要進(jìn)行的代價(jià)高昂的新的安全參數(shù)協(xié)商過程SSL參數(shù)會(huì)話狀態(tài)參數(shù)會(huì)話標(biāo)識(shí)符：由服務(wù)器產(chǎn)生用于標(biāo)識(shí)活動(dòng)的或可恢復(fù)的會(huì)話狀態(tài)的一個(gè)任意字節(jié)序列對(duì)等證書：對(duì)等的X.509V3證書壓縮方法：加密前用于壓縮數(shù)據(jù)的算法密碼規(guī)格：大塊數(shù)據(jù)加密算法，計(jì)算MAC的散列算法主密鑰：48字節(jié)的會(huì)話密鑰可恢復(fù)性：能否把會(huì)話用于創(chuàng)建新連接的標(biāo)志比特連接狀態(tài)參數(shù)服務(wù)器和客戶端隨機(jī)數(shù)：服務(wù)器寫MAC密鑰：服務(wù)器發(fā)送數(shù)據(jù)時(shí)用于計(jì)算MAC的密鑰客戶端寫MAC密鑰：客戶端發(fā)送數(shù)據(jù)時(shí)用于計(jì)算MAC的密鑰服務(wù)器寫密鑰：服務(wù)器用于加密數(shù)據(jù)、客戶端用于解密數(shù)據(jù)的密鑰客戶端寫密鑰：客戶端用于加密數(shù)據(jù)、服務(wù)器用于解密數(shù)據(jù)的密鑰初始化向量：當(dāng)CBC模式中的數(shù)據(jù)塊正在使用時(shí)，需要為每個(gè)密鑰配置一個(gè)初始化向量。之后的IV值為前一次分組密碼算法的最后一個(gè)密文分組序列號(hào)SSLRecordProtocolServicesConfidentiality機(jī)密性u(píng)singsymmetricencryptionwithasharedsecretkeydefinedbyHandshakeProtocolAES,IDEA,RC2-40,DES-40,DES,3DES,Fortezza,RC4-40,RC4-128messageiscompressedbeforeencryptionmessageintegrity消息完整性u(píng)singaMACwithsharedsecretkeysimilartoHMACbutwithdifferentpaddingSSL記錄協(xié)議每個(gè)這樣的段最大為2^14-1=16383個(gè)字節(jié)。從原始數(shù)據(jù)段到生成SSL明文分段、SSL壓縮、SSL密文（加密步驟）SSL記錄格式SSL記錄頭部包括：內(nèi)容類型（8位）--可以是修改密碼協(xié)議、報(bào)警協(xié)議、握手協(xié)議、應(yīng)用數(shù)據(jù)四種主版本號(hào)（8位）副版本號(hào)（8位）壓縮長(zhǎng)度（16位）-以字節(jié)為單位的明文分段（壓縮分段）長(zhǎng)度ContentTypeMajorVersionMinorVersionCompressedLengthPlaintext(optionallycompressed)MAC(0,16,or20bytes)Encrypted1(a)ChangeCipherSpecProtocol1byte(c)HandshakeProtocolType1byteLengthContent3bytes3bytes(b)AlertProtocolLevel1byteAlert1byte(d)OtherUpperLayerProtocolasTLSPayloadContentUpto214+2048bytesSSL記錄協(xié)議負(fù)載SSL修改密文協(xié)議協(xié)議由單個(gè)消息組成,該消息只包含一個(gè)值為1的單個(gè)字節(jié)。該消息的唯一作用就是使未決狀態(tài)拷貝為當(dāng)前狀態(tài),更新用于當(dāng)前連接的密碼組。為了保障SSL傳輸過程的安全性,雙方應(yīng)該每隔一段時(shí)間改變加密規(guī)范。SSL告警協(xié)議為對(duì)等實(shí)體傳遞SSL的相關(guān)警告。如果在通信過程中某一方發(fā)現(xiàn)任何異常,就需要給對(duì)方發(fā)送一條警示消息通告。警示消息有兩種

Fatal錯(cuò)誤,如傳遞數(shù)據(jù)過程中,發(fā)現(xiàn)錯(cuò)誤的MAC,雙方就需要立即中斷會(huì)話,同時(shí)消除自己緩沖區(qū)相應(yīng)的會(huì)話記錄;

Warning消息,這種情況,通信雙方通常都只是記錄日志,而對(duì)通信過程不造成任何影響。（對(duì)警告的內(nèi)容做了相關(guān)的約定）SSL握手協(xié)議1使得服務(wù)器和客戶能夠相互鑒別對(duì)方,協(xié)商具體的加密算法和MAC算法以及保密密鑰,用來保護(hù)在SSL記錄中發(fā)送的數(shù)據(jù)SSL握手協(xié)議允許通信實(shí)體在交換應(yīng)用數(shù)據(jù)之前協(xié)商密鑰的算法、加密密鑰和對(duì)客戶端進(jìn)行認(rèn)證（可選）的協(xié)議，為下一步記錄協(xié)議要使用的密鑰信息進(jìn)行協(xié)商，使客戶端和服務(wù)器建立并保持安全通信的狀態(tài)信息。SSL握手協(xié)議是在任何應(yīng)用程序數(shù)據(jù)傳輸之前使用的。SSL握手協(xié)議包含四個(gè)階段:建立安全能力;服務(wù)器鑒別和密鑰交換;客戶鑒別和密鑰交換;完成握手協(xié)議。建立安全能力服務(wù)器認(rèn)證和密鑰交換客戶端認(rèn)證和密鑰交換完成SSL握手協(xié)議細(xì)節(jié)第一階段客戶端發(fā)起建立連接請(qǐng)求Client_hello消息

Version：客戶端SSL的最高版本號(hào)Random：隨機(jī)序列32位時(shí)間戳+28字節(jié)隨機(jī)數(shù)（防重放攻擊），用于生成主秘密。SessionID:會(huì)話ID非零值表示用戶希望重用現(xiàn)有會(huì)話的參數(shù)；零值表示客戶端希望建立新的會(huì)話ID并協(xié)商安全參數(shù)

CipherSuite:密碼構(gòu)件，客戶端可以支持的密碼算法組合（以優(yōu)先遞減順序給出）CompressionMethod:客戶端支持的壓縮方法列表ServerHello信息Version：取客戶端支持的最高版本號(hào)和服務(wù)端支持的最高版本號(hào)中的較低者。Random：用于生成主秘密的32字節(jié)的隨機(jī)數(shù)。（客戶端一個(gè)、服務(wù)端一個(gè)）會(huì)話ID：如果client_hello中的會(huì)話ID非零，則差找相應(yīng)存儲(chǔ)的會(huì)話參數(shù)，反饋用原值，為零則產(chǎn)生一個(gè)新的會(huì)話ID從客戶端的密碼套件列表中選擇的一個(gè)密碼套件，若用原會(huì)話ID，則直接用相應(yīng)參數(shù)從客戶端的壓縮方法的列表中選擇的壓縮方法SSL握手協(xié)議細(xì)節(jié)密碼套件列表參數(shù)密鑰交換方法（6種：無效（沒有密鑰交換）、RSA、匿名Diffie-Hellman、EphemeralDiffie-Hellman、FixedDiffie-Hellman、Fortezza）；

塊加密算法（AES,IDEA,RC2-40,DES-40,DES,3DES,Fortezza,RC4-40,RC4-128）MAC算法（MD5，SHA-1）FixedDiffie-Hellman

公鑰證書中包含固定的Diffie-Hellman公鑰參數(shù)EphemeralDiffie-Hellman

Diffie-Hellman公鑰參數(shù)使用發(fā)送者的RSA私鑰或DSS密鑰的方式被交換和簽名，可以獲得一個(gè)臨時(shí)的被認(rèn)證的密鑰SSL握手協(xié)議細(xì)節(jié)列舉JSSE支持的幾個(gè)套件：

SSL_RSA_WITH_RC4_128_MD5=0x0004

/*非對(duì)稱加密算法或密鑰交換算法為RSA，采用高強(qiáng)度128位對(duì)稱加密算法RC4，摘要或MAC算法為MD5，不支持出口*/

SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA=0x0014

/*非對(duì)稱加密算法或密鑰交換算法支持RSA和DH，采用40位對(duì)稱加密算法DES，摘要或MAC算法為SHA，可以出口*/

JSSE，即Java(TM)SecureSocketExtension。JSSE是基于安全算法和握手機(jī)制之上的合成體。JSSE將危險(xiǎn)的安全弱點(diǎn)降到最低點(diǎn)，并且它減輕了開發(fā)者的負(fù)擔(dān)，使得開發(fā)者可以很輕松的整合到程序中。

SSL(SecureSocketsLayer)是JSSE中的重要的部分。OpenSSL采用C語言作為開發(fā)語言，這使得OpenSSL具有優(yōu)秀的跨平臺(tái)性能，這對(duì)于廣大技術(shù)人員來說是一件非常美妙的事情，可以在不同的平臺(tái)使用同樣熟悉的東西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平臺(tái)，這使得OpenSSL具有廣泛的適用性。1998年，OpenSSL項(xiàng)目組接管了OpenSSL的開發(fā)工作，并推出了OpenSSL的0.9.1版，到目前為止，OpenSSL的算法已經(jīng)非常完善，對(duì)SSL2.0、SSL3.0以及TLS1.0都支持。SSL握手協(xié)議細(xì)節(jié)第二階段服務(wù)器認(rèn)證和密鑰交換證書：服務(wù)器將數(shù)字證書和到根CA整個(gè)鏈發(fā)給客戶端，使客戶端能用服務(wù)器證書中的服務(wù)器公鑰認(rèn)證服務(wù)器。服務(wù)器密鑰交換（可選）：這里視密鑰交換算法而定證書請(qǐng)求：服務(wù)端可能會(huì)要求客戶自身進(jìn)行驗(yàn)證。服務(wù)器握手完成：第二階段的結(jié)束，第三階段開始的信號(hào)SSL握手協(xié)議細(xì)節(jié)如果協(xié)商過程中確定使用RSA交換密鑰，SSL握手協(xié)議細(xì)節(jié)證書（可選）：為了對(duì)服務(wù)器證明自身，客戶要發(fā)送一個(gè)證書信息，這是可選的，在IIS中可以配置強(qiáng)制客戶端證書認(rèn)證?？蛻魴C(jī)密鑰交換（Pre-master-secret）：這里客戶端將預(yù)備主密鑰發(fā)送給服務(wù)端，注意這里會(huì)使用服務(wù)端的公鑰進(jìn)行加密。證書驗(yàn)證（可選），對(duì)預(yù)備秘密和隨機(jī)數(shù)進(jìn)行簽名，證明自己擁有證書的私鑰。SSL握手協(xié)議細(xì)節(jié)Client發(fā)送消息給服務(wù)器確認(rèn)將來客戶端將會(huì)用會(huì)話密鑰,然后客戶端發(fā)送一個(gè)消息（加密的）指示服務(wù)器客戶端握手部分結(jié)束。Server發(fā)送消息給客戶端確認(rèn)服務(wù)器端將會(huì)使用會(huì)話秘鑰,然后服務(wù)端發(fā)送一個(gè)消息（加密的）指示客戶端服務(wù)器握手部分結(jié)束。SSL握手結(jié)束，SSL會(huì)話開始。C與S使用會(huì)話密鑰來加解密相互發(fā)送的數(shù)據(jù)以及驗(yàn)證消息的完整性。CryptographicComputationsmastersecretcreationaone-time48-bytevaluegeneratedusingsecurekeyexchange(RSA/Diffie-Hellman)andthenhashinginfogenerationofcryptographicparametersclientwriteMACsecret,aserverwriteMACsecret,aclientwritekey,aserverwritekey,aclientwriteIV,andaserverwriteIV

generatedbyhashingmastersecret密鑰計(jì)算過程SSL協(xié)議安全性分析鑒別機(jī)制公開密鑰技術(shù)和數(shù)字證書可以實(shí)現(xiàn)客戶端和服務(wù)器端的身份鑒別。加密機(jī)制

混合密碼體制的使用提供了會(huì)話和數(shù)據(jù)傳輸?shù)募用苄员Ｗo(hù)。雙方使用非對(duì)稱密碼體制協(xié)商出本次將要使用的會(huì)話密鑰，并選擇一種對(duì)稱加密算法。完整性機(jī)制

定義了共享的、可以用來形成報(bào)文鑒別碼MAC的密鑰。數(shù)據(jù)進(jìn)行分片壓縮后，使用單向散列函數(shù)產(chǎn)生一個(gè)MAC，加密后置于數(shù)據(jù)包的后部，并且再一次和數(shù)據(jù)一起被加密,然后加上SSL首部進(jìn)行網(wǎng)絡(luò)傳輸。 這樣，如果數(shù)據(jù)被修改，其散列值就無法和原來的MAC相匹配，從而保證了數(shù)據(jù)的完整性?？怪胤殴?/p>

SSL使用序列號(hào)來保護(hù)通信方免受報(bào)文重放攻擊。這個(gè)序列號(hào)被加密后作為數(shù)據(jù)包的負(fù)載。 在整個(gè)SSL握手中，都有一個(gè)唯一的隨機(jī)數(shù)來標(biāo)記這個(gè)SSL握手，這樣重放便無機(jī)可乘。SSL協(xié)議安全性分析SSL脆弱性分析客戶端假冒因?yàn)镾SL協(xié)議設(shè)計(jì)初衷是對(duì)Web站點(diǎn)及網(wǎng)上交易進(jìn)行安全性保護(hù)，使消費(fèi)者明白正在和誰進(jìn)行交易要比使商家知道誰正在付費(fèi)更為重要，為了不致于由于安全協(xié)議的使用而導(dǎo)致網(wǎng)絡(luò)性能大幅下降，SSL協(xié)議并不是默認(rèn)地要求進(jìn)行客戶鑒別，這樣做雖然有悖于安全策略，但卻促進(jìn)了SSL的廣泛應(yīng)用。針對(duì)這個(gè)問題，可在必要的時(shí)候配置SSL協(xié)議，使其選擇對(duì)客戶端進(jìn)行認(rèn)證鑒別。無法提供基于UDP應(yīng)用的安全保護(hù)SSL協(xié)議需要在握手之前建立TCP連接，因此不能對(duì)UDP應(yīng)用進(jìn)行保護(hù)。如果要兼顧UDP協(xié)議層之上的安全保護(hù)，可以采用IP層的安全解決方案。SSL協(xié)議不能對(duì)抗通信流量分析由于SSL只對(duì)應(yīng)用數(shù)據(jù)進(jìn)行保護(hù)，數(shù)據(jù)包的IP頭和TCP頭仍然暴露在外，通過檢查沒有加密的IP源和目的地址以及TCP端口號(hào)或者檢查通信數(shù)據(jù)量，一個(gè)通信分析者依然可以揭示哪一方在使用什么服務(wù)，有時(shí)甚至揭露商業(yè)或私人關(guān)系的秘密。進(jìn)程中主密鑰泄漏除非SSL的工程實(shí)現(xiàn)大部分駐留在硬件中，否則主密鑰將會(huì)存留在主機(jī)的主存儲(chǔ)器中，這就意味著任何可以讀取SSL進(jìn)程存儲(chǔ)空間的攻擊者都能讀取主密鑰，因此，不可能面對(duì)掌握機(jī)器管理特權(quán)的攻擊者而保護(hù)SSL連接，這個(gè)問題要依靠用戶管理策略來解決。SSL脆弱性分析磁盤上的臨時(shí)文件可能遭受攻擊對(duì)于使用虛擬內(nèi)存的操作系統(tǒng)，不可避免地有些敏感數(shù)據(jù)甚至主密鑰都交換到存盤上，可采取內(nèi)存加鎖和及時(shí)刪除磁盤臨時(shí)文件等措施來降低風(fēng)險(xiǎn)安全盲點(diǎn)系統(tǒng)管理員不能使用現(xiàn)有的安全漏洞掃描或網(wǎng)絡(luò)入侵檢測(cè)系統(tǒng)來審查或監(jiān)控網(wǎng)絡(luò)上的SSL交易。加密技術(shù)使得通過網(wǎng)絡(luò)傳輸?shù)男畔o法讓IDS辨認(rèn).使得最重要的服務(wù)器反而成為受到最少防護(hù)的服務(wù)器。對(duì)此，惡意代碼檢測(cè)、增強(qiáng)的日志功能等基于主機(jī)的安全策略會(huì)成為最后防線。SSL脆弱性分析SSL的評(píng)價(jià)SSL仍然不失為一套全面完善的安全策略中有效的組成元素。然而，與網(wǎng)絡(luò)安全的其它工具軟件一樣，僅使用單一的防護(hù)軟件都是遠(yuǎn)遠(yuǎn)不夠的。對(duì)SSL的過高評(píng)價(jià)有可能帶來高的安全風(fēng)險(xiǎn)，它僅僅是網(wǎng)絡(luò)安全工具的一種，必須和其它網(wǎng)絡(luò)安全工具緊密結(jié)合，方能構(gòu)造出全面、完善、安全可靠的網(wǎng)絡(luò)。傳輸層安全（TLS）RFC5246非常接近于SSLv3記錄格式與SSL完全相同不同消息認(rèn)證碼的計(jì)算使用了RFC2104定義的HMAC算法；而SSL也使用相同算法，只是填充部分采用了與密鑰串接的方式而不是異或方式，安全強(qiáng)度基本相同定義了更多的報(bào)警碼密鑰構(gòu)建細(xì)小差別TLS不支持Fortezza密鑰計(jì)算HTTPsHTTP和SSL結(jié)合實(shí)現(xiàn)網(wǎng)絡(luò)瀏覽器和服務(wù)器之間的安全通信，RFC2818HTTPS和HTTP的區(qū)別https協(xié)議需要到CA申請(qǐng)證書，一般免費(fèi)證書很少，需要交費(fèi)。http信息是明文傳輸，https則是具有安全性的SSL加密傳輸協(xié)議。http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。http的連接很簡(jiǎn)單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。HTTPs解決的問題信任主機(jī)的問題.采用https的服務(wù)器必須從CA申請(qǐng)一個(gè)用于證明服務(wù)器用途類型的證書。目前所有的銀行系統(tǒng)網(wǎng)站，關(guān)鍵部分應(yīng)用都是https的。客戶通過信任該證書，從而信任了該主機(jī)。通訊過程中的數(shù)據(jù)的泄密和被篡改一般意義上的https，就是服務(wù)器有一個(gè)證書。保證服務(wù)器是他聲稱的服務(wù)器。

服務(wù)端和客戶端之間的所有通訊，都是加密的?？蛻舳水a(chǎn)生一對(duì)稱的密鑰，通過服務(wù)器的證書來交換密鑰所有的信息往來都加密

少許對(duì)客戶端有要求的情況下，會(huì)要求客戶端也必須有一個(gè)證書。除了用戶名/密碼，還有一個(gè)CA認(rèn)證過的身份。個(gè)人銀行的專業(yè)版是這種做法，具體證書可能是拿U盤（即U盾）作為一個(gè)備份的載體。SSH（SecureShell

）一、信任主機(jī)的問題.采用https的服務(wù)器必須從CA（CertificateAuthority）申請(qǐng)一個(gè)用于證明服務(wù)器用途類型的證書。該證書只有用于對(duì)應(yīng)的服務(wù)器的時(shí)候，客戶端才信任此主機(jī)。所以目前所有的銀行系統(tǒng)網(wǎng)站，關(guān)鍵部分應(yīng)用都是https的?？蛻敉ㄟ^信任該證書，從而信任了該主機(jī)。其實(shí)這樣做效率很低，但是銀行更側(cè)重安全。這一點(diǎn)對(duì)我們沒有任何異議，我們的服務(wù)器，采用的證書不管是自己發(fā)布的還是從公眾的地方發(fā)布的，其客戶端都是自己人，所以我們也就肯定信任該服務(wù)器。二、通訊過程中的數(shù)據(jù)的泄密和被篡改1．一般意義上的https，就是服務(wù)器有一個(gè)證書。a)主要目的是保證服務(wù)器就是他聲稱的服務(wù)器，這個(gè)跟第一點(diǎn)一樣。b)

服務(wù)端和客戶端之間的所有通訊，都是加密的。i.具體講，是客戶端產(chǎn)生一個(gè)對(duì)稱的密鑰，通過服務(wù)器的證書來交換密鑰，即一般意義上的握手過程。ii.接下來所有的信息往來就都是加密的。第三方即使截獲，也沒有任何意義，因?yàn)樗麤]有密鑰，當(dāng)然篡改也就沒有什么意義了。2．少許對(duì)客戶端有要求的情況下，會(huì)要求客戶端也必須有一個(gè)證書。a)這里客戶端證書，其實(shí)就類似表示個(gè)人信息的時(shí)候，除了用戶名/密碼，還有一個(gè)CA認(rèn)證過的身份。因?yàn)閭€(gè)人證書一般來說是別人無法模擬的，所有這樣能夠更深的確認(rèn)自己的身份。b)目前少數(shù)個(gè)人銀行的專業(yè)版是這種做法，具體證書可能是拿U盤（即U盾）作為一個(gè)備份的載體。

[protocolforsecurenetworkcommunicationsdesignedtobesimple&inexpensiveSSH1providedsecureremotelogonfacilityreplaceTELNET&otherinsecureschemesalsohasmoregeneralclient/servercapabilitySSH2fixesanumberofsecurityflawsdocumentedinRFCs4250through4254SSHclients&serversarewidelyavailablemethodofchoiceforremotelogin/XtunnelsSSH是目前較可靠，專為遠(yuǎn)程登錄會(huì)話和其他網(wǎng)絡(luò)服務(wù)提供安全性的協(xié)議。利用SSH協(xié)議可以有效防止遠(yuǎn)程管理過程中的信息泄露問題。SSH最初是UNIX系統(tǒng)上的一個(gè)程序，后來又迅速擴(kuò)展到其他操作平臺(tái)。SSH客戶端適用于多種平臺(tái)。

幾乎所有UNIX平臺(tái)—包括HP-UX、Linux、AIX、Solaris、DigitalUNIX、Irix，以及其他平臺(tái)—都可運(yùn)行SSH。SSH（SecureShell

）SSH（SecureShell

）SSHTransportLayerProtocolserverauthenticationoccursattransportlayer,basedonserver/hostkeypair(s)serverauthenticationrequiresclientstoknowhostkeysinadvance（客戶端本地?cái)?shù)據(jù)庫(kù)保存，服務(wù)器公鑰或者CA根密鑰）packetexchangeestablishTCPconnectioncanthenexchangedataidentificationstringexchange（識(shí)別字符串交換）這些字符用于Diffie-Hellman密鑰交換,algorithmnegotiation（算法協(xié)商）給出算法清單,包括密鑰交換、加密、MAC算法和壓縮算法（p136）

keyexchange（密鑰交換）,Diffie-Hellman服務(wù)器用私鑰簽名endofkeyexchange,（密鑰生成-協(xié)商后的密鑰做hash運(yùn)算）servicerequest請(qǐng)求獲得身份認(rèn)證usingspecifiedpacketformat（分組長(zhǎng)度、填充域長(zhǎng)度、壓縮的有效載荷、SSHUserAuthenticationProtocolauthenticatesclienttoserverthreemessagetypes:SSH_MSG_USERAUTH_REQUESTSSH_MSG_USERAUTH_FAILURESSH_MSG_USERAUTH_SUCCESSauthe