在传统的ftp通讯和传输过程中可以看出，ftp协议提供了一种简单实用的网络文件传输方法，但是缺陷也是显而易见的。传统ftp服务缺乏对数据的机密性和完整性保护，对通讯双方也没有可靠的认证措施，同时还存在着明文信息传输的弱点——在同一个网络上的任何用户都可能窃取到重要的信息。虽然近年来出现了很多种ftp的替代服务，例如ssh加密通道的sftp/scp，或使用IPSEC协议的VPN通道等等，但是在大多数情况下，ftp的通用性和易用性使得它在很长一段时间内必然无法被完全取代。所以如同其他一系列古董服务(例如SMTP/HTTP)一样，近年来也出现了一些不需要对ftp协议自身做完全更改的协议扩展模块，能够良好的完成兼容性和功能扩展。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
1、SSL/TLS简介
先说一下SSL/TLS协议，SSL(Secure Socket Layer)最早是netscape公司设计的用于HTTP协议加密的安全传输协议，SSL工作于TCP协议的传 输层(TCP层)和应用程序之间。作为一个中间层，应用程序只要采用SSL提供的一套SSL套接字API来替换标准的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
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, 协商完毕，开始加密数据传输；
相关内容
