FTP协议的分析和扩展
生活随笔
收集整理的這篇文章主要介紹了
FTP协议的分析和扩展
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
2019獨角獸企業(yè)重金招聘Python工程師標準>>>
FTP協(xié)議的分析和擴展
出處： http://elly.blogdriver.com/index.jsp>> 1.0<< FTP和TCP端口號
根據(jù)是使用Port模式還是Passive模式，FTP使用不同的TCP端口號，在詳細描述FTP前，我們來
簡單討論一下TCP端口號的一些基本概念。TCP使用端口號來標識所發(fā)送和接收的應用，端口號
可以幫助TCP來分離字節(jié)流并且?guī)拖鄳止?jié)傳遞給正確的應用程序。
TCP端口號可以是半永久的和暫時的。服務器端監(jiān)聽在半永久的端口上來讓客戶端訪問。客戶
端使用暫時的端口在本地標識一個對話，客戶端端口只在使用TCP服務時候才存在，而服務器
端口只要服務器在運行就一直在監(jiān)聽。
TCP端口可以歸為3類：
1、眾所周知的端口來標識在TCP上運行的標準服務，包括FTP、HTTP、TELNET、SMTP等，這些
端口號碼范圍為0-1023；
2、注冊端口號用來標識那些已經(jīng)向IANA（Internet Assigned Numbers Assigned Numbers
Authority）注冊的應用，注冊端口號為1024-49151；
3、私有端口號是非注冊的并且可以動態(tài)地分配給任何應用，私有端口為49152-65535；
注冊的端口號本來打算只給注冊的應用使用，可近年來端口號已經(jīng)陷入了到達極限的困境，你
可能會看到本來應該是給注冊應用使用的注冊端口被非注冊應用用做暫時的端口。RFC1700詳
細標注了眾所周知的和注冊的端口號，然而不幸的是，這個RFC文檔自從1994年以來一直沒有
被更新，然后你仍可以從IANA得到一個及時更新的端口列表，詳細URL為：
http://www.iana.org/assignments/port-numbers
>> 2.0<< FTP Port模式和FTP Passive模式
當你對一個FTP問題進行排錯時候，你首先要問的一個問題是使用的是port模式的還是passive
模式。因為這兩種行為迥異，所以這兩種模式引起的問題也不同；在過去，客戶端缺省為acti
ve(port)模式；近來，由于Port模式的安全問題，許多客戶端的FTP應用缺省為Passive模式。
>>2.1 FTP Port模式
Port模式的FTP步驟如下：
1、 客戶端發(fā)送一個TCP SYN（TCP同步）包給服務器段眾所周知的FTP控制端口21，客戶端
使用暫時的端口作為它的源端口；
2、 服務器端發(fā)送SYN ACK（同步確認）包給客戶端，源端口為21，目的端口為客戶端上使用
的暫時端口；
3、 客戶端發(fā)送一個ACK（確認）包；客戶端使用這個連接來發(fā)送FTP命令，服務器端使用這個
連接來發(fā)送FTP應答；
4、 當用戶請求一個列表(List)請求或者發(fā)起一個要求發(fā)送或者接受文件的請求，客戶端軟件使用
PORT命令，這個命令包含了一個暫時的端口，客戶端希望服務器在打開一個數(shù)據(jù)連接時候使用
這個暫時端口；PORT命令也包含了一個IP地址，這個IP地址通常是客戶自己的IP地址，而且FT
P也支持第三方（third-party）模式，第三方模式是客戶端告訴服務器端打開與另臺主機的連接；
5、 服務器端發(fā)送一個SYN包給客戶端的暫時端口，源端口為20，暫時端口為客戶端在PORT命令中
發(fā)送給服務器端的暫時端口號；
6、 客戶端以源端口為暫時端口，目的端口為20發(fā)送一個SYN ACK包；
7、 服務器端發(fā)送一個ACK包；
8、 發(fā)送數(shù)據(jù)的主機以這個連接來發(fā)送數(shù)據(jù)，數(shù)據(jù)以TCP段(注：segment，第4層的PDU)形式發(fā)送（
一些命令，如STOR表示客戶端要發(fā)送數(shù)據(jù)，RETR表示服務器段發(fā)送數(shù)據(jù)），這些TCP段都需要
對方進行ACK確認（注：因為TCP協(xié)議是一個面向連接的協(xié)議）
9、 當數(shù)據(jù)傳輸完成以后，發(fā)送數(shù)據(jù)的主機以一個FIN命令來結束數(shù)據(jù)連接，這個FIN命令需要另一
臺主機以ACK確認，另一臺主機也發(fā)送一個FIN命令，這個FIN命令同樣需要發(fā)送數(shù)據(jù)的主機以A
CK確認；
10、 客戶端能在控制連接上發(fā)送更多的命令，這可以打開和關閉另外的數(shù)據(jù)連接；有時候客戶端結
束后，客戶端以FIN命令來關閉一個控制連接，服務器端以ACK包來確認客戶端的FIN，服務器
同樣也發(fā)送它的FIN，客戶端用ACK來確認。
下圖圖示了FTP PORT模式前幾步步驟：
/====================================================================\
| |
| [ ftp Client ] [ ftp Server ] |
| |
| (TCP:21 連接初始化,控制端口) |
| SYN |
| Port xxxx ----------------------> Port 21 [TCP] |
| SYN+ACK |
| Port xxxx <---------------------- Port 21 |
| ACK |
| Port xxxx ----------------------> Port 21 |
| |
| (控制操作: 用戶列目錄或傳輸文件) |
| |
| Port, IP, Port yyyy |
| Port xxxx <---------------------- Port 21 |
| Port Seccussful |
| Port xxxx <---------------------- Port 21 |
| List, Retr or Stor |
| Port xxxx ----------------------> Port 21 |
| |
| |
| (TCP:20 連接初始化,數(shù)據(jù)端口) |
| SYN |
| Port yyyy <---------------------- Port 20 |
| SYN+ACK |
| Port yyyy ----------------------> Port 20 |
| ACK |
| Port yyyy <---------------------- Port 20 |
| |
| |
| (數(shù)據(jù)操作: 數(shù)據(jù)傳輸) |
| Data + ACK |
| Port yyyy <---------------------> Port 20 |
| . |
| . |
| . |
| |
\====================================================================/
FTP Port模式會給網(wǎng)絡管理人員在許多方面帶來很多問題，首先，在PORT命令消息中的IP地址和端
口號的編碼不是直白地顯示。另外，應用層的協(xié)議命令理論上不應該包含網(wǎng)絡地址信息（注：
IP地址），因為這打破了協(xié)議層的原則并且可能導致協(xié)同性和安全性方面的問題。
下圖是WildPackets EtherPeek協(xié)議分析儀解碼了PORT命令的地址參數(shù)，地址參數(shù)后是端口號，見PORT
192,168,10,232,6,127；6，127部分的第一個阿拉伯數(shù)字乘以256，然后加上第2個阿拉伯數(shù)字
就得到端口號，所以客戶端指定了端口號為6*256+127=1663；
/====================================================================\
| IP Header - Internet Protocol Datagram |
| Version: 4 |
| Header Length: 5 (20 bytes) |
| |
| ............... |
| |
| Time To Live: 128 |
| Protocol: 6 TCP - Transmission Control Protocol |
| Header Checksum: 0xAA36 |
| Source IP Address: 192.168.0.1 DEMO |
| Dest. IP Address: 192.168.0.3 VI |
| No IP Options |
| |
| TCP - Transport Control Protocol |
| Source Port: 2342 manage-exec |
| Destination Port: 21 ftp |
| Sequence Number: 2435440100 |
| Ack Number: 9822605 |
| Offset: 5 (20 bytes) |
| Reserved: %000000 |
| Flags: %011000 |
| 0. .... (No Urgent pointer) |
| .1 .... Ack |
| .. 1... Push |
| .. .0.. (No Reset) |
| .. ..0. (No SYN) |
| .. ...0 (No FIN) |
| |
| Window: 65150 |
| Checksum: 0x832A |
| Urgent Pointer: 0 |
| No TCP Options |
| |
| FTP Control - File Transfer Protocol |
| Line 1: PORT 192,168,0,1,9,39<CR><LF> |
| |
| FCS - Frame Check Sequence |
| FCS (Calculated): 0xF4C04A4F |
\====================================================================/
下圖驗證了服務器端的確從端口20打開到端口1663的TCP連接：
/====================================================================\
| TCP - Transport Control Protocol |
| Source Port: 20 ftp-data |
| Destination Port: 1663 |
| Sequence Number: 2578824336 |
| Ack Number: 0 |
| Offset: 6 (24 bytes) |
| Reserved: %000000 |
| Flags: %000010 |
| 0. .... (No Urgent pointer) |
| .0 .... (No Ack) |
| .. 0... (No Push) |
| .. .0.. (No Reset) |
| .. ..1. SYN |
| .. ...0 (No FIN) |
| |
| Window: 3731 |
| Checksum: 0x8A4C |
| Urgent Pointer: 0 |
| No TCP Options |
| |
| TCP Options |
| Options Type: 2 Maxinum Segment Size |
| Length: 4 |
| MSS: 1460 |
| |
| FCS - Frame Check Sequence |
| FCS (Calculated): 0x5A1BD023 |
\====================================================================/
當使用FTP時候，網(wǎng)絡中的防火墻必須要聲明相應的端口，防火墻必須要跟蹤FTP對話然后檢查
PORT命令，防火墻必須要參與從服務器端到客戶端在PORT命令中指定的端口連接的建立過程。
如果網(wǎng)絡中使用了NAT（注：網(wǎng)絡地址翻譯），那么NAT的網(wǎng)關同樣也需要聲明相應的端口，網(wǎng)
關需要把在PORT命令中指定的IP地址翻譯成分配給客戶的地址，然后重新計算TCP的Checksum
；如果網(wǎng)關沒有正確地執(zhí)行這個操作，FTP就失敗了。
黑客可能會利用FTP支持第三方特性這一特點，在PORT命令中設置IP地址和端口號參數(shù)來指定
一臺目標主機的地址和端口號（有時候稱這種攻擊為FTP反彈攻擊），例如黑客可以讓一臺FTP
服務器不斷地從它的源端口20發(fā)送TCP SYN包給一系列目的端口，讓FTP服務器看起來正在進行
端口掃描，目的主機不知道攻擊來自黑客的主機，看起來攻擊象是來自FTP服務器。一些常用的
FTP應用在PORT命令中設置地址為0.0.0.0，這樣做的意圖是讓FTP服務器只需要與打開控制連接
的相同客戶進行數(shù)據(jù)連接，設置地址為0.0.0.0可能會讓防火墻不知所措。例如，CISCO PIX IOS
6.0以上版本的PIX（注：CISCO硬件防火墻設備，6.0以上版本為其修正了相關的FTP協(xié)議）
要求數(shù)據(jù)連接的IP地址與已經(jīng)存在的控制連接的IP地址必須相同。這樣做的原因是防止黑客用
PORT命令來攻擊別的機器，雖然一些FTP應用設置IP地址為0.0.0.0不是有意圖的攻擊，但在PI
X修正協(xié)議環(huán)境下的確引起了一些問題，同時對其他不允許第三方模式和避免FTP反彈攻擊的防
火墻來說，這也會引起相同的問題。
>>2.2 FTP Passive模式
下面的列表描述了Passive模式的FTP的步驟，步驟1到3和Port模式FTP相同，步驟9到11同樣與
Port模式FTP最后三步相同。
1、客戶端發(fā)送一個TCP SYN（TCP同步）包給服務器段眾所周知的FTP控制端口21，客戶端使
用暫時的端口作為它的源端口；
2、服務器端發(fā)送SYN ACK（同步確認）包給客戶端，源端口為21，目的端口為客戶端上使用
的暫時端口；
3、客戶端發(fā)送一個ACK（確認）包；客戶端使用這個連接來發(fā)送FTP命令，服務器端使用這個
連接來發(fā)送FTP應答；
4、當用戶請求一個列表(List)或者發(fā)送或接收文件時候，客戶端軟件發(fā)送PASV命令給服務器端
表明客戶端希望進入Passive模式；
5、服務器端進行應答，應答包括服務器的IP地址和一個暫時的端口，這個暫時的端口是客戶端
在打開數(shù)據(jù)傳輸連接時應該使用的端口；
6、客戶端發(fā)送一個SYN包，源端口為客戶端自己選擇的一個暫時端口，目的端口為服務器在PASV
應答命令中指定的暫時端口號；
7、服務器端發(fā)送SYN ACK包給客戶端，目的端口為客戶端自己選擇的暫時端口，源端口為PASV
應答中指定的暫時端口號；
8、客戶端發(fā)送一個ACK包；
9、發(fā)送數(shù)據(jù)的主機以這個連接來發(fā)送數(shù)據(jù)，數(shù)據(jù)以TCP段(注：segment，第4層的PDU)形式發(fā)送（
一些命令，如STOR表示客戶端要發(fā)送數(shù)據(jù)，RETR表示服務器段發(fā)送數(shù)據(jù)），這些TCP段都需要
對方進行ACK確認；
10、當數(shù)據(jù)傳輸完成以后，發(fā)送數(shù)據(jù)的主機以一個FIN命令來結束數(shù)據(jù)連接，這個FIN命令需要另一
臺主機以ACK確認，另一臺主機也發(fā)送一個FIN命令，這個FIN命令同樣需要發(fā)送數(shù)據(jù)的主機以A
CK確認；
11、客戶端能在控制連接上發(fā)送更多的命令，這可以打開和關閉另外的數(shù)據(jù)連接；有時候客戶端結
束后，客戶端以FIN命令來關閉一個控制連接，服務器端以ACK包來確認客戶端的FIN，服務器
同樣也發(fā)送它的FIN，客戶端用ACK來確認。
下圖圖示了Passive模式FTP的開始幾個步驟：
/====================================================================\
| |
| [ ftp Client ] [ ftp Server ] |
| |
| (TCP:21 連接初始化,控制端口) |
| SYN |
| Port xxxx ----------------------> Port 21 [TCP] |
| SYN+ACK |
| Port xxxx <---------------------- Port 21 |
| ACK |
| Port xxxx ----------------------> Port 21 |
| |
| (PASV操作: 被動連接數(shù)據(jù)端口初始化) |
| |
| PASV |
| Port xxxx ----------------------> Port 21 |
| PASV OK, IP, Port yyyy |
| Port xxxx <---------------------- Port 21 |
| SYN |
| Port zzzz ----------------------> Port yyyy |
| SYN+ACK |
| Port zzzz <---------------------- Port yyyy |
| ACK |
| Port zzzz ----------------------> Port yyyy |
| |
| |
| (數(shù)據(jù)操作: 數(shù)據(jù)傳輸) |
| List, Retr or Stor |
| Port xxxx ----------------------> Port 21 |
| Data + ACK |
| Port zzzz <---------------------> Port yyyy |
| . |
| . |
| . |
| |
\====================================================================/
一個PASV請求要求服務器在服務器選擇的一個新的端口上接受數(shù)據(jù)連接，PASV命令沒有任何參
數(shù)，服務器端的回應只是一行顯示服務器IP地址和服務器接受連接的TCP端口號。
下圖顯示了服務器對PASV命令的回應，服務器告訴客戶端它在端口5365（192,168,179,100,20
,245）上進行監(jiān)聽，計算端口的方法是20*256+245=5365；
/====================================================================\
| TCP - Transport Control Protocol |
| Source Port: 21 ftp |
| Destination Port: 1249 |
| Sequence Number: 4239887193 |
| Ack Number: 36925357 |
| Offset: 5 (20 bytes) |
| Reserved: %000000 |
| Flags: %011000 |
| 0. .... (No Urgent pointer) |
| .1 .... Ack |
| .. 1... Push |
| .. .0.. (No Reset) |
| .. ..0. (No SYN) |
| .. ...0 (No FIN) |
| |
| Window: 8760 |
| Checksum: 0x3EAB |
| Urgent Pointer: 0 |
| No TCP Options |
| |
| FTP Control - File Transfer Protocol |
| Line 1: PASV 192,168,0,1,100,20,245<CR><LF> |
| |
| FCS - Frame Check Sequence |
| FCS (Calculated): 0xBED4346D |
\====================================================================/
當收到PASV命令的回應后，客戶端打開一個TCP連接，源端口為一個暫時的端口，目的端口為
服務器提供的暫時端口。
下圖顯示了客戶端的TCP連接建立過程，正如上面所說，目的端口為5365。
/====================================================================\
| TCP - Transport Control Protocol |
| Source Port: 1250 |
| Destination Port: 5365 |
| Sequence Number: 36931503 |
| Ack Number: 0 |
| Offset: 7 (28 bytes) |
| Reserved: %000000 |
| Flags: %000010 |
| 0. .... (No Urgent pointer) |
| .0 .... (No Ack) |
| .. 0... (No Push) |
| .. .0.. (No Reset) |
| .. ..1. SYN |
| .. ...0 (No FIN) |
| |
| Window: 8192 |
| Checksum: 0x1A57 |
| Urgent Pointer: 0 |
| No TCP Options |
| |
| TCP Options |
| Options Type: 2 Maxinum Segment Size |
| Length: 4 |
| MSS: 1460 |
| |
| FCS - Frame Check Sequence |
| FCS (Calculated): 0x5A1BD023 |
\====================================================================/
大多數(shù)人認為在防火墻網(wǎng)絡環(huán)境中Passive模式比Port模式的問題小，但我們注意到在Passive
模式下，客戶端打開一個暫時的目的端口連接，一些防火墻或者CISCO設備的訪問列表(ACL)可
能會阻止這種連接，同樣服務器的回應也是從一個暫時的端口到一個暫時的端口，防火墻或者
CISCO的訪問列表也會阻止這種連接。在CISCO路由器上你可以用訪問列表關鍵字"established
"來避免第二個問題，"established"關鍵字告訴路由器允許帶ACK字端的包通過，服務器端的S
YN ACK包帶有ACK字端。在新版本PIX IOS中也可以通過fixit關鍵字建立針對ftp協(xié)議的深層狀
態(tài)檢測過濾，其他大多數(shù)狀態(tài)檢測防火墻例如LinuxNetfilters也支持ftp協(xié)議的狀態(tài)檢測，進行
準確的PASV動態(tài)端口過濾。
>>2.3 用戶名和口令的明文傳輸
FTP另一個聲名狼藉的問題是它以明文方式發(fā)送用戶名和口令，也就是不加密地發(fā)送。任何人
只要在網(wǎng)絡中合適的位置放置一個協(xié)議分析儀就可以看到用戶名和口令；FTP發(fā)送的數(shù)據(jù)也是
以明文方式傳輸，通過對ftp連接的監(jiān)控和數(shù)據(jù)收集就可以收集和重現(xiàn)ftp的數(shù)據(jù)傳輸并實現(xiàn)協(xié)
議連接回放。事實上很多用戶把相同的用戶名和口令用在不同的應用中，這樣這個問題可能
看起來更為糟糕；如果黑客收集到FTP口令，他們也可能就得到了你在線帳號或者其他一些
機密數(shù)據(jù)的口令。
下面是通過tcpdump -- 一個著名的網(wǎng)絡協(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 ........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<< 改進: ftp安全擴展, SSL/TLS
在傳統(tǒng)的ftp通訊和傳輸過程中可以看出，ftp協(xié)議提供了一種簡單實用的網(wǎng)絡文件傳輸方法，
但是缺陷也是顯而易見的。傳統(tǒng)ftp服務缺乏對數(shù)據(jù)的機密性和完整性保護，對通訊雙方也沒
有可靠的認證措施，同時還存在著明文信息傳輸?shù)娜觞c --
在同一個網(wǎng)絡上的任何用戶都可能竊取到重要的信息。雖然近年來出現(xiàn)了很多種ftp的替代服
務，例如ssh加密通道的sftp/scp，或使用IPSEC協(xié)議的VPN通道等等，但是在大多數(shù)情況下，f
tp的通用性和易用性使得它在很長一段時間內(nèi)必然無法被完全取代。所以如同其他一系列古董
服務(例如SMTP/HTTP)一樣，近年來也出現(xiàn)了一些不需要對ftp協(xié)議自身做完全更改的協(xié)議擴展
模塊，能夠良好的完成兼容性和功能擴展。ftp SSL/TLS Extension就是其中一種方式。
FTP安全擴展: http://www.ietf.org/rfc/rfc2228.txt
http://www.ietf.org/rfc/rfc2246.txt
FTP安全擴展，SSL接口草案:
http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-13.txt
>> 3.1 SSL/TLS簡介
先說一下SSL/TLS協(xié)議，SSL(Secure Socket
Layer)最早是netscape公司設計的用于HTTP協(xié)議加密的安全傳輸協(xié)議，SSL工作于TCP協(xié)議的傳
輸層(TCP層)和應用程序之間。作為一個中間層，應用程序只要采用SSL提供的一套SSL套接字A
PI來替換標準的Socket套接字，就可以把程序轉換為SSL化的安全網(wǎng)絡程序，在傳輸過程中將
由SSL協(xié)議實現(xiàn)數(shù)據(jù)機密性和完整性的保證。SSL協(xié)議的當前版本為3.0，當SSL取得大規(guī)模成功
后，IETF( www.ietf.org)將SSL作了標準化，規(guī)范為RFC2246，并將其稱為TLS（Transport
Layer
Security）。從技術上講，TLS1.0與SSL3.0的差別非常微小，SSL由于其歷史應用的原因在當
前的商業(yè)應用程序之中使用得更多一些。
TLS協(xié)議，RFC 2246: http://www.ietf.org/rfc/rfc2246.txt
>> 3.2 數(shù)據(jù)機密性和完整性
前面多次提到了數(shù)據(jù)的機密性和完整性兩個方面，在此略微解釋一下。數(shù)據(jù)的機密性確保數(shù)據(jù)
信息機密可靠，不會被沒有權限的對象所訪問和瀏覽到，基本的機密性保護手段就是數(shù)據(jù)加密
；而數(shù)據(jù)的完整性則是指數(shù)據(jù)在傳輸和存儲過程中將保證數(shù)據(jù)的唯一和完整，不會被惡意篡改
著所修改，保證數(shù)據(jù)完整性的基本手段主要有數(shù)字簽名。
這里就牽扯到數(shù)據(jù)加密領域的兩類算法，加密算法和散列算法。加密算法從數(shù)學原理上看可以
分為對稱加密和非對稱加密，從數(shù)據(jù)處理方法上可以分為流加密和分組加密，本文重點不在此
，不再贅述，只舉例幾種常用的加密算法: DES, 3DES, AES,
BlowFish,RC2-RC6等等。數(shù)據(jù)簽名算法是加密領域的另一套方法，又叫數(shù)據(jù)散列算法，用于對
數(shù)據(jù)進行處理生成一個唯一的等長簽名字符串，原數(shù)據(jù)的長度可能是任意的，而任意兩個相似
但哪怕只有少許細微差別的數(shù)據(jù)集，都將產(chǎn)生差別非常大的等長簽名字符串，這個字符串在一
般意義下被認為是極少會發(fā)生空間沖突(重復)的，因此數(shù)據(jù)散列算法對于確保數(shù)據(jù)的唯一性是
一種必要的手段；常見的數(shù)字散列算法有MD5，SHA-1，CAST-256等等。
可以看出，面對如此多種類的加密算法，應用程序處理起來是很繁瑣的。SSL在這個層次中就
提供了一種自動的算法協(xié)商，密鑰交換和數(shù)據(jù)加密過程。SSL協(xié)議分為兩部分：Handshake
Protocol和Record
Protocol，HandShake部分用于處理通訊雙方的算法協(xié)商和密鑰交換過程，Record部分用于對
數(shù)據(jù)進行加密傳輸。
整個的SSL基本通訊過程如下:
/====================================================================\
| |
| [ SSL Client ] [ SSL Server ] |
| |
| (TCP三步握手) |
| (SSL套結字連接) |
| . |
| . SSLSocket() |
| . Bind() |
| SSLSocket() -------------------> |
| <------------------- Connect |
| (連接加密算法協(xié)商) |
| ClientHello() -------------------> |
| (服務器端算法確認和證書發(fā)送)|
| ServerHello |
| Certificate* |
| ServerKeyExchange* |
| CertificateRequest* |
| <------------------- ServerHelloDone |
| (客戶端證書驗證與密鑰交換) |
| Certificate* |
| ClientKeyExchange |
| CertificateVerify* |
| [ChangeCipherSpec] |
| Finished -------------------> (數(shù)據(jù)加密算法協(xié)商) |
| [ChangeCipherSpec] |
| <------------------- Finished |
| (應用數(shù)據(jù)加密傳輸) |
| Application Data <------------------> Application Data |
| ... |
\====================================================================/
SSL套結字通訊過程如下:
1, Client和Server雙方程序通過ssl socket系列函數(shù)替換BSD Socket系列函數(shù)；
2, Client通過TCP協(xié)議連接到Server端應用程序；
3, Client發(fā)起連接質(zhì)詢，發(fā)送自身所能實現(xiàn)的"安全集合"，其中包含加密和簽名算法協(xié)商；
4, Server回應連接，包含本次通訊所使用的算法集合，以及Server端證書；
5, Client收到證書后，使用Server端協(xié)商的算法，用Server端證書中包含的Server公鑰加密一個
隨機序列，作為一個挑戰(zhàn)質(zhì)詢發(fā)回Server；
6, Server收到加密密文，使用自身的私鑰進行數(shù)據(jù)解密，如果成功，代表SA協(xié)商匹配，可以
開始通訊；
7, 可選過程，繼續(xù)發(fā)起Client端驗證過程，Client端發(fā)出Client證書，進行Client端驗證過程；
8, 可選過程，數(shù)據(jù)傳輸過程加密算法協(xié)商；
9, 協(xié)商完畢，開始加密數(shù)據(jù)傳輸；
可以看出，SSL Socket通訊過程相比正常的BSD Socket，只不過多了一個安全集合交換協(xié)商的過程，
這個過程由SSL實現(xiàn)自身來完成，相對于應用程序，只要采用了SSL Socket，其他的過程都是
透明的。SSL通訊過程中的第3-6步是必須操作，包含了Server端驗證過程和加密算法協(xié)商，類
似于TCP協(xié)議的三步握手過程，這個過程中通過公鑰加密算法加密密鑰(公鑰)和解密秘鑰(私鑰)
不同的功能，巧妙地實現(xiàn)了密鑰交換和算法協(xié)商，并且由于解密秘鑰不需要在網(wǎng)絡上傳輸，這樣
就同時實現(xiàn)了數(shù)據(jù)通訊過程的保密性和內(nèi)部應用程序協(xié)議的保密性。在第7步進行Client端證書
的驗證過程中，由于當前網(wǎng)絡環(huán)境下PKI和CA體系尚不完善，并且由于SSL設計的工作環(huán)境相對
對Client端的安全需求并不很高，所以Client端驗證一般作為一種可選手段來實現(xiàn)，取決于應
用程序的安全等級需求。
SSL數(shù)據(jù)通訊的機密性特性就是由上面的過程完成的，在算法協(xié)商過程中除了加密算法的協(xié)商外
還會交換一個數(shù)據(jù)簽名算法，用于對數(shù)據(jù)生成一個唯一的散列校驗碼，防止在傳輸過程中數(shù)據(jù)
被篡改，數(shù)據(jù)簽名過程實現(xiàn)了通訊過程的完整性保證。
對應于SSL所提供的兩種安全特性，機密性和保密性，ssl定義了四個安全級別，分別是這兩種
特性的狀態(tài)組合:
'C' - Clear - 沒有任何保護
'S' - Safe - 完整性實現(xiàn)，但是沒有機密性
'E' - Confidential - 機密性實現(xiàn)，但是沒有完整性
'P' - Private - 同時實現(xiàn)機密性和完整性
ftp的ssl擴展使用了其中的兩種狀態(tài)
1)Clear (requested by 'PROT C')
2)Private (requested by 'PROT P')
在連接過程中通過ftp擴展指令PROT來完成狀態(tài)的切換。
>>3.3 ssl FTP擴展
在RFC 2228中，ftp協(xié)議擴展了如下指令:
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擴展相關的主要指令有以下幾條:
AUTH (協(xié)商擴展驗證): 指定擴展認證方法,SSL或TLS；
PBSZ (協(xié)商保護緩沖區(qū)): 制定保護緩沖區(qū),SSL/TLS模式中必須為0；
PROT (切換保護級別): 切換保護級別，可以為"C"無保護，或"P"保護級別；
在一個典型的ftp ssl通訊過程中指令序列如下:
/====================================================================\
| Client Server |
| control data data control |
|====================================================================|
| |
| socket() |
| bind() |
| socket() |
| connect() -------------------------------------------> accept() |
| <------------------------------------------- 220 |
| AUTH TLS -------------------------------------------> |
| <------------------------------------------- 234 |
| TLSneg() <------------------------------------------> TLSneg() |
| PBSZ 0 -------------------------------------------> |
| <------------------------------------------- 200 |
| PROT P -------------------------------------------> |
| <------------------------------------------- 200 |
| USER elly -------------------------------------------> |
| <------------------------------------------- 331 |
| PASS **** -------------------------------------------> |
| <------------------------------------------- 230 |
| |
\====================================================================/
一個SSL FTP的連接過程實例:
/====================================================================\
| |
| WinSock 2.0 -- OpenSSL 0.9.7d 17 Mar 2004 |
| [R] Connecting to 192.168.21.3 -> IP=192.168.21.3 PORT=2121 |
| [R] Connected to 192.168.21.3 |
| [R] 220 Please enter your login name now. |
| [R] AUTH TLS (認證方法)|
| [R] 234 AUTH Command OK. Initializing SSL connection. |
| [R] Connected. Negotiating SSL/TLS session.. |
| [R] SSL/TLS negotiation successful... (協(xié)商關聯(lián))|
| [R] TLSv1/SSLv3 encrypted session using cipher AES256-SHA (256 bits)
| [R] PBSZ 0 (PBSZ設置)|
| [R] 200 PBSZ Command OK. Protection buffer size set to 0. |
| [R] USER elly (ftp傳統(tǒng)認證)|
| [R] 331 Password required for elly . |
| [R] PASS (hidden) |
| [R] 230 User elly logged in. |
| [R] SYST |
| [R] 215 UNIX Type: L8 , CP:936 |
| [R] FEAT (擴展指令測試)|
| [R] 211-Extensions supported: |
| [R] SIZE |
| [R] MDTM |
| [R] MDTM YYYYMMDDHHMMSS filename |
| [R] LIST -laT |
| [R] STAT -laT |
| ... |
| [R] AUTH SSL |
| [R] AUTH TLS |
| [R] PROT |
| [R] PBSZ |
| [R] SSCN |
| [R] UTF8 |
| [R] 211 END |
| [R] CLNT FlashFXP 2.2.985 |
| [R] 213 client type set to FlashFXP 2.2.985. |
| [R] PWD (傳統(tǒng)通訊過程)|
| [R] 257 "/" is current directory |
| [R] TYPE A |
| [R] 200 Type set to ASCII. |
| [R] PROT P (切換到保護模式)|
| [R] 200 PROT P accepted. |
| [R] PASV |
| [R] 227 Entering Passive Mode (192,168,21,3,5,122) |
| [R] Opening data connection IP: 192.168.21.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] 226-free disk space under this directory : 101 mb |
| [R] 226 Transfer finished successfully. Data connection closed . |
| [R] List Complete: 181 bytes in 0.14 seconds (1.26 KBps) |
| |
\====================================================================/
在ssl ftp中，有以下幾個特殊點:
1, AUTH是可選指令，因為ssl ftp實現(xiàn)的方式不同而存在，詳見下一節(jié)explicit SSL
與implicit SSL；
2, PBSZ和PROT是必須指令，用于切換到保護通道模式；
3, AUTH，PBSZ和PROT指令是實現(xiàn)SSL認證方式的必須方法，但可以與傳統(tǒng)的User/Password
模式共存，或只取其一；
4, SSL認證方法的SSL認證過程(AUTH/PBSZ)和傳統(tǒng)模式認證并無嚴格的先后順序關聯(lián)，可能在
用戶名和密碼之前，也可能在之后；但出于安全因素，最好在User/Password傳輸之前切換
到安全模式，可以確保User/Password的傳輸安全；
5, 在explicit SSL模式中，可以在任何時間切換到保護模式，如第四條所述；在implicit
SSL模式中，初始化連接將直接采用SSL Socket建立，不需要AUTH指令切換。
>>3.4 Explicit SSL和Implicit SSL
由于歷史和軟件兼容性因素，ssl FTP的實現(xiàn)有兩種方式，分別是Explicit SSL和Implicit SSL，
上面的大部分數(shù)據(jù)都是以explicit SSL為范例。
Explicit SSL(外部SSL)，又被稱為AUTH SSL方式；Explicit SSL保持了與傳統(tǒng)ftp服務的
良好兼容性，以一個ftp服務擴展指令的方式存在。初始化連接可以采用與傳統(tǒng)ftp兼容的連
接模式，當需要傳輸加密信息時使用AUTH SSL指令切換到保護模式。使用Explicit SSL時
Server必須完整地實現(xiàn)AUTH/PBSZ/PROT等指令。
Implicit SSL(隱含SSL)，是一個全新的ftp實現(xiàn)方式，在TCP三步握手完成之后就直接使用
SSL Socket進行協(xié)商和通訊，之后將全程采用SSL加密連接。在這種模式中一般ftp server
將監(jiān)聽在一個新的服務端口，IANA指定ftps:tcp:990為implicit SSL ftp的默認端口。因為在
連接初始階段就自動由SSL實現(xiàn)完成了協(xié)商，因此implicit模式中AUTH指令是可選的。
在不考慮兼容性的因素下，在服務期端最好優(yōu)先使用implicit SSL模式，可以獲得更好的保密
特性。
比較兩種ssl ftp實現(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() <-----> ... -+ | |
| | |
\======================================================================/
>>3.5 一些雜亂圖示
在3.3種引用了一個Explicit SSL連接指令序列，這里是對應的Implicit SSL連接過程:
/======================================================================\
| WinSock 2.0 -- OpenSSL 0.9.7d 17 Mar 2004 |
| [R] Connecting to 192.168.21.3 -> IP=192.168.21.3 PORT=9909 |
| [R] Connected to 192.168.21.3 |
| [R] Connected. Negotiating SSL/TLS session.. |
| [R] SSL/TLS negotiation successful... |
| [R] TLSv1/SSLv3 encrypted session using cipher AES256-SHA (256 bits) |
| [R] 220 Please enter your login name now. |
| [R] PBSZ 0 |
| [R] 200 PBSZ Command OK. Protection buffer size set to 0. |
| [R] USER elly |
| [R] 331 Password required for elly . |
| [R] PASS (hidden) |
| [R] 230 User elly logged in. |
| [R] SYST |
| [R] 215 UNIX Type: L8 , CP:936 |
| [R] PROT P |
| [R] 200 PROT P accepted. |
| [R] PASV |
| [R] 227 Entering Passive Mode (192,168,21,3,5,122) |
| [R] Opening data connection IP: 192.168.21.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)加密，無法看到。對應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<< 總結
FTP的替代應用
如今，如果考慮到其他一些安全的文件傳輸選擇，可能看起來沒有理由再使用FTP了，如SCP或
者SFTP，與FTP應用相似但運用SSH（注：Secure
Shell）來進行驗證和加密，如果你使用一臺基于UNIX的服務器，你可以在命令方式下調(diào)用SCP
或者SFTP，如果你想獲得更多的關于SSH的信息，參考如下URL： http://www.openssh.com
如果你只是用FTP來更新你的Web頁面，有別的替代應用，稱為WebDAV的新的協(xié)議，WebDAV
是HTTP的擴展，它允許多個用戶共同編輯和維護遠程WEB服務器上的文件，如果想了解WebDAV
的詳細信息，參考： http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2518.html
FTP是在70年代設計出來的，那個時候互聯(lián)網(wǎng)還是一個封閉的網(wǎng)絡，網(wǎng)絡安全不是一個大的問
題。當FTP在使用NAT網(wǎng)關、防火墻、CISCO訪問列表的現(xiàn)代網(wǎng)絡環(huán)境中運用的時候，不管你使
用Port模式還是Passive模式，都可能產(chǎn)生一些問題，FTP在公網(wǎng)上作為一些關鍵應用的文件傳
輸手段可能就是一個錯誤；當然近年很多人為了是FTP協(xié)議更加安全進行了不懈的努力，這些
努力卻使對于FTP的排錯更加復雜，而且都沒有解決FTP最大的問題，即明文傳輸用戶名和口令
。有許多應用可以替代FTP，如SCP，SFTP或者WebDAV。
以上為原文總結，本文下半部分補充了ftp自身的安全擴展，使用SSL/TLS進行ftp傳輸過程的
驗證和加密，良好的實現(xiàn)了與傳統(tǒng)ftp協(xié)議的兼容性和優(yōu)良的數(shù)據(jù)保密性與完整性。在無法使用
替代服務的環(huán)境下，是一種非常好的ftp服務改進計劃。
略有不足的是，由于歷史兼容性因素，很多ftp client和server對ssl ftp擴展的實現(xiàn)都存在
著各種缺陷，例如加密算法不足，指令順序有錯誤等等，這可能會引起一些安全保護級別的削弱。
1, 由于沒有良好的PKI體系支撐，很多ftp server的證書合法性無法得到驗證，可能存在無法
信任或被偽造的可能；
2, 由于Explicit SSL模式的歷史兼容問題，AUTH指令和USER/PASS指令序列的優(yōu)先級沒有明確
約定，可能存在指令序列錯誤造成信息泄露的問題；
3, 由于SSL自身體系的一些問題，可能受到證書泄露，偽造，或SSL中間人攻擊;
4, 在不完整的CA或PKI體系下，只能夠采用自簽名證書，這時SSL ftp得到的安全性提高僅僅
是通訊過程加密，并無法完成身份認證的功能。
當然，排除無法實現(xiàn)身份認證功能和略微的實現(xiàn)缺陷，ssl ftp仍然是一種優(yōu)秀的ftp服務安全加強
措施。
轉載于:https://my.oschina.net/qichang/blog/34280
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎總結
以上是生活随笔為你收集整理的FTP协议的分析和扩展的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 金山安全报告：二月漏洞频出 网站挂马猖獗
- 下一篇： iOS5中 UIViewControll