第7講傳輸層安全_第1頁
第7講傳輸層安全_第2頁
第7講傳輸層安全_第3頁
第7講傳輸層安全_第4頁
第7講傳輸層安全_第5頁
已閱讀5頁,還剩41頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

1、第七講第七講 傳輸層安全傳輸層安全提綱提綱TCP/IP安全方法SSLTLSHTTPSSSHTCP/IPTCP/IP安全方法安全方法TCP/IP協(xié)議協(xié)議 棧中的安全設(shè)施的相對位置棧中的安全設(shè)施的相對位置Ipsec的好處是對終端用戶和應(yīng)用是透明的,能提供一種一般性的解決方案SSL或TLS都是可執(zhí)行協(xié)議軟件包的一部分,從而對應(yīng)用是透明的,Netscape進(jìn)而IE都配置了SSL。大部分Web服務(wù)器都實(shí)現(xiàn)了該協(xié)議。SSL (Secure Socket Layer)SSL(Security Socket Layer 安全套接層) 最初1994年Netscape開發(fā),專門用于保護(hù)Web通訊.保護(hù)瀏覽器和服務(wù)

2、器之間的通信,在客戶和服務(wù)器之間提供服務(wù)器鑒別、可選客戶鑒別和加密通信信道。使用TCP提供一種可靠的端對端的安全服務(wù)。版本和歷史 1.0,不成熟 2.0,基本上解決了Web通訊的安全問題Microsoft公司發(fā)布了PCT(Private Communication Technology),并在IE中支持 3.0,1996年發(fā)布,增加了一些算法,修改了一些缺陷 TLS 1.0(Transport Layer Security傳輸層安全協(xié)議, 也被稱為SSL 3.1),1997年IETF發(fā)布了Draft,同時(shí),Microsoft宣布放棄PCT,與Netscape一起支持TLS 1.0 1999年,

3、發(fā)布RFC 2246(The TLS Protocol v1.0)功能 客戶端驗(yàn)證服務(wù)器 客戶段與服務(wù)器選擇彼此支持的算法 服務(wù)器驗(yàn)證客戶端(可選) 使用公開密鑰算法產(chǎn)生共享的密鑰 SSL連接建立VersionSourceDescriptionBrowser SupportSSL v2.0Vendor Standard (from Netscape Corp.) SSL2First SSL protocol for which implementations exist- NS Navigator 1.x/2.x- MS IE 3.x- Lynx/2.8+OpenSSLSSL v3.0Expi

4、red Internet Draft (from Netscape Corp.) SSL3Revisions to prevent specific security attacks, add non-RSA ciphers and support for certificate chains- NS Navigator 2.x/3.x/4.x- MS IE 3.x/4.x- Lynx/2.8+OpenSSLTLS v1.0Proposed Internet Standard (from IETF) TLS1Revision of SSL 3.0 to update the MAC layer

5、 to HMAC, add block padding for block ciphers, message order standardization and more alert messages.- Lynx/2.8+OpenSSLSSL協(xié)議的版本協(xié)議的版本SSL3.0 增加了對證書鏈加載的支持。使服務(wù)器可以將自己的服務(wù)器證書和發(fā)行者的證書一起傳給瀏覽器。證書鏈的加載,使得客戶機(jī)即使沒有安裝過服務(wù)器的中間證書,也可以來驗(yàn)證服務(wù)器證書的有效性,因?yàn)榉?wù)器的中間證書被放在證書鏈中一起發(fā)送給了客戶機(jī)。SSL2.0協(xié)議只適用RSA密鑰交換方式,而SSL3.0不僅支持RSA密鑰交換(在使用證書的情

6、況下),還支持Diffie-Hellman密鑰交換(在沒有使用證書或者沒有客戶端和服務(wù)器之間通信密鑰之前的情況下。)7層模型的第4層 (傳輸層) 實(shí)際上在四層的上部: TCP 不需要更改操作系統(tǒng) TCP 提供了可靠的消息傳輸SSL協(xié)議的位置協(xié)議的位置SSL協(xié)議可用于保護(hù)正常運(yùn)行于TCP之上的任何應(yīng)用協(xié)議,如HTTP、FTP、SMTP或Telnet的通信,最常見的是用SSL來保護(hù)HTTP的通信。協(xié)議的使用協(xié)議的使用 https:/ 與shttp:/SSL Architecture包括包括SSL記錄協(xié)議和三個(gè)高層協(xié)議(握手協(xié)議、密鑰更改記錄協(xié)議和三個(gè)高層協(xié)議(握手協(xié)議、密鑰更改規(guī)格協(xié)議、報(bào)警協(xié)議)

7、規(guī)格協(xié)議、報(bào)警協(xié)議)SSL記錄協(xié)議對各種更高級的協(xié)議提供基本的安全服務(wù)。記錄協(xié)議對各種更高級的協(xié)議提供基本的安全服務(wù)。SSL connection a transient, peer-to-peer, communications link associated with 1 SSL sessionSSL session an association between client & server created by the Handshake Protocol define a set of cryptographic parameters may be shared by mul

8、tiple SSL connections 避免每條連接需要進(jìn)行的代價(jià)高昂的新的安全參數(shù)協(xié)商過程SSL 參數(shù)參數(shù)會(huì)話狀態(tài)參數(shù)會(huì)話狀態(tài)參數(shù)會(huì)話標(biāo)識(shí)符:由服務(wù)器產(chǎn)生用于標(biāo)識(shí)活動(dòng)的或可恢復(fù)的會(huì)話狀態(tài)的一個(gè)任意字節(jié)序列對等證書:對等的X.509V3證書壓縮方法:加密前用于壓縮數(shù)據(jù)的算法密碼規(guī)格:大塊數(shù)據(jù)加密算法, 計(jì)算MAC的散列算法主密鑰:48字節(jié)的會(huì)話密鑰可恢復(fù)性:能否把會(huì)話用于創(chuàng)建新連接的標(biāo)志比特連接狀態(tài)參數(shù)連接狀態(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ù)、客戶端用于

9、解密數(shù)據(jù)的密鑰客戶端寫密鑰:客戶端用于加密數(shù)據(jù)、服務(wù)器用于解密數(shù)據(jù)的密鑰初始化向量:當(dāng)CBC模式中的數(shù)據(jù)塊正在使用時(shí),需要為每個(gè)密鑰配置一個(gè)初始化向量。之后的IV值為前一次分組密碼算法的最后一個(gè)密文分組序列號(hào)SSL Record Protocol ServicesConfidentiality 機(jī)密性機(jī)密性 using symmetric encryption with a shared secret key defined by Handshake Protocol AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128

10、 message is compressed before encryptionmessage integrity 消息完整性消息完整性 using a MAC with shared secret key similar to HMAC but with different paddingSSL記錄協(xié)議記錄協(xié)議每個(gè)這樣的段最大為214-1=16383個(gè)字節(jié)。從原始數(shù)據(jù)段到生成SSL明文分段、SSL壓縮、SSL密文(加密步驟)SSL記錄格式記錄格式SSL記錄頭部包括:記錄頭部包括:內(nèi)容類型(內(nèi)容類型(8位)位)-可以是可以是修改密碼協(xié)議、報(bào)警協(xié)議修改密碼協(xié)議、報(bào)警協(xié)議、握手協(xié)議、應(yīng)用數(shù)據(jù)四、握

11、手協(xié)議、應(yīng)用數(shù)據(jù)四種種主版本號(hào)(主版本號(hào)(8位)位) 副版本副版本號(hào)(號(hào)(8位)位)壓縮長度(壓縮長度(16位)位)-以字以字節(jié)為單位的明文分段(壓節(jié)為單位的明文分段(壓縮分段)長度縮分段)長度Content TypeMajor VersionMinor VersionCompressed LengthPlaintext (optionally compressed)MAC (0, 16, or 20 bytes)Encrypted1(a) Change Cipher Spec Protocol1 byte(c) Handshake ProtocolType1 byteLengthConten

12、t3 bytes3 bytes(b) Alert ProtocolLevel1 byteAlert1 byte(d) Other Upper Layer Protocol as TLS PayloadContentUp to 214 + 2048 bytesSSL記錄協(xié)議負(fù)載記錄協(xié)議負(fù)載SSL修改密文協(xié)議修改密文協(xié)議 協(xié)議由單個(gè)消息組成,該消息只包含一個(gè)值為1的單個(gè)字節(jié)。該消息的唯一作用就是使未決狀態(tài)拷貝為當(dāng)前狀態(tài),更新用于當(dāng)前連接的密碼組。 為了保障SSL傳輸過程的安全性,雙方應(yīng)該每隔一段時(shí)間改變加密規(guī)范。 SSL告警協(xié)議告警協(xié)議 為對等實(shí)體傳遞SSL的相關(guān)警告。如果在通信過程中某一方發(fā)現(xiàn)任

13、何異常,就需要給對方發(fā)送一條警示消息通告。 警示消息有兩種 Fatal錯(cuò)誤,如傳遞數(shù)據(jù)過程中,發(fā)現(xiàn)錯(cuò)誤的MAC,雙方就需要立即中斷會(huì)話,同時(shí)消除自己緩沖區(qū)相應(yīng)的會(huì)話記錄; Warning消息,這種情況,通信雙方通常都只是記錄日志,而對通信過程不造成任何影響。 (對警告的內(nèi)容做了相關(guān)的約定)SSL握手協(xié)議握手協(xié)議 1 使得服務(wù)器和客戶能夠相互鑒別對方,協(xié)商具體的加密算法和MAC算法以及保密密鑰,用來保護(hù)在SSL記錄中發(fā)送的數(shù)據(jù) SSL握手協(xié)議允許通信實(shí)體在交換應(yīng)用數(shù)據(jù)之前協(xié)商密鑰的算法、加密密鑰和對客戶端進(jìn)行認(rèn)證(可選)的協(xié)議,為下一步記錄協(xié)議要使用的密鑰信息進(jìn)行協(xié)商,使客戶端和服務(wù)器建立并保持

14、安全通信的狀態(tài)信息。SSL握手協(xié)議是在任何應(yīng)用程序數(shù)據(jù)傳輸之前使用的。 SSL握手協(xié)議包含四個(gè)階段: 建立安全能力; 服務(wù)器鑒別和密鑰交換; 客戶鑒別和密鑰交換; 完成握手協(xié)議。建立安全能力建立安全能力服務(wù)器認(rèn)證和密鑰服務(wù)器認(rèn)證和密鑰交換交換客戶端認(rèn)證和密鑰交換客戶端認(rèn)證和密鑰交換完成完成SSL握手協(xié)議細(xì)節(jié)握手協(xié)議細(xì)節(jié)第一階段 客戶端發(fā)起建立連接請求Client_hello消息 Version:客戶端SSL的最高版本號(hào) Random:隨機(jī)序列 32位時(shí)間戳+28字節(jié)隨機(jī)數(shù)(防重放攻擊),用于生成主秘密。 Session ID :會(huì)話ID 非零值表示用戶希望重用現(xiàn)有會(huì)話的參數(shù);零值表示客戶端希望

15、建立新的會(huì)話ID并協(xié)商安全參數(shù) CipherSuite : 密碼構(gòu)件,客戶端可以支持的密碼算法組合(以優(yōu)先遞減順序給出) Compression Method : 客戶端支持的壓縮方法列表 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ù)從客戶端的壓縮方法的列表中選擇的壓

16、縮方法SSL握手協(xié)議細(xì)節(jié)握手協(xié)議細(xì)節(jié)密碼套件列表參數(shù) 密鑰交換方法(6種:無效(沒有密鑰交換)、RSA、匿名Diffie-Hellman、Ephemeral Diffie-Hellman、Fixed Diffie-Hellman、Fortezza); 塊加密算法(AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128) MAC算法(MD5,SHA-1)Fixed Diffie-Hellman 公鑰證書中包含固定的Diffie-Hellman公鑰參數(shù)Ephemeral Diffie-Hellman Diffie-Hellma

17、n公鑰參數(shù)使用發(fā)送者的RSA私鑰或DSS密鑰的方式被交換和簽名,可以獲得一個(gè)臨時(shí)的被認(rèn)證的密鑰SSL握手協(xié)議細(xì)節(jié)握手協(xié)議細(xì)節(jié)列舉JSSE支持的幾個(gè)套件:SSL_RSA_WITH_RC4_128_MD5 = 0 x0004 /* 非對稱加密算法或密鑰交換算法為RSA,采用高強(qiáng)度128位對稱加密算法RC4,摘要或MAC算法為MD5,不支持出口 */SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = 0 x0014 /* 非對稱加密算法或密鑰交換算法支持RSA和DH,采用40位對稱加密算法DES,摘要或MAC算法為SHA,可以出口 */ JSSE,即Java(TM) Se

18、cure Socket Extension 。 JSSE是基于安全算法和握手機(jī)制之上的合成體。JSSE將危險(xiǎn)的安全弱點(diǎn)降到最低點(diǎn),并且它減輕了開發(fā)者的負(fù)擔(dān),使得開發(fā)者可以很輕松的整合到程序中。 SSL(Secure Sockets Layer)是JSSE中的重要的部分。OpenSSL采用C語言作為開發(fā)語言,這使得OpenSSL具有優(yōu)秀的跨平臺(tái)性能,這對于廣大技術(shù)人員來說是一件非常美妙的事情,可以在不同的平臺(tái)使用同樣熟悉的東西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平臺(tái),這使得OpenSSL具有廣泛的適用性。1998年,OpenSSL項(xiàng)目組接管了OpenSSL的開

19、發(fā)工作,并推出了OpenSSL的0.9.1版,到目前為止,OpenSSL的算法已經(jīng)非常完善,對SSL2.0、SSL3.0以及TLS1.0都支持。SSL握手協(xié)議細(xì)節(jié)握手協(xié)議細(xì)節(jié)第二階段 服務(wù)器認(rèn)證和密鑰交換 證書:服務(wù)器將數(shù)字證書和到根CA整個(gè)鏈發(fā)給客戶端,使客戶端能用服務(wù)器證書中的服務(wù)器公鑰認(rèn)證服務(wù)器。 服務(wù)器密鑰交換(可選):這里視密鑰交換算法而定 證書請求:服務(wù)端可能會(huì)要求客戶自身進(jìn)行驗(yàn)證。 服務(wù)器握手完成:第二階段的結(jié)束,第三階段開始的信號(hào)SSL握手協(xié)議細(xì)節(jié)握手協(xié)議細(xì)節(jié)如果協(xié)商過程中確定使用RSA交換密鑰,SSL握手協(xié)議細(xì)節(jié)握手協(xié)議細(xì)節(jié)證書(可選):為了對服務(wù)器證明自身,客戶要發(fā)送一個(gè)證

20、書信息,這是可選的,在IIS中可以配置強(qiáng)制客戶端證書認(rèn)證??蛻魴C(jī)密鑰交換(Pre-master-secret):這里客戶端將預(yù)備主密鑰發(fā)送給服務(wù)端,注意這里會(huì)使用服務(wù)端的公鑰進(jìn)行加密。證書驗(yàn)證(可選),對預(yù)備秘密和隨機(jī)數(shù)進(jìn)行簽名,證明自己擁有證書的私鑰。SSL握手協(xié)議細(xì)節(jié)握手協(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ù)以及

21、驗(yàn)證消息的完整性。Cryptographic Computations master secret creationla one-time 48-byte valuelgenerated using secure key exchange (RSA / Diffie-Hellman) and then hashing info generation of cryptographic parameterslclient write MAC secret, a server write MAC secret, a client write key, a server write key, a cl

22、ient write IV, and a server write IVl generated by hashing master secret密鑰計(jì)算過程密鑰計(jì)算過程SSL協(xié)議安全性分析鑒別機(jī)制鑒別機(jī)制 公開密鑰技術(shù)和數(shù)字證書可以實(shí)現(xiàn)客戶端和服務(wù)器端的身份鑒別。加密機(jī)制加密機(jī)制混合密碼體制的使用提供了會(huì)話和數(shù)據(jù)傳輸?shù)募用苄员Wo(hù)。雙方使用非對稱密碼體制協(xié)商出本次將要使用的會(huì)話密鑰,并選擇一種對稱加密算法。 完整性機(jī)制完整性機(jī)制 定義了共享的、可以用來形成報(bào)文鑒別碼MAC的密鑰。數(shù)據(jù)進(jìn)行分片壓縮后,使用單向散列函數(shù)產(chǎn)生一個(gè)MAC,加密后置于數(shù)據(jù)包的后部,并且再一次和數(shù)據(jù)一起被加密,然后加上SSL

23、首部進(jìn)行網(wǎng)絡(luò)傳輸。 這樣,如果數(shù)據(jù)被修改,其散列值就無法和原來的MAC相匹配,從而保證了數(shù)據(jù)的完整性。 抗重放攻擊抗重放攻擊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ì)初衷是對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)了

24、SSL的廣泛應(yīng)用。 針對這個(gè)問題,可在必要的時(shí)候配置SSL協(xié)議,使其選擇對客戶端進(jìn)行認(rèn)證鑒別。無法提供基于無法提供基于UDPUDP應(yīng)用的安全保護(hù)應(yīng)用的安全保護(hù)SSL協(xié)議需要在握手之前建立TCP連接,因此不能對UDP應(yīng)用進(jìn)行保護(hù)。如果要兼顧UDP協(xié)議層之上的安全保護(hù),可以采用IP層的安全解決方案。SSLSSL協(xié)議不能對抗通信流量分析協(xié)議不能對抗通信流量分析 由于SSL只對應(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)程中主密鑰泄漏進(jìn)程

25、中主密鑰泄漏 除非SSL的工程實(shí)現(xiàn)大部分駐留在硬件中,否則主密鑰將會(huì)存留在主機(jī)的主存儲(chǔ)器中,這就意味著任何可以讀取SSL進(jìn)程存儲(chǔ)空間的攻擊者都能讀取主密鑰,因此,不可能面對掌握機(jī)器管理特權(quán)的攻擊者而保護(hù)SSL連接,這個(gè)問題要依靠用戶管理策略來解決。SSL脆弱性分析磁盤上的臨時(shí)文件可能遭受攻擊磁盤上的臨時(shí)文件可能遭受攻擊對于使用虛擬內(nèi)存的操作系統(tǒng),不可避免地有些敏感數(shù)據(jù)甚至主密鑰都交換到存盤上,可采取內(nèi)存加鎖和及時(shí)刪除磁盤臨時(shí)文件等措施來降低風(fēng)險(xiǎn)安全盲點(diǎn)安全盲點(diǎn)系統(tǒng)管理員不能使用現(xiàn)有的安全漏洞掃描或網(wǎng)絡(luò)入侵檢測系統(tǒng)來審查或監(jiān)控網(wǎng)絡(luò)上的SSL交易。加密技術(shù)使得通過網(wǎng)絡(luò)傳輸?shù)男畔o法讓IDS辨認(rèn).使

26、得最重要的服務(wù)器反而成為受到最少防護(hù)的服務(wù)器。對此,惡意代碼檢測、增強(qiáng)的日志功能等基于主機(jī)的安全策略會(huì)成為最后防線。SSL脆弱性分析SSL的評價(jià)的評價(jià) SSL仍然不失為一套全面完善的安全策略中有效的組成元素。 然而,與網(wǎng)絡(luò)安全的其它工具軟件一樣,僅使用單一的防護(hù)軟件都是遠(yuǎn)遠(yuǎn)不夠的。對SSL的過高評價(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也使

27、用相同算法,只是填充部分采用了與密鑰串接的方式而不是異或方式,安全強(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申請證書,一般免費(fèi)證書很少,需要交費(fèi)。 http信息是明文傳輸,https 則是具有安全性的SSL加密傳輸協(xié)議。 http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。 http的連接很簡單,是無狀態(tài)的;HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份

28、認(rèn)證的網(wǎng)絡(luò)協(xié)議,比http協(xié)議安全。HTTPs解決的問題解決的問題信任主機(jī)的問題信任主機(jī)的問題.采用https的服務(wù)器必須從CA 申請一個(gè)用于證明服務(wù)器用途類型的證書。目前所有的銀行系統(tǒng)網(wǎng)站,關(guān)鍵部分應(yīng)用都是https 的??蛻敉ㄟ^信任該證書,從而信任了該主機(jī)。通訊過程中的數(shù)據(jù)的泄密和被篡改通訊過程中的數(shù)據(jù)的泄密和被篡改一般意義上的https,就是服務(wù)器有一個(gè)證書。保證服務(wù)器是他聲稱的服務(wù)器。 服務(wù)端和客戶端之間的所有通訊,都是加密的。服務(wù)端和客戶端之間的所有通訊,都是加密的。 客戶端產(chǎn)生一對稱的密鑰,通過服務(wù)器的證書來交換密鑰所有的信息往來都加密 少許對客戶端有要求的情況下,會(huì)要求客戶端也必

29、須有一個(gè)證書少許對客戶端有要求的情況下,會(huì)要求客戶端也必須有一個(gè)證書。除了用戶名/密碼,還有一個(gè)CA 認(rèn)證過的身份。個(gè)人銀行的專業(yè)版是這種做法,具體證書可能是拿U盤(即U盾)作為一個(gè)備份的載體。SSH( Secure Shell )protocol for secure network communicationsldesigned to be simple & inexpensiveSSH1 provided secure remote logon facilitylreplace TELNET & other insecure schemeslalso has more g

30、eneral client/server capabilitySSH2 fixes a number of security flawsdocumented in RFCs 4250 through 4254SSH clients & servers are widely availablemethod of choice for remote login/ X tunnelsSSH 是目前較可靠,專為遠(yuǎn)程登錄會(huì)話和其他網(wǎng)絡(luò)服務(wù)提供安全性的協(xié)議。利用 SSH 協(xié)議可以有效防止遠(yuǎn)程管理過程中的信息泄露問題。S S H最初是U N I X系統(tǒng)上的一個(gè)程序,后來又迅速擴(kuò)展到其他操作平臺(tái)。S

31、S H客戶端適用于多種平臺(tái)。 幾乎所有U N I X平臺(tái)包括H P - U X、L i n u x、A I X、S o l a r i s、Digital UNIX、I r i x,以及其他平臺(tái)都可運(yùn)行S S H。SSH( Secure Shell )SSH( Secure Shell )SSH Transport Layer Protocolserver authentication occurs at transport layer, based on server/host key pair(s) server authentication requires clients to kno

32、w host keys in advance (客戶端本地?cái)?shù)據(jù)庫保存,服務(wù)器公鑰或者CA根密鑰) packet exchange establish TCP connection can then exchange data identification string exchange(識(shí)別字符串交換)這些字符用于Diffie-Hellman密鑰交換, algorithm negotiation(算法協(xié)商)給出算法清單,包括密鑰交換、加密、MAC算法和壓縮算法(p136) key exchange(密鑰交換), Diffie-Hellman 服務(wù)器用私鑰簽名 end of key exchan

33、ge, (密鑰生成-協(xié)商后的密鑰做hash運(yùn)算) service request 請求獲得身份認(rèn)證 using specified packet format(分組長度、填充域長度、壓縮的有效載荷、SSH User Authentication Protocol authenticates client to server three message types:l SSH_MSG_USERAUTH_REQUESTl SSH_MSG_USERAUTH_FAILURE l SSH_MSG_USERAUTH_SUCCESS authentication methods usedl public-key, 用戶向服務(wù)器發(fā)送包含用戶公共密鑰的信息,該信息由用戶私鑰簽名。l password, 信息包含了明文口令,加密l host-based 驗(yàn)證主機(jī)而非用戶本身,一臺(tái)支持多個(gè)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論