FTPS协议

这篇文章解释了FTPS协议以及如何使用FTPS服务器软件（如CompleteFTP）来安全地传输文件。

FTPS（FTP安全）是通过SSL连接的FTP。

"普通 "FTP的一个重要问题是它不安全 -- -- 用户名、密码和数据都是在网络上公开发送的。这意味着窃听者在嗅探网络时，几乎不难获得凭证和传输文件的副本。

FTPS协议就是为了解决这个问题而设计的，它使用SSL/TLS协议对通信进行加密，SSL/TLS协议是专门为保护网络连接安全而设计的。

FTPS是RFC 4217中描述的IETF标准。

1. 隐性FTPS和显性FTPS

FTPS协议的早期版本现在被称为隐性FTPS协议。在连接时，隐性FTPS协议的客户端会自动开始使用SSL/TLS保护连接。

这对于未加密的FTP客户端来说是一个问题--它们将无法再连接到需要立即确保连接安全的服务器端口上。如果要在同一服务器上支持FTP和FTPS（隐性），它们需要不同的端口号。通常，隐性FTPS协议使用990端口，而不是标准的FTP端口21。

显性FTPS通过要求客户端在确保连接之前发送AUTH命令来解决这个问题。这意味着未加密的FTP客户端可以与FTPS协议客户端在相同的端口上进行连接--未加密的客户端只是从未发送AUTH命令，会话仍未加密。FTPS协议客户端在登录前会发送AUTH命令，这样可以保证凭证的安全。

隐性FTPS客户端仍然可以找到，但显式模式总是更受欢迎。除非需要隐式模式，最好在CompleteFTP中禁用隐式模式的FTPS协议。

2. 确保控制和数据通道的安全

FTP会话使用两个通道：控制和数据。每个会话中只使用一个控制通道，但可以使用多个数据通道 - 每个数据传输一个。AUTH 命令只保证控制通道的安全。在发出PBSZ和PROT命令之前，数据通道不会被保护。 这些命令告诉服务器是否应该确保后续数据通道的安全。

客户端可以在未加密模式下连接到FTPS服务器，然后根据要求切换到安全模式。要做到这一点，客户机发出AUTH命令，客户机与服务器协商建立安全连接。 切换后，所有的FTP命令都会被加密，但重要的是，除非提供进一步的命令，否则数据不会被加密。

3. FTPS协议命令

使用了三个命令，AUTH、PBSZ和PROT。其中的PBSZ似乎是多余的，可能只是为了满足RFC规范而包含。

3.1 AUTH (AUTHentication)

AUTH命令只需要一个参数，它定义了要使用的安全机制，通常是 "SSL "或 "TLS"。

AUTH TLS

通过该命令，尝试在控制通道上协商一个TLS连接。服务器尝试通过发送证书向客户端验证自己（服务器验证）。它也可能涉及到客户端向服务器发送证书（客户端验证）。

3.2 PBSZ保护缓冲器SiZe)

PBSZ命令是用来定义安全机制在数据通道上加密数据时使用的缓冲区大小。但是对于TLS来说，这个设置是多余的，总是把'0'作为参数传递。

PBSZ 0

虽然这个调用是多余的，但它是必须的，而且必须在PROT命令之前进行。

3.3 PROT (数据通道PROTection级别)

PROT定义了数据通道是否要被保护。数据通道要么是Clear（默认），要么是Private。Clear意味着数据通道不使用任何安全保护（意味着文件传输时不需要加密），Private意味着数据通道应该被加密。所以有两种可能的PROT命令。

PROT C

对于不安全的数据通道，

PROT P

对于加密的数据通道。

4. FTPS协议使用

一个典型的显性FTPS会话可能包括以下命令序列。

> USER (user-name)
Provide user-name
> PASS (password)
Provide password
> LIST
Get a directory listing
> AUTH TLS
Switch to TLS on control-channel
> RETR (file-name)
Download a file (without security)
> PBSZ 0
> PROT P
Switch to TLS on the data-channel
> STOR (file-name)
Upload a file (with security)
> QUIT
End session

在这个例子中，前三个命令（USER、PASS和LIST）是标准的FTP，因此是不安全的。 AUTH命令使其余的命令安全地发送到服务器，换句话说，攻击者无法看到哪些命令被发出。 RETR命令（从服务器上取文件），在AUTH之后，是受保护的，但实际传输的文件不受保护，因为它在PBSZ和PROT命令之前。 PBSZ和PROT告诉服务器在未来的所有数据通道上使用TLS，因此STOR命令（在服务器上存储文件）中传输的文件是安全的。

4.1 规则

关于发出显性FTPS协议命令，有两条规则必须遵守。

1. AUTH must precede PBSZ		
2. PBSZ must precede PROT

除此以外，FTPS服务器还有关于其资源访问权限的政策。这些政策也将决定命令必须以何种顺序发出。可能的政策太多，在此无法一一列举，但下面给出了一些此类政策的例子，以及它们在发布命令方面的后果。

政策
后果
· 没有未受保护的命令
AUTH必须在任何其他命令之前发出。
· 某些用户不允许在没有安全性的情况下登录。
除非之前有成功的AUTH命令,否则会拒绝特定用户的USER命令。
· 不得传输不受保护的数据
在传输任何文件之前,必须发出"PROT P"命令（前面有PBSZ命令）。
· 允许TLS验证而不是USER/PASS验证
必须提供客户端证书,并且不需要USER/PASS命令。

5. SSL证书 (a.k.a. TLS证书)

虽然FTPS协议的用户可能安全地对大多数基本安全机制一无所知，但他们必须了解公钥和证书的基本知识。在某些情况下,还需要了解哪些加密/解密算法（或密码）可用,以及它们提供的保护级别。

5.1 公钥加密技术

公钥密码学（PKC）是一种在给定通信中使用一对密钥的范式；一个密钥用于加密消息,另一个密钥用于解密消息。每一个密钥都可以起到这两种作用,但使用一个密钥加密的消息只能由另一个密钥解密。

下面的例子说明了如何使用这样一对钥匙进行安全通信。

甲方生成了一对密钥。它们保留一个密钥,即私钥,并以可信的方式将另一个密钥,即公钥分发给乙方（见第4.1.2节）。

1. A用私钥加密一条信息，然后发送给B。  如果B能够使用公钥对消息进行解密，那么B可以确信消息确实来自A，因为只有A拥有私钥。

2. B用公钥加密一条信息并发送给A。  由于消息只能使用私钥解密,并且只有A拥有此密钥,因此B可能确信只有A能够读取消息。

因此,使用A的私钥/公钥对,B可以确保（1） A是他们声称的人,以及（2）发送到A的任何消息只能由该方读取。然而，以下缺点仍然存在：（1） A不能确信B是B声称的人；（2）任何拥有公钥的人都可以阅读A到B之间的通信。

虽然如果B有自己的一对钥匙并提供了A的公钥，这两个缺点都很容易克服，但由于所涉及的工作量很大，这往往是不现实的。但是，后一个缺点可以通过以下方式轻松克服：

3. B会自动生成临时密钥对。由于B可能确信其发送给A的消息只能由A读取,因此B可以安全地提供给A密钥之一。一旦A收到此密钥,他们就可以使用它对发送给B的任何消息进行加密。因此,他们可能确信只有B才能读取任何后续消息。

因此,一个私有-公共密钥对可能提供以下安全性：

I.接收来自密钥对所有者的消息的各方可以验证编码的消息是否来自所有者。

II.安全消息可以在所有者和其他各方之间发送。

如前所述，这假定密钥对的所有者能够以可信的方式分发其公共密钥。实际上，这是通过公钥证书和证书颁发机构来实现的。

5.2 证书和证书颁发机构 (CAs)

上一节强调了公钥需要以可信的方式进行分发。   仅仅以电子方式发送钥匙不应该被认为是安全的，因为信息可能会在途中被篡改，尽管在很多情况下都会这样做。让一个人把装有钥匙的记忆棒交给另一个人可能是可以接受的，但通常是不切实际的。  互联网上使用的解决方案是使用一个被称为证书颁发机构（CA）的可信第三方。

CA是专门颁发公钥证书的组织。他们只有在提供了充分的身份证明文件后才向当事方（或当事人）签发证书。世界上只有少数CA,由于它们的生存能力取决于它们的可信度,因此通常可以依靠它们来做好验证其主体的工作。

每个CA都有自己的专用公钥对和自己的证书（称为根证书）。由于CA太少,而且它们很少更改密钥,因此,软件可以随所有现有CA的证书列表一起分发。例如,Microsoft和Netscape的浏览器都包含包含根证书列表的文件。

CA向某主体颁发的证书包含以下内容：

  • 对主体的识别，
  • 这个主体的公钥，
  • 对签发证书的CA的识别，以及
  • CA提供的数字签名,用于验证消息的内容。

主体的证书可通过以下方式进行验证:

  1. 使用CA的标识查找适当的根证书。
  2. 使用该根证书检查数字签名,从而证明CA颁发的证书以及证书中的信息未被篡改。
  3. 验证主体的识别。

一旦这样做，当事人可以相信证书中的公钥确实是他们期望的公钥。从此，可以使用这种公钥以第12节所述的方式与该主体建立安全的通信。

一旦这样做，当事人可以相信证书中的公钥确实是他们期望的公钥。从此，可以使用这种公钥以第12节所述的方式与该主体建立安全的通信。

5.3 获取钥匙和证书

私钥-公钥对很容易产生。 同样，"未经认证 "的证书可能不费吹灰之力就能生成，但要从核证机构获得值得信赖的证书，就必须付出一些努力、时间和（通常）成本。 它涉及到与CA互动以证明身份，并等待CA对证书进行数字签名。

也可以使用OpenSSL。读者可以参考OpenSSL中关于生成密钥对和证书的说明。建议使用长度至少为768位的密钥。

5.4 服务器和客户端验证

前面几节介绍了如何使用公用钥匙证书来验证参与安全通信的各方。 它们还解释了为什么获取证书会涉及一些努力、时间和费用。

互联网使用的本质是，区分服务器验证和客户端验证是很重要的。服务器验证可以让客户端知道它是在和目标服务器对话，比如CompleteFTP。相反，客户端验证允许服务器知道它正在与目标客户端通话。

对客户来说，知道自己正在与目标服务器通话往往比反之更重要。原因通常是财务方面的。例如，如果客户从在线零售商处购买商品，客户需要确定他们的信用卡信息将被送到预定的目的地。 虽然对零售商来说，确定钱的来源可能是件好事，但这通常不是必要的。 因此，在这类交易中，几乎总是使用服务器验证，但客户端验证较少使用。 其他应用程序，如网上银行，通常同时使用客户端和服务器验证。

在FTPS协议中，服务器和客户端的证书验证都是可选的。 虽然服务器的证书总是被发送的，但是客户端是否验证证书是由它自己决定的。客户端是否会尝试向服务器验证自己的证书是由客户端决定的，但有些服务器的政策是不允许未经验证的客户端访问其部分或全部资源。

需要注意的是，虽然许多FTPS服务器不要求客户证书，但大多数服务器要求发送用户名和密码。如果这些都是通过安全的控制渠道发送的，那么合理的客户端验证水平是固有的。

5.5 主机名检查

服务器验证的步骤之一是主机名检查。 主机名检查是在建立安全连接时进行的简单检查。它包括比较以下两个项目。

  • FTPS服务器提交的证书中所包含的主机名。
  • 运行FTPS服务器的机器的主机名。

如果它们相匹配，那么人们可以确信，客户所连接的服务器实际上就是签发证书的那台服务器；如果它们不相匹配，那么就有可能是证书被盗，客户所连接的服务器试图 "冒充 "客户实际连接的服务器。这是一种 "中间人 "攻击的形式，它使攻击者完全控制了发送和接收的数据。

遗憾的是，最广泛兼容的X.509证书标准版本并没有明确规定如何在服务器证书中定义主机名。惯例是应使用证书的通用名（CN）字段，虽然大多数证书颁发机构都遵循这一惯例，但它并不通用。

如果可以配置FTPS服务器的证书，那么证书的通用名（CN）字段必须与FTPS服务器运行的机器的主机名相同。

强烈反对禁用主机名检查，只有在FTPS服务器的证书不能配置成包含主机名的CN参数时，才应作为最后的手段。

6. 密码

SSL和TLS可以使用各种加密/解密算法（称为密码）。 在一个安全连接中，多达四种不同的密码可以用于不同的目的；这组密码被称为密码套件。安全连接中的每一方都必须指定它要支持哪些密码套件。当建立一个新的安全连接时，参与的各方会尝试就使用哪个密码套件达成一致。在连接的两边必须至少有一个密码套件是可用的，这样才有可能。

不同的密码套件有不同的安全级别和性能。安全等级越低，密码越容易被破解。 不幸的是，更强的密码通常提供较慢的性能。 因此，两者之间存在一定程度的权衡。出于这个原因，关于支持哪种密码套件的决定留给SSL和TLS应用的开发者和/或用户。

每一个密码套件都有一个标准的名称(例如：TLS_RSA_WITH_RC4_128_SHA)。 这个名称揭示了该套件中使用的密码。

选择密码套件时可能有用的一些准则：

  • 三重DES提供了很高的安全性，但性能相对较差（看名字中带字符，3DES）。
  • DES(不是3DES)可以比较容易地被破解。
  • 128位RC4提供了高性能和合理的安全性（寻找带有RC4_128字符的名称）。
  • SHA优于MD5（选择名称以SHA结尾的算法，而不是以MD5结尾的算法）。
  • 导出版算法被刻意弱化，尽量避免（即避免40位套件）。