>>1.0<<FTP和TCP端口号
根据是使用Port模式还是Passive模式，FTP使用不同的TCP端口号，在详细描述FTP前，我们来
简单讨论一下TCP端口号的一些基本概念。TCP使用端口号来标识所发送和接收的应用，端口号
可以帮助TCP来分离字节流并且帮相应字节传递给正确的应用程序。
TCP端口号可以是半永久的和暂时的。服务器端监听在半永久的端口上来让客户端访问。客户
端使用暂时的端口在本地标识一个对话，客户端端口只在使用TCP服务时候才存在，而服务器
端口只要服务器在运行就一直在监听。
TCP端口可以归为3类：
1、众所周知的端口来标识在TCP上运行的标准服务，包括FTP、HTTP、TELNET、SMTP等，这些
端口号码范围为0-1023；
2、注册端口号用来标识那些已经向IANA（InternetAssignedNumbersAssignedNumbers
Authority）注册的应用，注册端口号为1024-49151；
3、私有端口号是非注册的并且可以动态地分配给任何应用，私有端口为49152-65535；
注册的端口号本来打算只给注册的应用使用，可近年来端口号已经陷入了到达极限的困境，你
可能会看到本来应该是给注册应用使用的注册端口被非注册应用用做暂时的端口。RFC1700详
细标注了众所周知的和注册的端口号，然而不幸的是，这个RFC文档自从1994年以来一直没有
被更新，然后你仍可以从IANA得到一个及时更新的端口列表，详细URL为：
http://www.iana.org/assignments/port-numbers
>>2.0<<FTPPort模式和FTPPassive模式
当你对一个FTP问题进行排错时候，你首先要问的一个问题是使用的是port模式的还是passive
模式。因为这两种行为迥异，所以这两种模式引起的问题也不同；在过去，客户端缺省为acti
ve(port)模式；近来，由于Port模式的安全问题，许多客户端的FTP应用缺省为Passive模式。
>>2.1FTPPort模式
Port模式的FTP步骤如下：
1、客户端发送一个TCPSYN（TCP同步）包给服务器段众所周知的FTP控制端口21，客户端
使用暂时的端口作为它的源端口；
2、服务器端发送SYNACK（同步确认）包给客户端，源端口为21，目的端口为客户端上使用
的暂时端口；
3、客户端发送一个ACK（确认）包；客户端使用这个连接来发送FTP命令，服务器端使用这个
连接来发送FTP应答；
4、当用户请求一个列表(List)请求或者发起一个要求发送或者接受文件的请求，客户端软件使用
PORT命令，这个命令包含了一个暂时的端口，客户端希望服务器在打开一个数据连接时候使用
这个暂时端口；PORT命令也包含了一个IP地址，这个IP地址通常是客户自己的IP地址，而且FT
P也支持第三方（third-party）模式，第三方模式是客户端告诉服务器端打开与另台主机的连接；
5、服务器端发送一个SYN包给客户端的暂时端口，源端口为20，暂时端口为客户端在PORT命令中
发送给服务器端的暂时端口号；
6、客户端以源端口为暂时端口，目的端口为20发送一个SYNACK包；
7、服务器端发送一个ACK包；
8、发送数据的主机以这个连接来发送数据，数据以TCP段(注：segment，第4层的PDU)形式发送（
一些命令，如STOR表示客户端要发送数据，RETR表示服务器段发送数据），这些TCP段都需要
对方进行ACK确认（注：因为TCP协议是一个面向连接的协议）
9、当数据传输完成以后，发送数据的主机以一个FIN命令来结束数据连接，这个FIN命令需要另一
台主机以ACK确认，另一台主机也发送一个FIN命令，这个FIN命令同样需要发送数据的主机以A
CK确认；
10、客户端能在控制连接上发送更多的命令，这可以打开和关闭另外的数据连接；有时候客户端结
束后，客户端以FIN命令来关闭一个控制连接，服务器端以ACK包来确认客户端的FIN，服务器
同样也发送它的FIN，客户端用ACK来确认。
下图图示了FTPPORT模式前几步步骤：
/====================================================================
||
|[ftpClient][ftpServer]|
||
|(TCP:21连接初始化,控制端口)|
|SYN|
|Portxxxx---------------------->Port21[TCP]|
|SYN+ACK|
|Portxxxx<----------------------Port21|
|ACK|
|Portxxxx---------------------->Port21|
||
|(控制操作:用户列目录或传输文件)|
||
|Port,IP,Portyyyy|
|Portxxxx<----------------------Port21|
|PortSeccussful|
|Portxxxx<----------------------Port21|
|List,RetrorStor|
|Portxxxx---------------------->Port21|
||
||
|(TCP:20连接初始化,数据端口)|
|SYN|
|Portyyyy<----------------------Port20|
|SYN+ACK|
|Portyyyy---------------------->Port20|
|ACK|
|Portyyyy<----------------------Port20|
||
||
|(数据操作:数据传输)|
|Data+ACK|
|Portyyyy<--------------------->Port20|
|.|
|.|
|.|
||
====================================================================/
FTPPort模式会给网络管理人员在许多方面带来很多问题，首先，在PORT命令消息中的IP地址和端
口号的编码不是直白地显示。另外，应用层的协议命令理论上不应该包含网络地址信息（注：
IP地址），因为这打破了协议层的原则并且可能导致协同性和安全性方面的问题。
下图是WildPacketsEtherPeek协议分析仪解码了PORT命令的地址参数，地址参数后是端口号，见PORT
192,168,10,232,6,127；6，127部分的第一个阿拉伯数字乘以256，然后加上第2个阿拉伯数字
就得到端口号，所以客户端指定了端口号为6*256+127=1663；
/====================================================================
|IPHeader-InternetProtocolDatagram|
|Version:4|
|HeaderLength:5(20bytes)|
||
|...............|
||
|TimeToLive:128|
|Protocol:6TCP-TransmissionControlProtocol|
|HeaderChecksum:0xAA36|
|SourceIPAddress:192.168.0.1DEMO|
|Dest.IPAddress:192.168.0.3VI|
|NoIPOptions|
||
|TCP-TransportControlProtocol|
|SourcePort:2342manage-exec|
|DestinationPort:21ftp|
|SequenceNumber:2435440100|
|AckNumber:9822605|
|Offset:5(20bytes)|
|Reserved:%000000|
|Flags:%011000|
|0.....(NoUrgentpointer)|
|.1....Ack|
|..1...Push|
|...0..(NoReset)|
|....0.(NoSYN)|
|.....0(NoFIN)|
||
|Window:65150|
|Checksum:0x832A|
|UrgentPointer:0|
|NoTCPOptions|
||
|FTPControl-FileTransferProtocol|
|Line1:PORT192,168,0,1,9,39<CR><LF>|
||
|FCS-FrameCheckSequence|
|FCS(Calculated):0xF4C04A4F|
====================================================================/
下图验证了服务器端的确从端口20打开到端口1663的TCP连接：
/====================================================================
|TCP-TransportControlProtocol|
|SourcePort:20ftp-data|
|DestinationPort:1663|
|SequenceNumber:2578824336|
|AckNumber:0|
|Offset:6(24bytes)|
|Reserved:%000000|
|Flags:%000010|
|0.....(NoUrgentpointer)|
|.0....(NoAck)|
|..0...(NoPush)|
|...0..(NoReset)|
|....1.SYN|
|.....0(NoFIN)|
||
|Window:3731|
|Checksum:0x8A4C|
|UrgentPointer:0|
|NoTCPOptions|
||
|TCPOptions|
|OptionsType:2MaxinumSegmentSize|
|Length:4|
|MSS:1460|
||
|FCS-FrameCheckSequence|
|FCS(Calculated):0x5A1BD023|
====================================================================/
当使用FTP时候，网络中的防火墙必须要声明相应的端口，防火墙必须要跟踪FTP对话然后检查
PORT命令，防火墙必须要参与从服务器端到客户端在PORT命令中指定的端口连接的建立过程。
如果网络中使用了NAT（注：网络地址翻译），那么NAT的网关同样也需要声明相应的端口，网
关需要把在PORT命令中指定的IP地址翻译成分配给客户的地址，然后重新计算TCP的Checksum
；如果网关没有正确地执行这个操作，FTP就失败了。
黑客可能会利用FTP支持第三方特性这一特点，在PORT命令中设置IP地址和端口号参数来指定
一台目标主机的地址和端口号（有时候称这种攻击为FTP反弹攻击），例如黑客可以让一台FTP
服务器不断地从它的源端口20发送TCPSYN包给一系列目的端口，让FTP服务器看起来正在进行
端口扫描，目的主机不知道攻击来自黑客的主机，看起来攻击象是来自FTP服务器。一些常用的
FTP应用在PORT命令中设置地址为0.0.0.0，这样做的意图是让FTP服务器只需要与打开控制连接
的相同客户进行数据连接，设置地址为0.0.0.0可能会让防火墙不知所措。例如，CISCOPIXIOS
6.0以上版本的PIX（注：CISCO硬件防火墙设备，6.0以上版本为其修正了相关的FTP协议）
要求数据连接的IP地址与已经存在的控制连接的IP地址必须相同。这样做的原因是防止黑客用
PORT命令来攻击别的机器，虽然一些FTP应用设置IP地址为0.0.0.0不是有意图的攻击，但在PI
X修正协议环境下的确引起了一些问题，同时对其他不允许第三方模式和避免FTP反弹攻击的防
火墙来说，这也会引起相同的问题。
>>2.2FTPPassive模式
下面的列表描述了Passive模式的FTP的步骤，步骤1到3和Port模式FTP相同，步骤9到11同样与
Port模式FTP最后三步相同。
1、客户端发送一个TCPSYN（TCP同步）包给服务器段众所周知的FTP控制端口21，客户端使
用暂时的端口作为它的源端口；
2、服务器端发送SYNACK（同步确认）包给客户端，源端口为21，目的端口为客户端上使用
的暂时端口；
3、客户端发送一个ACK（确认）包；客户端使用这个连接来发送FTP命令，服务器端使用这个
连接来发送FTP应答；
4、当用户请求一个列表(List)或者发送或接收文件时候，客户端软件发送PASV命令给服务器端
#p# 表明客户端希望进入Passive模式；
5、服务器端进行应答，应答包括服务器的IP地址和一个暂时的端口，这个暂时的端口是客户端
在打开数据传输连接时应该使用的端口；
6、客户端发送一个SYN包，源端口为客户端自己选择的一个暂时端口，目的端口为服务器在PASV
应答命令中指定的暂时端口号；
7、服务器端发送SYNACK包给客户端，目的端口为客户端自己选择的暂时端口，源端口为PASV
应答中指定的暂时端口号；
8、客户端发送一个ACK包；
9、发送数据的主机以这个连接来发送数据，数据以TCP段(注：segment，第4层的PDU)形式发送（
一些命令，如STOR表示客户端要发送数据，RETR表示服务器段发送数据），这些TCP段都需要
对方进行ACK确认；
10、当数据传输完成以后，发送数据的主机以一个FIN命令来结束数据连接，这个FIN命令需要另一
台主机以ACK确认，另一台主机也发送一个FIN命令，这个FIN命令同样需要发送数据的主机以A
CK确认；
11、客户端能在控制连接上发送更多的命令，这可以打开和关闭另外的数据连接；有时候客户端结
束后，客户端以FIN命令来关闭一个控制连接，服务器端以ACK包来确认客户端的FIN，服务器
同样也发送它的FIN，客户端用ACK来确认。
下图图示了Passive模式FTP的开始几个步骤：
/====================================================================
||
|[ftpClient][ftpServer]|
||
|(TCP:21连接初始化,控制端口)|
|SYN|
|Portxxxx---------------------->Port21[TCP]|
|SYN+ACK|
|Portxxxx<----------------------Port21|
|ACK|
|Portxxxx---------------------->Port21|
||
|(PASV操作:被动连接数据端口初始化)|
||
|PASV|
|Portxxxx---------------------->Port21|
|PASVOK,IP,Portyyyy|
|Portxxxx<----------------------Port21|
|SYN|
|Portzzzz---------------------->Portyyyy|
|SYN+ACK|
|Portzzzz<----------------------Portyyyy|
|ACK|
|Portzzzz---------------------->Portyyyy|
||
||
|(数据操作:数据传输)|
|List,RetrorStor|
|Portxxxx---------------------->Port21|
|Data+ACK|
|Portzzzz<--------------------->Portyyyy|
|.|
|.|
|.|
||
====================================================================/
一个PASV请求要求服务器在服务器选择的一个新的端口上接受数据连接，PASV命令没有任何参
数，服务器端的回应只是一行显示服务器IP地址和服务器接受连接的TCP端口号。
下图显示了服务器对PASV命令的回应，服务器告诉客户端它在端口5365（192,168,179,100,20
,245）上进行监听，计算端口的方法是20*256+245=5365；
/====================================================================
|TCP-TransportControlProtocol|
|SourcePort:21ftp|
|DestinationPort:1249|
|SequenceNumber:4239887193|
|AckNumber:36925357|
|Offset:5(20bytes)|
|Reserved:%000000|
|Flags:%011000|
|0.....(NoUrgentpointer)|
|.1....Ack|
|..1...Push|
|...0..(NoReset)|
|....0.(NoSYN)|
|.....0(NoFIN)|
||
|Window:8760|
|Checksum:0x3EAB|
|UrgentPointer:0|
|NoTCPOptions|
||
|FTPControl-FileTransferProtocol|
|Line1:PASV192,168,0,1,100,20,245<CR><LF>|
||
|FCS-FrameCheckSequence|
|FCS(Calculated):0xBED4346D|
====================================================================/
当收到PASV命令的回应后，客户端打开一个TCP连接，源端口为一个暂时的端口，目的端口为
服务器提供的暂时端口。
下图显示了客户端的TCP连接建立过程，正如上面所说，目的端口为5365。
/====================================================================
|TCP-TransportControlProtocol|
|SourcePort:1250|
|DestinationPort:5365|
|SequenceNumber:36931503|
|AckNumber:0|
|Offset:7(28bytes)|
|Reserved:%000000|
|Flags:%000010|
|0.....(NoUrgentpointer)|
|.0....(NoAck)|
|..0...(NoPush)|
|...0..(NoReset)|
|....1.SYN|
|.....0(NoFIN)|
||
|Window:8192|
|Checksum:0x1A57|
|UrgentPointer:0|
|NoTCPOptions|
||
|TCPOptions|
|OptionsType:2MaxinumSegmentSize|
|Length:4|
|MSS:1460|
||
|FCS-FrameCheckSequence|
|FCS(Calculated):0x5A1BD023|
====================================================================/
大多数人认为在防火墙网络环境中Passive模式比Port模式的问题小，但我们注意到在Passive
模式下，客户端打开一个暂时的目的端口连接，一些防火墙或者CISCO设备的访问列表(ACL)可
能会阻止这种连接，同样服务器的回应也是从一个暂时的端口到一个暂时的端口，防火墙或者
CISCO的访问列表也会阻止这种连接。在CISCO路由器上你可以用访问列表关键字"established
"来避免第二个问题，"established"关键字告诉路由器允许带ACK字端的包通过，服务器端的S
YNACK包带有ACK字端。在新版本PIXIOS中也可以通过fixit关键字建立针对ftp协议的深层状
态检测过滤，其他大多数状态检测防火墙例如LinuxNetfilters也支持ftp协议的状态检测，进行
准确的PASV动态端口过滤。
>>2.3用户名和口令的明文传输
FTP另一个声名狼藉的问题是它以明文方式发送用户名和口令，也就是不加密地发送。任何人
只要在网络中合适的位置放置一个协议分析仪就可以看到用户名和口令；FTP发送的数据也是
以明文方式传输，通过对ftp连接的监控和数据收集就可以收集和重现ftp的数据传输并实现协
议连接回放。事实上很多用户把相同的用户名和口令用在不同的应用中，这样这个问题可能
看起来更为糟糕；如果黑客收集到FTP口令，他们也可能就得到了你在线帐号或者其他一些
机密数据的口令。
下面是通过tcpdump--一个著名的网络协议分析程序抓取的ftp的完整通讯过程。
/=================================================================
21:55:36.682402IP192.168.0.1.2323>192.168.0.3.21:S2047626269:2047626269(0)
win65535<mss1460,nop,nop,sackOK>(DF)
21:55:36.682792IP192.168.0.3.21>192.168.0.1.2323:S3917547047:3917547047(0)
ack2047626270win65535<mss1460,nop,nop,sackOK>(DF)
21:55:36.682855IP192.168.0.1.2323>192.168.0.3.21:.ack1win65535(DF)
<TCP三步握手>
21:55:36.854899IP192.168.0.3.21>192.168.0.1.2323:P1:115(114)ack1win65535
(DF)
0x00004500009ad57040008006a398c0a80003E....p@.........
0x0010c0a8000100150913e98106287a0c4c1e...........(z.L.
0x00205018ffffcd5000003232302d54686973P....P..220-This
0x00302073657276657220697320666f722070.server.is.for.p
0x004072697661746520757365206f6e6c790drivate.use.only.
0x00500a32.2
21:55:37.016115IP192.168.0.1.2323>192.168.0.3.21:.ack115win65421(DF)
0x000045000028b8d040008006c0aac0a80001E..(..@.........
0x0010c0a80003091300157a0c4c1ee981069a........z.L.....
0x00205010ff8d6f830000P...o...
21:55:37.016471IP192.168.0.3.21>192.168.0.1.2323:P115:154(39)ack1win
65535(DF)
<FTP协议连接>
0x00004500004fd58640008006a3cdc0a80003E..O..@.........
0x0010c0a8000100150913e981069a7a0c4c1e............z.L.
0x00205018ffff074f000032323020506c6561P....O..220.Plea
0x0030736520656e74657220796f7572206c6fse.enter.your.lo
0x004067696e206e616d65206e6f772e0d0agin.name.now...
21:55:37.022282IP192.168.0.1.2323>192.168.0.3.21:P1:12(11)ack154win65382
(DF)
0x000045000033b8d240008006c09dc0a80001E..3..@.........
0x0010c0a80003091300157a0c4c1ee98106c1......
#p# ..z.L.....
0x00205018ff66c4eb00005553455220656c6cP..f....USER.ell
0x0030790d0ay..
<用户名:elly>
21:55:37.059430IP192.168.0.3.21>192.168.0.1.2323:P154:188(34)ack12win
65524(DF)
0x00004500004ad58b40008006a3cdc0a80003E..J..@.........
0x0010c0a8000100150913e98106c17a0c4c29............z.L)
0x00205018fff4b34300003333312050617373P....C..331.Pass
0x0030776f726420726571756972656420666fword.required.fo
0x00407220656c6c79202e0d0ar.elly....
21:55:37.060301IP192.168.0.1.2323>192.168.0.3.21:P12:27(15)ack188win
65348(DF)
0x000045000037b8db40008006c090c0a80001E..7..@.........
0x0010c0a80003091300157a0c4c29e98106e3........z.L)....
0x00205018ff44e47900005041535320383838P..D.y..PASS.888
0x003038383838380d0a88888..
<密码:88888888>
21:55:37.243954IP192.168.0.3.21>192.168.0.1.2323:.ack27win65509(DF)
0x000045000028d59d40008006a3ddc0a80003E..(..@.........
0x0010c0a8000100150913e98106e37a0c4c38............z.L8
0x00205010ffe56ec80000000000000000P...n.........
21:55:37.285586IP192.168.0.3.21>192.168.0.1.2323:.188:1648(1460)ack27win
65509(DF)
0x0000450005dcd5a4400080069e22c0a80003E.....@...."....
0x0010c0a8000100150913e98106e37a0c4c38............z.L8
0x00205010ffe5030000003233302d57656c63P.......230-Welc
0x00306f6d6520746f20766920465450207365ome.to.vi.FTP.se
0x0040727665720d0a3233302d0d0a3233302drver..230-..230-
0x00504375Cu
<明文数据传输>
=================================================================/
>>3.0<<改进:ftp安全扩展,SSL/TLS
在传统的ftp通讯和传输过程中可以看出，ftp协议提供了一种简单实用的网络文件传输方法，
但是缺陷也是显而易见的。传统ftp服务缺乏对数据的机密性和完整性保护，对通讯双方也没
有可靠的认证措施，同时还存在着明文信息传输的弱点--
在同一个网络上的任何用户都可能窃取到重要的信息。虽然近年来出现了很多种ftp的替代服
务，例如ssh加密通道的sftp/scp，或使用IPSEC协议的VPN通道等等，但是在大多数情况下，f
tp的通用性和易用性使得它在很长一段时间内必然无法被完全取代。所以如同其他一系列古董
服务(例如SMTP/HTTP)一样，近年来也出现了一些不需要对ftp协议自身做完全更改的协议扩展
模块，能够良好的完成兼容性和功能扩展。ftpSSL/TLSExtension就是其中一种方式。
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.1SSL/TLS简介
先说一下SSL/TLS协议，SSL(SecureSocket
Layer)最早是netscape公司设计的用于HTTP协议加密的安全传输协议，SSL工作于TCP协议的传
输层(TCP层)和应用程序之间。作为一个中间层，应用程序只要采用SSL提供的一套SSL套接字A
PI来替换标准的Socket套接字，就可以把程序转换为SSL化的安全网络程序，在传输过程中将
由SSL协议实现数据机密性和完整性的保证。SSL协议的当前版本为3.0，当SSL取得大规模成功
后，IETF(www.ietf.org)将SSL作了标准化，规范为RFC2246，并将其称为TLS（Transport
Layer
Security）。从技术上讲，TLS1.0与SSL3.0的差别非常微小，SSL由于其历史应用的原因在当
前的商业应用程序之中使用得更多一些。
TLS协议，RFC2246:
http://www.ietf.org/rfc/rfc2246.txt
>>3.2数据机密性和完整性
前面多次提到了数据的机密性和完整性两个方面，在此略微解释一下。数据的机密性确保数据
信息机密可靠，不会被没有权限的对象所访问和浏览到，基本的机密性保护手段就是数据加密
；而数据的完整性则是指数据在传输和存储过程中将保证数据的唯一和完整，不会被恶意篡改
着所修改，保证数据完整性的基本手段主要有数字签名。
这里就牵扯到数据加密领域的两类算法，加密算法和散列算法。加密算法从数学原理上看可以
分为对称加密和非对称加密，从数据处理方法上可以分为流加密和分组加密，本文重点不在此
，不再赘述，只举例几种常用的加密算法:DES,3DES,AES,
BlowFish,RC2-RC6等等。数据签名算法是加密领域的另一套方法，又叫数据散列算法，用于对
数据进行处理生成一个唯一的等长签名字符串，原数据的长度可能是任意的，而任意两个相似
但哪怕只有少许细微差别的数据集，都将产生差别非常大的等长签名字符串，这个字符串在一
般意义下被认为是极少会发生空间冲突(重复)的，因此数据散列算法对于确保数据的唯一性是
一种必要的手段；常见的数字散列算法有MD5，SHA-1，CAST-256等等。
可以看出，面对如此多种类的加密算法，应用程序处理起来是很繁琐的。SSL在这个层次中就
提供了一种自动的算法协商，密钥交换和数据加密过程。SSL协议分为两部分：Handshake
Protocol和Record
Protocol，HandShake部分用于处理通讯双方的算法协商和密钥交换过程，Record部分用于对
数据进行加密传输。
整个的SSL基本通讯过程如下:
/====================================================================
||
|[SSLClient][SSLServer]|
||
|(TCP三步握手)|
|(SSL套结字连接)|
|.|
|.SSLSocket()|
|.Bind()|
|SSLSocket()------------------->|
|<-------------------Connect|
|(连接加密算法协商)|
|ClientHello()------------------->|
|(服务器端算法确认和证书发送)|
|ServerHello|
|Certificate*|
|ServerKeyExchange*|
|CertificateRequest*|
|<-------------------ServerHelloDone|
|(客户端证书验证与密钥交换)|
|Certificate*|
|ClientKeyExchange|
|CertificateVerify*|
|[ChangeCipherSpec]|
|Finished------------------->(数据加密算法协商)|
|[ChangeCipherSpec]|
|<-------------------Finished|
|(应用数据加密传输)|
|ApplicationData<------------------>ApplicationData|
|...|
====================================================================/
SSL套结字通讯过程如下:
1,Client和Server双方程序通过sslsocket系列函数替换BSDSocket系列函数；
2,Client通过TCP协议连接到Server端应用程序；
3,Client发起连接质询，发送自身所能实现的"安全集合"，其中包含加密和签名算法协商；
4,Server回应连接，包含本次通讯所使用的算法集合，以及Server端证书；
5,Client收到证书后，使用Server端协商的算法，用Server端证书中包含的Server公钥加密一个
随机序列，作为一个挑战质询发回Server；
6,Server收到加密密文，使用自身的私钥进行数据解密，如果成功，代表SA协商匹配，可以
开始通讯；
7,可选过程，继续发起Client端验证过程，Client端发出Client证书，进行Client端验证过程；
8,可选过程，数据传输过程加密算法协商；
9,协商完毕，开始加密数据传输；
可以看出，SSLSocket通讯过程相比正常的BSDSocket，只不过多了一个安全集合交换协商的过程，
这个过程由SSL实现自身来完成，相对于应用程序，只要采用了SSLSocket，其他的过程都是
透明的。SSL通讯过程中的第3-6步是必须操作，包含了Server端验证过程和加密算法协商，类
似于TCP协议的三步握手过程，这个过程中通过公钥加密算法加密密钥(公钥)和解密秘钥(私钥)
不同的功能，巧妙地实现了密钥交换和算法协商，并且由于解密秘钥不需要在网络上传输，这样
就同时实现了数据通讯过程的保密性和内部应用程序协议的保密性。在第7步进行Client端证书
的验证过程中，由于当前网络环境下PKI和CA体系尚不完善，并且由于SSL设计的工作环境相对
对Client端的安全需求并不很高，所以Client端验证一般作为一种可选手段来实现，取决于应
用程序的安全等级需求。
SSL数据通讯的机密性特性就是由上面的过程完成的，在算法协商过程中除了加密算法的协商外
还会交换一个数据签名算法，用于对数据生成一个唯一的散列校验码，防止在传输过程中数据
被篡改，数据签名过程实现了通讯过程的完整性保证。
对应于SSL所提供的两种安全特性，机密性和保密性，ssl定义了四个安全级别，分别是这两种
特性的状态组合:
C-Clear-没有任何保护
S-Safe-完整性实现，但是没有机密性
E-Confidential-机密性实现，但是没有完整性
P-Private-同时实现机密性和完整性
ftp的ssl扩展使用了其中的两种状态
1)Clear(requestedbyPROTC)
2)Private(requestedbyPROTP)
在连接过程中通过ftp扩展指令PROT来完成状态的切换。
>>3.3sslFTP扩展
在RFC2228中，ftp协议扩展了如下指令:
AUTH(Authentication/SecurityMechanism),
ADAT(Authentication/SecurityData),
PROT(DataChannelProtectionLevel),
PBSZ(ProtectionBufferSize),
CCC(ClearCommandChannel),
MIC(IntegrityProtectedCommand),
CONF(ConfidentialityProtectedCommand),and
ENC(PrivacyProtectedCommand).
其中和SSL扩展相关的主要指令有以下几条:
AUTH(协商扩展验证):指定扩展认证方法,SSL或TLS；
PBSZ(协商保护缓冲区):制定保护缓冲区,SSL/TLS模式中必须为0；
PROT(切换保护级别):切换保护级别，可以为"C"无保护，或"P"保护级别；
在一个典型的ftpssl通讯过程中指令序列如下:
/====================================================================
|ClientServer|
|controldatadatacontrol|
|====================================================================|
||
|socket()|
|bind()|
|socket()|
|connect()----------------------------------
#p# --------->accept()|
|<-------------------------------------------220|
|AUTHTLS------------------------------------------->|
|<-------------------------------------------234|
|TLSneg()<------------------------------------------>TLSneg()|
|PBSZ0------------------------------------------->|
|<-------------------------------------------200|
|PROTP------------------------------------------->|
|<-------------------------------------------200|
|USERelly------------------------------------------->|
|<-------------------------------------------331|
|PASS****------------------------------------------->|
|<-------------------------------------------230|
||
====================================================================/
一个SSLFTP的连接过程实例:
/====================================================================
||
|WinSock2.0--OpenSSL0.9.7d17Mar2004|
|[R]Connectingto192.168.21.3->IP=192.168.21.3PORT=2121|
|[R]Connectedto192.168.21.3|
|[R]220Pleaseenteryourloginnamenow.|
|[R]AUTHTLS(认证方法)|
|[R]234AUTHCommandOK.InitializingSSLconnection.|
|[R]Connected.NegotiatingSSL/TLSsession..|
|[R]SSL/TLSnegotiationsuccessful...(协商关联)|
|[R]TLSv1/SSLv3encryptedsessionusingcipherAES256-SHA(256bits)
|[R]PBSZ0(PBSZ设置)|
|[R]200PBSZCommandOK.Protectionbuffersizesetto0.|
|[R]USERelly(ftp传统认证)|
|[R]331Passwordrequiredforelly.|
|[R]PASS(hidden)|
|[R]230Userellyloggedin.|
|[R]SYST|
|[R]215UNIXType:L8,CP:936|
|[R]FEAT(扩展指令测试)|
|[R]211-Extensionssupported:|
|[R]SIZE|
|[R]MDTM|
|[R]MDTMYYYYMMDDHHMMSSfilename|
|[R]LIST-laT|
|[R]STAT-laT|
|...|
|[R]AUTHSSL|
|[R]AUTHTLS|
|[R]PROT|
|[R]PBSZ|
|[R]SSCN|
|[R]UTF8|
|[R]211END|
|[R]CLNTFlashFXP2.2.985|
|[R]213clienttypesettoFlashFXP2.2.985.|
|[R]PWD(传统通讯过程)|
|[R]257"/"iscurrentdirectory|
|[R]TYPEA|
|[R]200TypesettoASCII.|
|[R]PROTP(切换到保护模式)|
|[R]200PROTPaccepted.|
|[R]PASV|
|[R]227EnteringPassiveMode(192,168,21,3,5,122)|
|[R]OpeningdataconnectionIP:192.168.21.3PORT:1402|
|[R]LIST-al|
|[R]Connected.NegotiatingSSL/TLSsession..(加密通讯过程)|
|[R]150OpeningASCIIdataconnectionforls/usingSSL/TLS.|
|[R]SSL/TLSnegotiationsuccessful...|
|[R]TLSv1/SSLv3encryptedsessionusingcipherAES256-SHA(256bits)
|[R]226-freediskspaceunderthisdirectory:101mb|
|[R]226Transferfinishedsuccessfully.Dataconnectionclosed.|
|[R]ListComplete:181bytesin0.14seconds(1.26KBps)|
||
====================================================================/
在sslftp中，有以下几个特殊点:
1,AUTH是可选指令，因为sslftp实现的方式不同而存在，详见下一节explicitSSL
与implicitSSL；
2,PBSZ和PROT是必须指令，用于切换到保护通道模式；
3,AUTH，PBSZ和PROT指令是实现SSL认证方式的必须方法，但可以与传统的User/Password
模式共存，或只取其一；
4,SSL认证方法的SSL认证过程(AUTH/PBSZ)和传统模式认证并无严格的先后顺序关联，可能在
用户名和密码之前，也可能在之后；但出于安全因素，最好在User/Password传输之前切换
到安全模式，可以确保User/Password的传输安全；
5,在explicitSSL模式中，可以在任何时间切换到保护模式，如第四条所述；在implicit
SSL模式中，初始化连接将直接采用SSLSocket建立，不需要AUTH指令切换。
>>3.4ExplicitSSL和ImplicitSSL
由于历史和软件兼容性因素，sslFTP的实现有两种方式，分别是ExplicitSSL和ImplicitSSL，
上面的大部分数据都是以explicitSSL为范例。
ExplicitSSL(外部SSL)，又被称为AUTHSSL方式；ExplicitSSL保持了与传统ftp服务的
良好兼容性，以一个ftp服务扩展指令的方式存在。初始化连接可以采用与传统ftp兼容的连
接模式，当需要传输加密信息时使用AUTHSSL指令切换到保护模式。使用ExplicitSSL时
Server必须完整地实现AUTH/PBSZ/PROT等指令。
ImplicitSSL(隐含SSL)，是一个全新的ftp实现方式，在TCP三步握手完成之后就直接使用
SSLSocket进行协商和通讯，之后将全程采用SSL加密连接。在这种模式中一般ftpserver
将监听在一个新的服务端口，IANA指定ftps:tcp:990为implicitSSLftp的默认端口。因为在
连接初始阶段就自动由SSL实现完成了协商，因此implicit模式中AUTH指令是可选的。
在不考虑兼容性的因素下，在服务期端最好优先使用implicitSSL模式，可以获得更好的保密
特性。
比较两种sslftp实现模式区别如下:
/======================================================================
|explicitimplicit|
|clientserverclientserver|
|======================================================================|
|||
|connect()------>-+-明文|sslConnect()------>加密|
|<------220||<------220-+|
|AUTHSSL------>||USER***------>||
|<------234-+|<------331||
|TLSneg()<----->TLSneg()-+-加密|PASS***------>||
|<------200||<------230||
|USER***------>||LIST<----->...||
|<------331||RETR<----->...||
|PASS***------>||...||
|<------230||||
|LIST/RETR<----->...||sslClose()<----->...-+|
|close()<----->...-+||
|||
======================================================================/
>>3.5一些杂乱图示
在3.3种引用了一个ExplicitSSL连接指令序列，这里是对应的ImplicitSSL连接过程:
/======================================================================
|WinSock2.0--OpenSSL0.9.7d17Mar2004|
|[R]Connectingto192.168.21.3->IP=192.168.21.3PORT=9909|
|[R]Connectedto192.168.21.3|
|[R]Connected.NegotiatingSSL/TLSsession..|
|[R]SSL/TLSnegotiationsuccessful...|
|[R]TLSv1/SSLv3encryptedsessionusingcipherAES256-SHA(256bits)|
|[R]220Pleaseenteryourloginnamenow.|
|[R]PBSZ0|
|[R]200PBSZCommandOK.Protectionbuffersizesetto0.|
|[R]USERelly|
|[R]331Passwordrequiredforelly.|
|[R]PASS(hidden)|
|[R]230Userellyloggedin.|
|[R]SYST|
|[R]215UNIXType:L8,CP:936|
|[R]PROTP|
|[R]200PROTPaccepted.|
|[R]PASV|
|[R]227EnteringPassiveMode(192,168,21,3,5,122)|
|[R]OpeningdataconnectionIP:192.168.21.
#p# 3PORT:1402|
|[R]LIST-al|
|[R]Connected.NegotiatingSSL/TLSsession..|
|[R]150OpeningASCIIdataconnectionforls/usingSSL/TLS.|
|[R]SSL/TLSnegotiationsuccessful...|
|[R]TLSv1/SSLv3encryptedsessionusingcipherAES256-SHA(256bits)|
|[R]ListComplete:181bytesin0.17seconds(1.04KBps)|
======================================================================/
ExplicitSSL模式下ftpclient<--server的通讯数据，可以看到AUTHSSL之后的指令全部都
已经加密，无法看到。对应2.3节中的传统通讯过程，这确保了传输过程中数据无法被窃听到。
在ImplicitSSL模式中，从初始化连接开始的数据将全部加密，无法分析，因此此处不摘录。
/======================================================================
21:34:22.095241IP192.168.0.1.2279>192.168.0.3.999:S1727744887:1727744887(0)win65535<mss1460,nop,nop,sackOK>(DF)
0x000045000030e6b74000800692bbc0a80001E..0..@.........
0x0010c0a8000308e703e766fb4b7700000000........f.Kw....
0x00207002ffff428a0000020405b401010402p...B...........
21:34:22.095576IP192.168.0.3.999>192.168.0.1.2279:S3598555607:3598555607(0)ack1727744888win65535<mss1460,nop,nop,sackOK>(DF)
0x0000450000308d9e40008006ebd4c0a80003E..0..@.........
0x0010c0a8000103e708e7d67d99d766fb4b78.........}..f.Kx
0x00207012ffffd2230000020405b401010402p....#..........
21:34:22.095639IP192.168.0.1.2279>192.168.0.3.999:.ack1win65535(DF)
0x000045000028e6b84000800692c2c0a80001E..(..@.........
0x0010c0a8000308e703e766fb4b78d67d99d8........f.Kx.}..
0x00205010fffffee70000P.......
21:34:22.108439IP192.168.0.3.999>192.168.0.1.2279:P1:115(114)ack1win65535(DF)
0x00004500009a8da440008006eb64c0a80003E.....@....d....
0x0010c0a8000103e708e7d67d99d866fb4b78.........}..f.Kx
0x00205018ffff5cb500003232302d54686973P......220-This
0x00302073657276657220697320666f722070.server.is.for.p
0x004072697661746520757365206f6e6c790drivate.use.only.
0x00500a32.2
21:34:22.257722IP192.168.0.1.2279>192.168.0.3.999:.ack115win65421(DF)
0x000045000028e6c14000800692b9c0a80001E..(..@.........
0x0010c0a8000308e703e766fb4b78d67d9a4a........f.Kx.}.J
0x00205010ff8dfee70000P.......
21:34:22.257941IP192.168.0.3.999>192.168.0.1.2279:P115:154(39)ack1win65535(DF)
0x00004500004f8da740008006ebacc0a80003E..O..@.........
0x0010c0a8000103e708e7d67d9a4a66fb4b78.........}.Jf.Kx
0x00205018ffff96b3000032323020506c6561P.......220.Plea
0x0030736520656e74657220796f7572206c6fse.enter.your.lo
0x004067696e206e616d65206e6f772e0d0agin.name.now...
21:34:22.264587IP192.168.0.1.2279>192.168.0.3.999:P1:11(10)ack154win65382(DF)
0x000045000032e6c24000800692aec0a80001E..2..@.........
0x0010c0a8000308e703e766fb4b78d67d9a71........f.Kx.}.q
0x00205018ff66e88e0000415554482053534cP..f....AUTH.SSL
0x00300d0a..
21:34:22.371140IP192.168.0.3.999>192.168.0.1.2279:P154:205(51)ack11win65525(DF)
0x00004500005b8dac40008006eb9bc0a80003E..[..@.........
0x0010c0a8000103e708e7d67d9a7166fb4b82.........}.qf.K.
0x00205018fff59a0300003233342041555448P.......234.AUTH
0x003020436f6d6d616e64204f4b2e20496e69.Command.OK..Ini
0x00407469616c697a696e672053534c20636ftializing.SSL.co
0x00506e6enn
21:34:22.374945IP192.168.0.1.2279>192.168.0.3.999:P11:141(130)ack205win65331(DF)
0x0000450000aae6c6400080069232c0a80001E.....@....2....
0x0010c0a8000308e703e766fb4b82d67d9aa4........f.K..}..
0x00205018ff33f99a00008080010301005700P..3..........W.
0x003000002000001600001300000a0700c000................
0x004000660000070000050000040500800300.f..............
0x00508001..
21:34:22.375857IP192.168.0.3.999>192.168.0.1.2279:P205:1071(866)ack141win65395(DF)
0x00004500038a8dad40008006e86bc0a80003E.....@....k....
0x0010c0a8000103e708e7d67d9aa466fb4c04.........}..f.L.
0x00205018ff73e3560000160301004a020000P..s.V......J...
0x00304603014082837da18821775e7765a9eeF..@..}..!w^we..
0x004018cae0ab1b17461ebf71515f68375c1a......F..qQ_h7.
======================================================================/
>>4.0<<总结
FTP的替代应用
如今，如果考虑到其他一些安全的文件传输选择，可能看起来没有理由再使用FTP了，如SCP或
者SFTP，与FTP应用相似但运用SSH（注：Secure
Shell）来进行验证和加密，如果你使用一台基于UNIX的服务器，你可以在命令方式下调用SCP
或者SFTP，如果你想获得更多的关于SSH的信息，参考如下URL
http://www.openssh.com
如果你只是用FTP来更新你的Web页面，有别的替代应用，称为WebDAV的新的协议，WebDAV
是HTTP的扩展，它允许多个用户共同编辑和维护远程WEB服务器上的文件，如果想了解WebDAV
的详细信息，参考
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2518.html
FTP是在70年代设计出来的，那个时候互联网还是一个封闭的网络，网络安全不是一个大的问
题。当FTP在使用NAT网关、防火墙、CISCO访问列表的现代网络环境中运用的时候，不管你使
用Port模式还是Passive模式，都可能产生一些问题，FTP在公网上作为一些关键应用的文件传
输手段可能就是一个错误；当然近年很多人为了是FTP协议更加安全进行了不懈的努力，这些
努力却使对于FTP的排错更加复杂，而且都没有解决FTP最大的问题，即明文传输用户名和口令
。有许多应用可以替代FTP，如SCP，SFTP或者WebDAV。
以上为原文总结，本文下半部分补充了ftp自身的安全扩展，使用SSL/TLS进行ftp传输过程的
验证和加密，良好的实现了与传统ftp协议的兼容性和优良的数据保密性与完整性。在无法使用
替代服务的环境下，是一种非常好的ftp服务改进计划。
略有不足的是，由于历史兼容性因素，很多ftpclient和server对sslftp扩展的实现都存在
着各种缺陷，例如加密算法不足，指令顺序有错误等等，这可能会引起一些安全保护级别的削弱。
1,由于没有良好的PKI体系支撑，很多ftpserver的证书合法性无法得到验证，可能存在无法
信任或被伪造的可能；
2,由于ExplicitSSL模式的历史兼容问题，AUTH指令和USER/PASS指令序列的优先级没有明确
约定，可能存在指令序列错误造成信息泄露的问题；
3,由于SSL自身体系的一些问题，可能受到证书泄露，伪造，或SSL中间人攻击;
4,在不完整的CA或PKI体系下，只能够采用自签名证书，这时SSLftp得到的安全性提高仅仅
是通讯过程加密，并无法完成身份认证的功能。
当然，排除无法实现身份认证功能和略微的实现缺陷，sslftp仍然是一种优秀的ftp服务安全加强
措施。
>>5.0<<参考
ftp协议簇
http://www.ietf.org/rfc/rfc959.txt
http://www.ietf.org/rfc/rfc1579.txt
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
ssl/tls协议规范:
#p# http://www.ietf.org/rfc/rfc2246.txt
OpenSSL,一个广为应用的SSL实现:
http://www.openssl.org
支持sslftp的ftpclient:
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext_col.html#client
支持sslftp的ftpserver:
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext_col.html#server