FTP協(xié)議的分析和擴(kuò)展

發(fā)布時(shí)間：2010-09-07 22:44:21 作者：佚名

>>1.0<< FTP和TCP端口號(hào) 根據(jù)是使用Port模式還是Passive模式，F(xiàn)TP使用不同的TCP端口號(hào)，在詳細(xì)描述FTP前，我們來簡(jiǎn)單討論一下TCP端口號(hào)的一些基本概念。TCP使用端口號(hào)來標(biāo)識(shí)所發(fā)送和接收的應(yīng)用，端口

>>1.0<< FTP和TCP端口號(hào)
根據(jù)是使用Port模式還是Passive模式，F(xiàn)TP使用不同的TCP端口號(hào)，在詳細(xì)描述FTP前，我們來
簡(jiǎn)單討論一下TCP端口號(hào)的一些基本概念。TCP使用端口號(hào)來標(biāo)識(shí)所發(fā)送和接收的應(yīng)用，端口號(hào)
可以幫助TCP來分離字節(jié)流并且?guī)拖鄳?yīng)字節(jié)傳遞給正確的應(yīng)用程序。
TCP端口號(hào)可以是半永久的和暫時(shí)的。服務(wù)器端監(jiān)聽在半永久的端口上來讓客戶端訪問?？蛻?nbsp;
端使用暫時(shí)的端口在本地標(biāo)識(shí)一個(gè)對(duì)話，客戶端端口只在使用TCP服務(wù)時(shí)候才存在，而服務(wù)器
端口只要服務(wù)器在運(yùn)行就一直在監(jiān)聽。

TCP端口可以歸為3類：
1、眾所周知的端口來標(biāo)識(shí)在TCP上運(yùn)行的標(biāo)準(zhǔn)服務(wù)，包括FTP、HTTP、TELNET、SMTP等，這些
端口號(hào)碼范圍為0-1023；
2、注冊(cè)端口號(hào)用來標(biāo)識(shí)那些已經(jīng)向IANA（Internet Assigned Numbers Assigned Numbers
Authority）注冊(cè)的應(yīng)用，注冊(cè)端口號(hào)為1024-49151；
3、私有端口號(hào)是非注冊(cè)的并且可以動(dòng)態(tài)地分配給任何應(yīng)用，私有端口為49152-65535；
注冊(cè)的端口號(hào)本來打算只給注冊(cè)的應(yīng)用使用，可近年來端口號(hào)已經(jīng)陷入了到達(dá)極限的困境，你
可能會(huì)看到本來應(yīng)該是給注冊(cè)應(yīng)用使用的注冊(cè)端口被非注冊(cè)應(yīng)用用做暫時(shí)的端口。RFC1700詳
細(xì)標(biāo)注了眾所周知的和注冊(cè)的端口號(hào)，然而不幸的是，這個(gè)RFC文檔自從1994年以來一直沒有
被更新，然后你仍可以從IANA得到一個(gè)及時(shí)更新的端口列表，詳細(xì)URL為：
http://www.iana.org/assignments/port-numbers

>>2.0<< FTP Port模式和FTP Passive模式
當(dāng)你對(duì)一個(gè)FTP問題進(jìn)行排錯(cuò)時(shí)候，你首先要問的一個(gè)問題是使用的是port模式的還是passive
模式。因?yàn)檫@兩種行為迥異，所以這兩種模式引起的問題也不同；在過去，客戶端缺省為acti
ve(port)模式；近來，由于Port模式的安全問題，許多客戶端的FTP應(yīng)用缺省為Passive模式。

>>2.1 FTP Port模式
Port模式的FTP步驟如下：
1、客戶端發(fā)送一個(gè)TCP SYN（TCP同步）包給服務(wù)器段眾所周知的FTP控制端口21，客戶端
使用暫時(shí)的端口作為它的源端口；
2、服務(wù)器端發(fā)送SYN ACK（同步確認(rèn)）包給客戶端，源端口為21，目的端口為客戶端上使用
的暫時(shí)端口；
3、客戶端發(fā)送一個(gè)ACK（確認(rèn)）包；客戶端使用這個(gè)連接來發(fā)送FTP命令，服務(wù)器端使用這個(gè)
連接來發(fā)送FTP應(yīng)答；
4、當(dāng)用戶請(qǐng)求一個(gè)列表(List)請(qǐng)求或者發(fā)起一個(gè)要求發(fā)送或者接受文件的請(qǐng)求，客戶端軟件使用
PORT命令，這個(gè)命令包含了一個(gè)暫時(shí)的端口，客戶端希望服務(wù)器在打開一個(gè)數(shù)據(jù)連接時(shí)候使用
這個(gè)暫時(shí)端口；PORT命令也包含了一個(gè)IP地址，這個(gè)IP地址通常是客戶自己的IP地址，而且FT
P也支持第三方（third-party）模式，第三方模式是客戶端告訴服務(wù)器端打開與另臺(tái)主機(jī)的連接；
5、服務(wù)器端發(fā)送一個(gè)SYN包給客戶端的暫時(shí)端口，源端口為20，暫時(shí)端口為客戶端在PORT命令中
發(fā)送給服務(wù)器端的暫時(shí)端口號(hào)；
6、客戶端以源端口為暫時(shí)端口，目的端口為20發(fā)送一個(gè)SYN ACK包；
7、服務(wù)器端發(fā)送一個(gè)ACK包；
8、發(fā)送數(shù)據(jù)的主機(jī)以這個(gè)連接來發(fā)送數(shù)據(jù)，數(shù)據(jù)以TCP段(注：segment，第4層的PDU)形式發(fā)送（
一些命令，如STOR表示客戶端要發(fā)送數(shù)據(jù)，RETR表示服務(wù)器段發(fā)送數(shù)據(jù)），這些TCP段都需要
對(duì)方進(jìn)行ACK確認(rèn)（注：因?yàn)門CP協(xié)議是一個(gè)面向連接的協(xié)議）
9、當(dāng)數(shù)據(jù)傳輸完成以后，發(fā)送數(shù)據(jù)的主機(jī)以一個(gè)FIN命令來結(jié)束數(shù)據(jù)連接，這個(gè)FIN命令需要另一
臺(tái)主機(jī)以ACK確認(rèn)，另一臺(tái)主機(jī)也發(fā)送一個(gè)FIN命令，這個(gè)FIN命令同樣需要發(fā)送數(shù)據(jù)的主機(jī)以A
CK確認(rèn)；
10、客戶端能在控制連接上發(fā)送更多的命令，這可以打開和關(guān)閉另外的數(shù)據(jù)連接；有時(shí)候客戶端結(jié)
束后，客戶端以FIN命令來關(guān)閉一個(gè)控制連接，服務(wù)器端以ACK包來確認(rèn)客戶端的FIN，服務(wù)器
同樣也發(fā)送它的FIN，客戶端用ACK來確認(rèn)。

FTP Port模式會(huì)給網(wǎng)絡(luò)管理人員在許多方面帶來很多問題，首先，在PORT命令消息中的IP地址和端
口號(hào)的編碼不是直白地顯示。另外，應(yīng)用層的協(xié)議命令理論上不應(yīng)該包含網(wǎng)絡(luò)地址信息（注：
IP地址），因?yàn)檫@打破了協(xié)議層的原則并且可能導(dǎo)致協(xié)同性和安全性方面的問題。

當(dāng)使用FTP時(shí)候，網(wǎng)絡(luò)中的防火墻必須要聲明相應(yīng)的端口，防火墻必須要跟蹤FTP對(duì)話然后檢查
PORT命令，防火墻必須要參與從服務(wù)器端到客戶端在PORT命令中指定的端口連接的建立過程。
如果網(wǎng)絡(luò)中使用了NAT（注：網(wǎng)絡(luò)地址翻譯），那么NAT的網(wǎng)關(guān)同樣也需要聲明相應(yīng)的端口，網(wǎng)
關(guān)需要把在PORT命令中指定的IP地址翻譯成分配給客戶的地址，然后重新計(jì)算TCP的Checksum
；如果網(wǎng)關(guān)沒有正確地執(zhí)行這個(gè)操作，F(xiàn)TP就失敗了。

黑客可能會(huì)利用FTP支持第三方特性這一特點(diǎn)，在PORT命令中設(shè)置IP地址和端口號(hào)參數(shù)來指定
一臺(tái)目標(biāo)主機(jī)的地址和端口號(hào)（有時(shí)候稱這種攻擊為FTP反彈攻擊），例如黑客可以讓一臺(tái)FTP
服務(wù)器不斷地從它的源端口20發(fā)送TCP SYN包給一系列目的端口，讓FTP服務(wù)器看起來正在進(jìn)行
端口掃描，目的主機(jī)不知道攻擊來自黑客的主機(jī)，看起來攻擊象是來自FTP服務(wù)器。一些常用的
FTP應(yīng)用在PORT命令中設(shè)置地址為0.0.0.0，這樣做的意圖是讓FTP服務(wù)器只需要與打開控制連接
的相同客戶進(jìn)行數(shù)據(jù)連接，設(shè)置地址為0.0.0.0可能會(huì)讓防火墻不知所措。例如，CISCO PIX IOS
6.0以上版本的PIX（注：CISCO硬件防火墻設(shè)備，6.0以上版本為其修正了相關(guān)的FTP協(xié)議）
要求數(shù)據(jù)連接的IP地址與已經(jīng)存在的控制連接的IP地址必須相同。這樣做的原因是防止黑客用
PORT命令來攻擊別的機(jī)器，雖然一些FTP應(yīng)用設(shè)置IP地址為0.0.0.0不是有意圖的攻擊，但在PI
X修正協(xié)議環(huán)境下的確引起了一些問題，同時(shí)對(duì)其他不允許第三方模式和避免FTP反彈攻擊的防
火墻來說，這也會(huì)引起相同的問題。

>>2.2 FTP Passive模式
下面的列表描述了Passive模式的FTP的步驟，步驟1到3和Port模式FTP相同，步驟9到11同樣與
Port模式FTP最后三步相同。

1、客戶端發(fā)送一個(gè)TCP SYN（TCP同步）包給服務(wù)器段眾所周知的FTP控制端口21，客戶端使
用暫時(shí)的端口作為它的源端口；
2、服務(wù)器端發(fā)送SYN ACK（同步確認(rèn)）包給客戶端，源端口為21，目的端口為客戶端上使用
的暫時(shí)端口；
3、客戶端發(fā)送一個(gè)ACK（確認(rèn)）包；客戶端使用這個(gè)連接來發(fā)送FTP命令，服務(wù)器端使用這個(gè)
連接來發(fā)送FTP應(yīng)答；
4、當(dāng)用戶請(qǐng)求一個(gè)列表(List)或者發(fā)送或接收文件時(shí)候，客戶端軟件發(fā)送PASV命令給服務(wù)器端

#p# 表明客戶端希望進(jìn)入Passive模式；
5、服務(wù)器端進(jìn)行應(yīng)答，應(yīng)答包括服務(wù)器的IP地址和一個(gè)暫時(shí)的端口，這個(gè)暫時(shí)的端口是客戶端
在打開數(shù)據(jù)傳輸連接時(shí)應(yīng)該使用的端口；
6、客戶端發(fā)送一個(gè)SYN包，源端口為客戶端自己選擇的一個(gè)暫時(shí)端口，目的端口為服務(wù)器在PASV
應(yīng)答命令中指定的暫時(shí)端口號(hào)；
7、服務(wù)器端發(fā)送SYN ACK包給客戶端，目的端口為客戶端自己選擇的暫時(shí)端口，源端口為PASV
應(yīng)答中指定的暫時(shí)端口號(hào)；
8、客戶端發(fā)送一個(gè)ACK包；
9、發(fā)送數(shù)據(jù)的主機(jī)以這個(gè)連接來發(fā)送數(shù)據(jù)，數(shù)據(jù)以TCP段(注：segment，第4層的PDU)形式發(fā)送（
一些命令，如STOR表示客戶端要發(fā)送數(shù)據(jù)，RETR表示服務(wù)器段發(fā)送數(shù)據(jù)），這些TCP段都需要
對(duì)方進(jìn)行ACK確認(rèn)；
10、當(dāng)數(shù)據(jù)傳輸完成以后，發(fā)送數(shù)據(jù)的主機(jī)以一個(gè)FIN命令來結(jié)束數(shù)據(jù)連接，這個(gè)FIN命令需要另一
臺(tái)主機(jī)以ACK確認(rèn)，另一臺(tái)主機(jī)也發(fā)送一個(gè)FIN命令，這個(gè)FIN命令同樣需要發(fā)送數(shù)據(jù)的主機(jī)以A
CK確認(rèn)；
11、客戶端能在控制連接上發(fā)送更多的命令，這可以打開和關(guān)閉另外的數(shù)據(jù)連接；有時(shí)候客戶端結(jié)
束后，客戶端以FIN命令來關(guān)閉一個(gè)控制連接，服務(wù)器端以ACK包來確認(rèn)客戶端的FIN，服務(wù)器
同樣也發(fā)送它的FIN，客戶端用ACK來確認(rèn)。

大多數(shù)人認(rèn)為在防火墻網(wǎng)絡(luò)環(huán)境中Passive模式比Port模式的問題小，但我們注意到在Passive
模式下，客戶端打開一個(gè)暫時(shí)的目的端口連接，一些防火墻或者CISCO設(shè)備的訪問列表(ACL)可
能會(huì)阻止這種連接，同樣服務(wù)器的回應(yīng)也是從一個(gè)暫時(shí)的端口到一個(gè)暫時(shí)的端口，防火墻或者
CISCO的訪問列表也會(huì)阻止這種連接。在CISCO路由器上你可以用訪問列表關(guān)鍵字"established
"來避免第二個(gè)問題，"established"關(guān)鍵字告訴路由器允許帶ACK字端的包通過，服務(wù)器端的S
YN ACK包帶有ACK字端。在新版本PIX IOS中也可以通過fixit關(guān)鍵字建立針對(duì)ftp協(xié)議的深層狀
態(tài)檢測(cè)過濾，其他大多數(shù)狀態(tài)檢測(cè)防火墻例如LinuxNetfilters也支持ftp協(xié)議的狀態(tài)檢測(cè)，進(jìn)行
準(zhǔn)確的PASV動(dòng)態(tài)端口過濾。

>>2.3 用戶名和口令的明文傳輸
FTP另一個(gè)聲名狼藉的問題是它以明文方式發(fā)送用戶名和口令，也就是不加密地發(fā)送。任何人
只要在網(wǎng)絡(luò)中合適的位置放置一個(gè)協(xié)議分析儀就可以看到用戶名和口令；FTP發(fā)送的數(shù)據(jù)也是
以明文方式傳輸，通過對(duì)ftp連接的監(jiān)控和數(shù)據(jù)收集就可以收集和重現(xiàn)ftp的數(shù)據(jù)傳輸并實(shí)現(xiàn)協(xié)
議連接回放。事實(shí)上很多用戶把相同的用戶名和口令用在不同的應(yīng)用中，這樣這個(gè)問題可能
看起來更為糟糕；如果黑客收集到FTP口令，他們也可能就得到了你在線帳號(hào)或者其他一些
機(jī)密數(shù)據(jù)的口令。

下面是通過tcpdump -- 一個(gè)著名的網(wǎng)絡(luò)協(xié)議分析程序抓取的ftp的完整通訊過程。
/=================================================================\
21:55:36.682402 IP 192.168.0.1.2323 > 192.168.0.3.21: S 2047626269:2047626269(0)
win 65535 <mss 1460,nop,nop,sackOK> (DF)
21:55:36.682792 IP 192.168.0.3.21 > 192.168.0.1.2323: S 3917547047:3917547047(0)
ack 2047626270 win 65535 <mss 1460,nop,nop,sackOK> (DF)
21:55:36.682855 IP 192.168.0.1.2323 > 192.168.0.3.21: . ack 1 win 65535 (DF)
<TCP三步握手>
21:55:36.854899 IP 192.168.0.3.21 > 192.168.0.1.2323: P 1:115(114) ack 1 win 65535
(DF)
0x0000 4500 009a d570 4000 8006 a398 c0a8 0003 E....p@.........
0x0010 c0a8 0001 0015 0913 e981 0628 7a0c 4c1e ...........(z.L.
0x0020 5018 ffff cd50 0000 3232 302d 5468 6973 P....P..220-This
0x0030 2073 6572 7665 7220 6973 2066 6f72 2070 .server.is.for.p
0x0040 7269 7661 7465 2075 7365 206f 6e6c 790d rivate.use.only.
0x0050 0a32 .2
21:55:37.016115 IP 192.168.0.1.2323 > 192.168.0.3.21: . ack 115 win 65421 (DF)
0x0000 4500 0028 b8d0 4000 8006 c0aa c0a8 0001 E..(..@.........
0x0010 c0a8 0003 0913 0015 7a0c 4c1e e981 069a ........z.L.....
0x0020 5010 ff8d 6f83 0000 P...o...
21:55:37.016471 IP 192.168.0.3.21 > 192.168.0.1.2323: P 115:154(39) ack 1 win
65535 (DF)
<FTP協(xié)議連接>
0x0000 4500 004f d586 4000 8006 a3cd c0a8 0003 E..O..@.........
0x0010 c0a8 0001 0015 0913 e981 069a 7a0c 4c1e ............z.L.
0x0020 5018 ffff 074f 0000 3232 3020 506c 6561 P....O..220.Plea
0x0030 7365 2065 6e74 6572 2079 6f75 7220 6c6f se.enter.your.lo
0x0040 6769 6e20 6e61 6d65 206e 6f77 2e0d 0a gin.name.now...
21:55:37.022282 IP 192.168.0.1.2323 > 192.168.0.3.21: P 1:12(11) ack 154 win 65382
(DF)
0x0000 4500 0033 b8d2 4000 8006 c09d c0a8 0001 E..3..@.........
0x0010 c0a8 0003 0913 0015 7a0c 4c1e e981 06c1 ......

#p# ..z.L.....
0x0020 5018 ff66 c4eb 0000 5553 4552 2065 6c6c P..f....USER.ell
0x0030 790d 0a y..
<用戶名:elly>
21:55:37.059430 IP 192.168.0.3.21 > 192.168.0.1.2323: P 154:188(34) ack 12 win
65524 (DF)
0x0000 4500 004a d58b 4000 8006 a3cd c0a8 0003 E..J..@.........
0x0010 c0a8 0001 0015 0913 e981 06c1 7a0c 4c29 ............z.L)
0x0020 5018 fff4 b343 0000 3333 3120 5061 7373 P....C..331.Pass
0x0030 776f 7264 2072 6571 7569 7265 6420 666f word.required.fo
0x0040 7220 656c 6c79 202e 0d0a r.elly....
21:55:37.060301 IP 192.168.0.1.2323 > 192.168.0.3.21: P 12:27(15) ack 188 win
65348 (DF)
0x0000 4500 0037 b8db 4000 8006 c090 c0a8 0001 E..7..@.........
0x0010 c0a8 0003 0913 0015 7a0c 4c29 e981 06e3 ........z.L)....
0x0020 5018 ff44 e479 0000 5041 5353 2038 3838 P..D.y..PASS.888
0x0030 3838 3838 380d 0a 88888..
<密碼:88888888>
21:55:37.243954 IP 192.168.0.3.21 > 192.168.0.1.2323: . ack 27 win 65509 (DF)
0x0000 4500 0028 d59d 4000 8006 a3dd c0a8 0003 E..(..@.........
0x0010 c0a8 0001 0015 0913 e981 06e3 7a0c 4c38 ............z.L8
0x0020 5010 ffe5 6ec8 0000 0000 0000 0000 P...n.........
21:55:37.285586 IP 192.168.0.3.21 > 192.168.0.1.2323: . 188:1648(1460) ack 27 win
65509 (DF)
0x0000 4500 05dc d5a4 4000 8006 9e22 c0a8 0003 E.....@...."....
0x0010 c0a8 0001 0015 0913 e981 06e3 7a0c 4c38 ............z.L8
0x0020 5010 ffe5 0300 0000 3233 302d 5765 6c63 P.......230-Welc
0x0030 6f6d 6520 746f 2076 6920 4654 5020 7365 ome.to.vi.FTP.se
0x0040 7276 6572 0d0a 3233 302d 0d0a 3233 302d rver..230-..230-
0x0050 4375 Cu
<明文數(shù)據(jù)傳輸>
\=================================================================/

>>3.0<< 改進(jìn): ftp安全擴(kuò)展, SSL/TLS
在傳統(tǒng)的ftp通訊和傳輸過程中可以看出，ftp協(xié)議提供了一種簡(jiǎn)單實(shí)用的網(wǎng)絡(luò)文件傳輸方法，
但是缺陷也是顯而易見的。傳統(tǒng)ftp服務(wù)缺乏對(duì)數(shù)據(jù)的機(jī)密性和完整性保護(hù)，對(duì)通訊雙方也沒
有可靠的認(rèn)證措施，同時(shí)還存在著明文信息傳輸?shù)娜觞c(diǎn) --
在同一個(gè)網(wǎng)絡(luò)上的任何用戶都可能竊取到重要的信息。雖然近年來出現(xiàn)了很多種ftp的替代服
務(wù)，例如ssh加密通道的sftp/scp，或使用IPSEC協(xié)議的VPN通道等等，但是在大多數(shù)情況下，f
tp的通用性和易用性使得它在很長一段時(shí)間內(nèi)必然無法被完全取代。所以如同其他一系列古董
服務(wù)(例如SMTP/HTTP)一樣，近年來也出現(xiàn)了一些不需要對(duì)ftp協(xié)議自身做完全更改的協(xié)議擴(kuò)展
模塊，能夠良好的完成兼容性和功能擴(kuò)展。ftp SSL/TLS Extension就是其中一種方式。

FTP安全擴(kuò)展: http://www.ietf.org/rfc/rfc2228.txt
http://www.ietf.org/rfc/rfc2246.txt
FTP安全擴(kuò)展，SSL接口草案:
http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-13.txt

>>3.1 SSL/TLS簡(jiǎn)介
先說一下SSL/TLS協(xié)議，SSL(Secure Socket
Layer)最早是netscape公司設(shè)計(jì)的用于HTTP協(xié)議加密的安全傳輸協(xié)議，SSL工作于TCP協(xié)議的傳
輸層(TCP層)和應(yīng)用程序之間。作為一個(gè)中間層，應(yīng)用程序只要采用SSL提供的一套SSL套接字A
PI來替換標(biāo)準(zhǔn)的Socket套接字，就可以把程序轉(zhuǎn)換為SSL化的安全網(wǎng)絡(luò)程序，在傳輸過程中將
由SSL協(xié)議實(shí)現(xiàn)數(shù)據(jù)機(jī)密性和完整性的保證。SSL協(xié)議的當(dāng)前版本為3.0，當(dāng)SSL取得大規(guī)模成功
后，IETF(www.ietf.org)將SSL作了標(biāo)準(zhǔn)化，規(guī)范為RFC2246，并將其稱為TLS（Transport
Layer
Security）。從技術(shù)上講，TLS1.0與SSL3.0的差別非常微小，SSL由于其歷史應(yīng)用的原因在當(dāng)
前的商業(yè)應(yīng)用程序之中使用得更多一些。
TLS協(xié)議，RFC 2246: http://www.ietf.org/rfc/rfc2246.txt

>>3.2 數(shù)據(jù)機(jī)密性和完整性
前面多次提到了數(shù)據(jù)的機(jī)密性和完整性兩個(gè)方面，在此略微解釋一下。數(shù)據(jù)的機(jī)密性確保數(shù)據(jù)
信息機(jī)密可靠，不會(huì)被沒有權(quán)限的對(duì)象所訪問和瀏覽到，基本的機(jī)密性保護(hù)手段就是數(shù)據(jù)加密
；而數(shù)據(jù)的完整性則是指數(shù)據(jù)在傳輸和存儲(chǔ)過程中將保證數(shù)據(jù)的唯一和完整，不會(huì)被惡意篡改
著所修改，保證數(shù)據(jù)完整性的基本手段主要有數(shù)字簽名。

這里就牽扯到數(shù)據(jù)加密領(lǐng)域的兩類算法，加密算法和散列算法。加密算法從數(shù)學(xué)原理上看可以
分為對(duì)稱加密和非對(duì)稱加密，從數(shù)據(jù)處理方法上可以分為流加密和分組加密，本文重點(diǎn)不在此
，不再贅述，只舉例幾種常用的加密算法: DES, 3DES, AES,
BlowFish,RC2-RC6等等。數(shù)據(jù)簽名算法是加密領(lǐng)域的另一套方法，又叫數(shù)據(jù)散列算法，用于對(duì)
數(shù)據(jù)進(jìn)行處理生成一個(gè)唯一的等長簽名字符串，原數(shù)據(jù)的長度可能是任意的，而任意兩個(gè)相似
但哪怕只有少許細(xì)微差別的數(shù)據(jù)集，都將產(chǎn)生差別非常大的等長簽名字符串，這個(gè)字符串在一
般意義下被認(rèn)為是極少會(huì)發(fā)生空間沖突(重復(fù))的，因此數(shù)據(jù)散列算法對(duì)于確保數(shù)據(jù)的唯一性是
一種必要的手段；常見的數(shù)字散列算法有MD5，SHA-1，CAST-256等等。

可以看出，面對(duì)如此多種類的加密算法，應(yīng)用程序處理起來是很繁瑣的。SSL在這個(gè)層次中就
提供了一種自動(dòng)的算法協(xié)商，密鑰交換和數(shù)據(jù)加密過程。SSL協(xié)議分為兩部分：Handshake
Protocol和Record
Protocol，HandShake部分用于處理通訊雙方的算法協(xié)商和密鑰交換過程，Record部分用于對(duì)
數(shù)據(jù)進(jìn)行加密傳輸。

SSL套結(jié)字通訊過程如下:
1, Client和Server雙方程序通過ssl socket系列函數(shù)替換BSD Socket系列函數(shù)；
2, Client通過TCP協(xié)議連接到Server端應(yīng)用程序；
3, Client發(fā)起連接質(zhì)詢，發(fā)送自身所能實(shí)現(xiàn)的"安全集合"，其中包含加密和簽名算法協(xié)商；
4, Server回應(yīng)連接，包含本次通訊所使用的算法集合，以及Server端證書；
5, Client收到證書后，使用Server端協(xié)商的算法，用Server端證書中包含的Server公鑰加密一個(gè)
隨機(jī)序列，作為一個(gè)挑戰(zhàn)質(zhì)詢發(fā)回Server；
6, Server收到加密密文，使用自身的私鑰進(jìn)行數(shù)據(jù)解密，如果成功，代表SA協(xié)商匹配，可以
開始通訊；
7, 可選過程，繼續(xù)發(fā)起Client端驗(yàn)證過程，Client端發(fā)出Client證書，進(jìn)行Client端驗(yàn)證過程；
8, 可選過程，數(shù)據(jù)傳輸過程加密算法協(xié)商；
9, 協(xié)商完畢，開始加密數(shù)據(jù)傳輸；

可以看出，SSL Socket通訊過程相比正常的BSD Socket，只不過多了一個(gè)安全集合交換協(xié)商的過程，
這個(gè)過程由SSL實(shí)現(xiàn)自身來完成，相對(duì)于應(yīng)用程序，只要采用了SSL Socket，其他的過程都是
透明的。SSL通訊過程中的第3-6步是必須操作，包含了Server端驗(yàn)證過程和加密算法協(xié)商，類
似于TCP協(xié)議的三步握手過程，這個(gè)過程中通過公鑰加密算法加密密鑰(公鑰)和解密秘鑰(私鑰)
不同的功能，巧妙地實(shí)現(xiàn)了密鑰交換和算法協(xié)商，并且由于解密秘鑰不需要在網(wǎng)絡(luò)上傳輸，這樣
就同時(shí)實(shí)現(xiàn)了數(shù)據(jù)通訊過程的保密性和內(nèi)部應(yīng)用程序協(xié)議的保密性。在第7步進(jìn)行Client端證書
的驗(yàn)證過程中，由于當(dāng)前網(wǎng)絡(luò)環(huán)境下PKI和CA體系尚不完善，并且由于SSL設(shè)計(jì)的工作環(huán)境相對(duì)
對(duì)Client端的安全需求并不很高，所以Client端驗(yàn)證一般作為一種可選手段來實(shí)現(xiàn)，取決于應(yīng)
用程序的安全等級(jí)需求。

SSL數(shù)據(jù)通訊的機(jī)密性特性就是由上面的過程完成的，在算法協(xié)商過程中除了加密算法的協(xié)商外
還會(huì)交換一個(gè)數(shù)據(jù)簽名算法，用于對(duì)數(shù)據(jù)生成一個(gè)唯一的散列校驗(yàn)碼，防止在傳輸過程中數(shù)據(jù)
被篡改，數(shù)據(jù)簽名過程實(shí)現(xiàn)了通訊過程的完整性保證。

對(duì)應(yīng)于SSL所提供的兩種安全特性，機(jī)密性和保密性，ssl定義了四個(gè)安全級(jí)別，分別是這兩種
特性的狀態(tài)組合:
C - Clear - 沒有任何保護(hù)

S - Safe - 完整性實(shí)現(xiàn)，但是沒有機(jī)密性

E - Confidential - 機(jī)密性實(shí)現(xiàn)，但是沒有完整性

P - Private - 同時(shí)實(shí)現(xiàn)機(jī)密性和完整性

ftp的ssl擴(kuò)展使用了其中的兩種狀態(tài)
1)Clear (requested by PROT C)
2)Private (requested by PROT P)
在連接過程中通過ftp擴(kuò)展指令PROT來完成狀態(tài)的切換。

>>3.3 ssl FTP擴(kuò)展
在RFC 2228中，ftp協(xié)議擴(kuò)展了如下指令:
AUTH (Authentication/Security Mechanism),
ADAT (Authentication/Security Data),
PROT (Data Channel Protection Level),
PBSZ (Protection Buffer Size),
CCC (Clear Command Channel),
MIC (Integrity Protected Command),
CONF (Confidentiality Protected Command), and
ENC (Privacy Protected Command).

其中和SSL擴(kuò)展相關(guān)的主要指令有以下幾條:
AUTH (協(xié)商擴(kuò)展驗(yàn)證): 指定擴(kuò)展認(rèn)證方法,SSL或TLS；
PBSZ (協(xié)商保護(hù)緩沖區(qū)): 制定保護(hù)緩沖區(qū),SSL/TLS模式中必須為0；
PROT (切換保護(hù)級(jí)別): 切換保護(hù)級(jí)別，可以為"C"無保護(hù)，或"P"保護(hù)級(jí)別；

#p# ---------> accept() |
| <------------------------------------------- 220 |
| AUTH TLS -------------------------------------------> |
| <------------------------------------------- 234 |
| TLSneg() <------------------------------------------> TLSneg() |
| PBSZ 0 -------------------------------------------> |
| <------------------------------------------- 200 |
| PROT P -------------------------------------------> |
| <------------------------------------------- 200 |
| USER elly -------------------------------------------> |
| <------------------------------------------- 331 |
| PASS **** -------------------------------------------> |
| <------------------------------------------- 230 |
| |
\====================================================================/

在ssl ftp中，有以下幾個(gè)特殊點(diǎn):
1, AUTH是可選指令，因?yàn)閟sl ftp實(shí)現(xiàn)的方式不同而存在，詳見下一節(jié)explicit SSL
與implicit SSL；
2, PBSZ和PROT是必須指令，用于切換到保護(hù)通道模式；
3, AUTH，PBSZ和PROT指令是實(shí)現(xiàn)SSL認(rèn)證方式的必須方法，但可以與傳統(tǒng)的User/Password
模式共存，或只取其一；
4, SSL認(rèn)證方法的SSL認(rèn)證過程(AUTH/PBSZ)和傳統(tǒng)模式認(rèn)證并無嚴(yán)格的先后順序關(guān)聯(lián)，可能在
用戶名和密碼之前，也可能在之后；但出于安全因素，最好在User/Password傳輸之前切換
到安全模式，可以確保User/Password的傳輸安全；
5, 在explicit SSL模式中，可以在任何時(shí)間切換到保護(hù)模式，如第四條所述；在implicit
SSL模式中，初始化連接將直接采用SSL Socket建立，不需要AUTH指令切換。

>>3.4 Explicit SSL和Implicit SSL
由于歷史和軟件兼容性因素，ssl FTP的實(shí)現(xiàn)有兩種方式，分別是Explicit SSL和Implicit SSL，
上面的大部分?jǐn)?shù)據(jù)都是以explicit SSL為范例。

Explicit SSL(外部SSL)，又被稱為AUTH SSL方式；Explicit SSL保持了與傳統(tǒng)ftp服務(wù)的
良好兼容性，以一個(gè)ftp服務(wù)擴(kuò)展指令的方式存在。初始化連接可以采用與傳統(tǒng)ftp兼容的連
接模式，當(dāng)需要傳輸加密信息時(shí)使用AUTH SSL指令切換到保護(hù)模式。使用Explicit SSL時(shí)
Server必須完整地實(shí)現(xiàn)AUTH/PBSZ/PROT等指令。

Implicit SSL(隱含SSL)，是一個(gè)全新的ftp實(shí)現(xiàn)方式，在TCP三步握手完成之后就直接使用
SSL Socket進(jìn)行協(xié)商和通訊，之后將全程采用SSL加密連接。在這種模式中一般ftp server
將監(jiān)聽在一個(gè)新的服務(wù)端口，IANA指定ftps:tcp:990為implicit SSL ftp的默認(rèn)端口。因?yàn)樵?nbsp;
連接初始階段就自動(dòng)由SSL實(shí)現(xiàn)完成了協(xié)商，因此implicit模式中AUTH指令是可選的。

在不考慮兼容性的因素下，在服務(wù)期端最好優(yōu)先使用implicit SSL模式，可以獲得更好的保密
特性。

比較兩種ssl ftp實(shí)現(xiàn)模式區(qū)別如下:
/======================================================================\
| explicit implicit |
| client server client server |
|======================================================================|
| | |
| connect() ------> -+-明文 | sslConnect() ------> 加密 |
| <------ 220 | | <------ 220 -+ |
| AUTH SSL ------> | | USER *** ------> | |
| <------ 234 -+ | <------ 331 | |
| TLSneg() <-----> TLSneg() -+-加密 | PASS *** ------> | |
| <------ 200 | | <------ 230 | |
| USER *** ------> | | LIST <-----> ... | |
| <------ 331 | | RETR <-----> ... | |
| PASS *** ------> | | ... | |
| <------ 230 | | | |
| LIST/RETR <-----> ... | | sslClose() <-----> ... -+ |
| close() <-----> ... -+ | |
| | |
\======================================================================/

#p# 3 PORT: 1402 |
| [R] LIST -al |
| [R] Connected. Negotiating SSL/TLS session.. |
| [R] 150 Opening ASCII data connection for ls / using SSL/TLS. |
| [R] SSL/TLS negotiation successful... |
| [R] TLSv1/SSLv3 encrypted session using cipher AES256-SHA (256 bits) |
| [R] List Complete: 181 bytes in 0.17 seconds (1.04 KBps) |
\======================================================================/

Explicit SSL模式下ftp client <-- server的通訊數(shù)據(jù)，可以看到AUTH SSL之后的指令全部都
已經(jīng)加密，無法看到。對(duì)應(yīng)2.3節(jié)中的傳統(tǒng)通訊過程，這確保了傳輸過程中數(shù)據(jù)無法被竊聽到。
在Implicit SSL模式中，從初始化連接開始的數(shù)據(jù)將全部加密，無法分析，因此此處不摘錄。
/======================================================================\
21:34:22.095241 IP 192.168.0.1.2279 > 192.168.0.3.999: S 1727744887:1727744887(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
0x0000 4500 0030 e6b7 4000 8006 92bb c0a8 0001 E..0..@.........
0x0010 c0a8 0003 08e7 03e7 66fb 4b77 0000 0000 ........f.Kw....
0x0020 7002 ffff 428a 0000 0204 05b4 0101 0402 p...B...........
21:34:22.095576 IP 192.168.0.3.999 > 192.168.0.1.2279: S 3598555607:3598555607(0) ack 1727744888 win 65535 <mss 1460,nop,nop,sackOK> (DF)
0x0000 4500 0030 8d9e 4000 8006 ebd4 c0a8 0003 E..0..@.........
0x0010 c0a8 0001 03e7 08e7 d67d 99d7 66fb 4b78 .........}..f.Kx
0x0020 7012 ffff d223 0000 0204 05b4 0101 0402 p....#..........
21:34:22.095639 IP 192.168.0.1.2279 > 192.168.0.3.999: . ack 1 win 65535 (DF)
0x0000 4500 0028 e6b8 4000 8006 92c2 c0a8 0001 E..(..@.........
0x0010 c0a8 0003 08e7 03e7 66fb 4b78 d67d 99d8 ........f.Kx.}..
0x0020 5010 ffff fee7 0000 P.......
21:34:22.108439 IP 192.168.0.3.999 > 192.168.0.1.2279: P 1:115(114) ack 1 win 65535 (DF)
0x0000 4500 009a 8da4 4000 8006 eb64 c0a8 0003 E.....@....d....
0x0010 c0a8 0001 03e7 08e7 d67d 99d8 66fb 4b78 .........}..f.Kx
0x0020 5018 ffff 5cb5 0000 3232 302d 5468 6973 P...\...220-This
0x0030 2073 6572 7665 7220 6973 2066 6f72 2070 .server.is.for.p
0x0040 7269 7661 7465 2075 7365 206f 6e6c 790d rivate.use.only.
0x0050 0a32 .2
21:34:22.257722 IP 192.168.0.1.2279 > 192.168.0.3.999: . ack 115 win 65421 (DF)
0x0000 4500 0028 e6c1 4000 8006 92b9 c0a8 0001 E..(..@.........
0x0010 c0a8 0003 08e7 03e7 66fb 4b78 d67d 9a4a ........f.Kx.}.J
0x0020 5010 ff8d fee7 0000 P.......
21:34:22.257941 IP 192.168.0.3.999 > 192.168.0.1.2279: P 115:154(39) ack 1 win 65535 (DF)
0x0000 4500 004f 8da7 4000 8006 ebac c0a8 0003 E..O..@.........
0x0010 c0a8 0001 03e7 08e7 d67d 9a4a 66fb 4b78 .........}.Jf.Kx
0x0020 5018 ffff 96b3 0000 3232 3020 506c 6561 P.......220.Plea
0x0030 7365 2065 6e74 6572 2079 6f75 7220 6c6f se.enter.your.lo
0x0040 6769 6e20 6e61 6d65 206e 6f77 2e0d 0a gin.name.now...
21:34:22.264587 IP 192.168.0.1.2279 > 192.168.0.3.999: P 1:11(10) ack 154 win 65382 (DF)
0x0000 4500 0032 e6c2 4000 8006 92ae c0a8 0001 E..2..@.........
0x0010 c0a8 0003 08e7 03e7 66fb 4b78 d67d 9a71 ........f.Kx.}.q
0x0020 5018 ff66 e88e 0000 4155 5448 2053 534c P..f....AUTH.SSL
0x0030 0d0a ..
21:34:22.371140 IP 192.168.0.3.999 > 192.168.0.1.2279: P 154:205(51) ack 11 win 65525 (DF)
0x0000 4500 005b 8dac 4000 8006 eb9b c0a8 0003 E..[..@.........
0x0010 c0a8 0001 03e7 08e7 d67d 9a71 66fb 4b82 .........}.qf.K.
0x0020 5018 fff5 9a03 0000 3233 3420 4155 5448 P.......234.AUTH
0x0030 2043 6f6d 6d61 6e64 204f 4b2e 2049 6e69 .Command.OK..Ini
0x0040 7469 616c 697a 696e 6720 5353 4c20 636f tializing.SSL.co
0x0050 6e6e nn
21:34:22.374945 IP 192.168.0.1.2279 > 192.168.0.3.999: P 11:141(130) ack 205 win 65331 (DF)
0x0000 4500 00aa e6c6 4000 8006 9232 c0a8 0001 E.....@....2....
0x0010 c0a8 0003 08e7 03e7 66fb 4b82 d67d 9aa4 ........f.K..}..
0x0020 5018 ff33 f99a 0000 8080 0103 0100 5700 P..3..........W.
0x0030 0000 2000 0016 0000 1300 000a 0700 c000 ................
0x0040 0066 0000 0700 0005 0000 0405 0080 0300 .f..............
0x0050 8001 ..
21:34:22.375857 IP 192.168.0.3.999 > 192.168.0.1.2279: P 205:1071(866) ack 141 win 65395 (DF)
0x0000 4500 038a 8dad 4000 8006 e86b c0a8 0003 E.....@....k....
0x0010 c0a8 0001 03e7 08e7 d67d 9aa4 66fb 4c04 .........}..f.L.
0x0020 5018 ff73 e356 0000 1603 0100 4a02 0000 P..s.V......J...
0x0030 4603 0140 8283 7da1 8821 775e 7765 a9ee F..@..}..!w^we..
0x0040 18ca e0ab 1b17 461e bf71 515f 6837 5c1a ......F..qQ_h7\.
\======================================================================/

>>4.0<< 總結(jié)
FTP的替代應(yīng)用
如今，如果考慮到其他一些安全的文件傳輸選擇，可能看起來沒有理由再使用FTP了，如SCP或
者SFTP，與FTP應(yīng)用相似但運(yùn)用SSH（注：Secure
Shell）來進(jìn)行驗(yàn)證和加密，如果你使用一臺(tái)基于UNIX的服務(wù)器，你可以在命令方式下調(diào)用SCP
或者SFTP，如果你想獲得更多的關(guān)于SSH的信息，參考如下URLhttp://www.openssh.com
如果你只是用FTP來更新你的Web頁面，有別的替代應(yīng)用，稱為WebDAV的新的協(xié)議，WebDAV
是HTTP的擴(kuò)展，它允許多個(gè)用戶共同編輯和維護(hù)遠(yuǎn)程WEB服務(wù)器上的文件，如果想了解WebDAV
的詳細(xì)信息，參考http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2518.html

FTP是在70年代設(shè)計(jì)出來的，那個(gè)時(shí)候互聯(lián)網(wǎng)還是一個(gè)封閉的網(wǎng)絡(luò)，網(wǎng)絡(luò)安全不是一個(gè)大的問
題。當(dāng)FTP在使用NAT網(wǎng)關(guān)、防火墻、CISCO訪問列表的現(xiàn)代網(wǎng)絡(luò)環(huán)境中運(yùn)用的時(shí)候，不管你使
用Port模式還是Passive模式，都可能產(chǎn)生一些問題，F(xiàn)TP在公網(wǎng)上作為一些關(guān)鍵應(yīng)用的文件傳
輸手段可能就是一個(gè)錯(cuò)誤；當(dāng)然近年很多人為了是FTP協(xié)議更加安全進(jìn)行了不懈的努力，這些
努力卻使對(duì)于FTP的排錯(cuò)更加復(fù)雜，而且都沒有解決FTP最大的問題，即明文傳輸用戶名和口令
。有許多應(yīng)用可以替代FTP，如SCP，SFTP或者WebDAV。

以上為原文總結(jié)，本文下半部分補(bǔ)充了ftp自身的安全擴(kuò)展，使用SSL/TLS進(jìn)行ftp傳輸過程的
驗(yàn)證和加密，良好的實(shí)現(xiàn)了與傳統(tǒng)ftp協(xié)議的兼容性和優(yōu)良的數(shù)據(jù)保密性與完整性。在無法使用
替代服務(wù)的環(huán)境下，是一種非常好的ftp服務(wù)改進(jìn)計(jì)劃。

略有不足的是，由于歷史兼容性因素，很多ftp client和server對(duì)ssl ftp擴(kuò)展的實(shí)現(xiàn)都存在
著各種缺陷，例如加密算法不足，指令順序有錯(cuò)誤等等，這可能會(huì)引起一些安全保護(hù)級(jí)別的削弱。
1, 由于沒有良好的PKI體系支撐，很多ftp server的證書合法性無法得到驗(yàn)證，可能存在無法
信任或被偽造的可能；
2, 由于Explicit SSL模式的歷史兼容問題，AUTH指令和USER/PASS指令序列的優(yōu)先級(jí)沒有明確
約定，可能存在指令序列錯(cuò)誤造成信息泄露的問題；
3, 由于SSL自身體系的一些問題，可能受到證書泄露，偽造，或SSL中間人攻擊;
4, 在不完整的CA或PKI體系下，只能夠采用自簽名證書，這時(shí)SSL ftp得到的安全性提高僅僅
是通訊過程加密，并無法完成身份認(rèn)證的功能。

當(dāng)然，排除無法實(shí)現(xiàn)身份認(rèn)證功能和略微的實(shí)現(xiàn)缺陷，ssl ftp仍然是一種優(yōu)秀的ftp服務(wù)安全加強(qiáng)
措施。

>>5.0<< 參考

ftp協(xié)議簇
http://www.ietf.org/rfc/rfc959.txt
http://www.ietf.org/rfc/rfc1579.txt

ftp安全擴(kuò)展
http://www.ietf.org/rfc/rfc2228.txt
http://www.ietf.org/rfc/rfc2246.txt

ftp安全擴(kuò)展，SSL接口草案:
http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-13.txt

ssl/tls協(xié)議規(guī)范:

#p# http://www.ietf.org/rfc/rfc2246.txt

OpenSSL,一個(gè)廣為應(yīng)用的SSL實(shí)現(xiàn):
http://www.openssl.org

支持ssl ftp的ftp client:
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext_col.html#client

支持ssl ftp的ftp server:
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext_col.html#server

亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

FTP協(xié)議的分析和擴(kuò)展

相關(guān)文章

最新評(píng)論

文章分類

大家感興趣的內(nèi)容

最近更新的內(nèi)容