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协议，SSL(Secure Socket
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协议，RFC 2246: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基本通讯过程如下:
/====================================================================\
| |
| [ SSL Client ] [ SSL Server ] |
| |
| (TCP三步握手) |
| (SSL套结字连接) |
| . |
| . SSLSocket() |
| . Bind() |
| SSLSocket() -------------------> |
| <------------------- Connect |
| (连接加密算法协商) |
| ClientHello() -------------------> |
| (服务器端算法确认和证书发送)|
| ServerHello |
| Certificate* |
| ServerKeyExchange* |
| CertificateRequest* |
| <------------------- ServerHelloDone |
| (客户端证书验证与密钥交换) |
| Certificate* |
| ClientKeyExchange |
| CertificateVerify* |
| [ChangeCipherSpec] |
| Finished -------------------> (数据加密算法协商) |
| [ChangeCipherSpec] |
| <------------------- Finished |
| (应用数据加密传输) |
| Application Data <------------------> Application Data |
| ... |
\====================================================================/

SSL套结字通讯过程如下:
1, Client和Server双方程序通过ssl socket系列函数替换BSD Socket系列函数；
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, 协商完毕，开始加密数据传输；

可以看出，SSL Socket通讯过程相比正常的BSD Socket，只不过多了一个安全集合交换协商的过程，
这个过程由SSL实现自身来完成，相对于应用程序，只要采用了SSL Socket，其他的过程都是
透明的。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 (requested by 'PROT C')
2)Private (requested by 'PROT P')
在连接过程中通过ftp扩展指令PROT来完成状态的切换。

>>3.3 ssl FTP扩展
在RFC 2228中，ftp协议扩展了如下指令:
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 (协商扩展验证): 指定扩展认证方法,SSL或TLS；
PBSZ (协商保护缓冲区): 制定保护缓冲区,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... (协商关联)|
| [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传统认证)|
| [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 (传统通讯过程)|
| [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实现的方式不同而存在，详见下一节explicit SSL
与implicit SSL；
2, PBSZ和PROT是必须指令，用于切换到保护通道模式；
3, AUTH，PBSZ和PROT指令是实现SSL认证方式的必须方法，但可以与传统的User/Password
模式共存，或只取其一；
4, SSL认证方法的SSL认证过程(AUTH/PBSZ)和传统模式认证并无严格的先后顺序关联，可能在
用户名和密码之前，也可能在之后；但出于安全因素，最好在User/Password传输之前切换
到安全模式，可以确保User/Password的传输安全；
5, 在explicit SSL模式中，可以在任何时间切换到保护模式，如第四条所述；在implicit
SSL模式中，初始化连接将直接采用SSL Socket建立，不需要AUTH指令切换。

>>3.4 Explicit SSL和Implicit SSL
由于历史和软件兼容性因素，ssl FTP的实现有两种方式，分别是Explicit SSL和Implicit
SSL，上面的大部分数据都是以explicit SSL为范例。

Explicit SSL(外部SSL)，又被称为AUTH SSL方式；Explicit SSL保持了与传统ftp服务的
良好兼容性，以一个ftp服务扩展指令的方式存在。初始化连接可以采用与传统ftp兼容的连接模
式，当需要传输加密信息时使用AUTH SSL指令切换到保护模式。使用Explicit SSL时Server
必须完整地实现AUTH/PBSZ/PROT等指令。

Implicit SSL(隐含SSL)，是一个全新的ftp实现方式，在TCP三步握手完成之后就直接使用SSL
Socket进行协商和通讯，之后将全程采用SSL加密连接。在这种模式中一般ftp server将监听在
一个新的服务端口，IANA指定ftps:tcp:990为implicit SSL ftp的默认端口。因为在连接初始
阶段就自动由SSL实现完成了协商，因此implicit模式中AUTH指令是可选的。

在不考虑兼容性的因素下，在服务期端最好优先使用implicit SSL模式，可以获得更好的保密特性。

上一页  [1] [2] [3] [4] 下一页