TCP/IP协议基础之四（TCP/IP的安全性） (2)

　　SKIP不提供BTP和PFS这件事曾经引起IPSEC工作组内部的批评，该协议也曾进行过 扩充，试图提供BTP和PFS。但是，扩充后的SKIP协议版本其实是在BTP和PFS功能 的提供该协议的无状态性之间的某种折衷。实际上，增加了BTP和PFS功能的SKIP 非常类似于Photuris以及类Photuris的协议，唯一的主要区别是SKIP(仍然)需要 原来的Diffie-Hellman证书。这一点必须注意:目前在Internet上，RSA证书比其 他证书更容易实现和开展业务。

　　大多数IPSP及其相应的密钥管理协议的实现均基于Unix系统。任何IPSP的实现都 必须跟对应协议栈的源码纠缠在一起，而这源码又能在Unix系统上使用，其原因 大概就在于此。但是，如果要想在Internet上更广泛地使用和采纳安全协议，就 必须有相应的DOS或Windows版本。而在这些系统上实现Internet层安全协议所直 接面临的一个问题就是，PC上相应的实现TCP/IP的公共源码资源什么也没有。为 克服这一困难，Wagner和Bellovin实现了一个IPSEC模块，它象一个设备驱动程序 一样工作，完全处于IP层以下。

　　Internet层安全性的主要优点是它的透明性，也就是说，安全服务的提供不需要 应用程序、其他通信层次和网络部件做任何改动。它的最主要的缺点是: Intern et层一般对属于不同进程和相应条例的包不作区别。对所有去往同一地址的包， 它将按照同样的加密密钥和访问控制策略来处理。这可能导致提供不了所需的功 能，也会导致性能下降。针对面向主机的密钥分配的这些问题，RFC 1825允许(甚 至可以说是推荐) 使用面向用户的密钥分配，其中，不同的连接会得到不同的加 密密钥。但是，面向用户的密钥分配需要对相应的操作系统内核作比较大的改动。

　　虽然IPSP的规范已经基本制订完毕，但密钥管理的情况千变万化，要做的工作还 很多。尚未引起足够重视的一个重要的问题是在多播 (multicast)环境下的密钥 分配问题，例如，在Internet多播骨干网(MBone)或IPv6网中的密钥分配问题。

　　简而言之，Internet层是非常适合提供基于主机对主机的安全服务的。相应的安 全协议可以用来在Internet上建立安全的IP通道和虚拟私有网。例如，利用它对 IP包的加密和解密功能，可以简捷地强化防火墙系统的防卫能力。事实上，许多厂商已经这样做了。RSA数据安全公司已经发起了一个倡议，来推进多家防火墙和 TCP/IP软件厂商联合开发虚拟私有网。该倡议被称为S-WAN(安全广域网)倡议。其 目标是制订和推荐Internet层的安全协议标准。

　　二、传输层的安全性

　　在Internet应用编程序中，通常使用广义的进程间通信(IPC)机制来与不同层次的 安全协议打交道。比较流行的两个IPC编程界面是BSD Sockets和传输层界面(TLI)， 在Unix系统V命令里可以找到。

　　在Internet中提供安全服务的首先一个想法便是强化它的IPC界面，如BSD Socke ts等，具体做法包括双端实体的认证，数据加密密钥的交换等。Netscape通信公 司遵循了这个思路，制定了建立在可靠的传输服务(如TCP/IP所提供)基础上的安 全套接层协议(SSL)。SSL版本3(SSL v3)于1995年12月制定。它主要包含以下两个 协议：

　　SSL记录协议 它涉及应用程序提供的信息的分段、压缩、数据认证和加密。SSL v3提供对数据认证用的MD5和SHA以及数据加密用的R4和DES等的支持，用来对数据 进行认证和加密的密钥可以通过SSL的握手协议来协商。

　　SSL握手协议 用来交换版本号、加密算法、(相互)身份认证并交换密钥。SSL v3 提供对Deffie-Hellman密钥交换算法、基于RSA的密钥交换机制和另一种实现在 Fortezza chip上的密钥交换机制的支持。

　　Netscape通信公司已经向公众推出了SSL的参考实现(称为SSLref)。另一免费的S SL实现叫做SSLeay。SSLref和SSLeay均可给任何TCP/IP应用提供SSL功能。Inter net号码分配当局(IANA)已经为具备SSL功能的应用分配了固定端口号，例如，带 SSL的 HTTP(https)被分配的端口号为443，带SSL的SMTP(ssmtp)被分配的端口号 为465，带SSL的NNTP(snntp)被分配的端口号为563。

　　微软推出了SSL2的改进版本称为PCT(私人通信技术)。至少从它使用的记录格式来 看，SSL和PCT是十分相似的。它们的主要差别是它们在版本号字段的最显著位(T he Most Significant Bit)上的取值有所不同: SSL该位取0，PCT该位取1。这样 区分之后，就可以对这两个协议都给以支持。

　　1996年4月，IETF授权一个传输层安全(TLS)工作组着手制定一个传输层安全协议 (TLSP)，以便作为标准提案向IESG正式提交。TLSP将会在许多地方酷似SSL。 前面已介绍Internet层安全机制的主要优点是它的透明性，即安全服务的提供不 要求应用层做任何改变。这对传输层来说是做不到的。原则上，任何TCP/IP应用， 只要应用传输层安全协议，比如说SSL或PCT，就必定要进行若干修改以增加相应 的功能，并使用(稍微)不同的IPC界面。于是，传输层安全机制的主要缺点就是要 对传输层IPC界面和应用程序两端都进行修改。可是，比起Internet层和应用层的 安全机制来，这里的修改还是相当小的。另一个缺点是，基于UDP的通信很难在传 输层建立起安全机制来。同网络层安全机制相比，传输层安全机制的主要优点是 它提供基于进程对进程的(而不是主机对主机的)安全服务。这一成就如果再加上 应用级的安全服务，就可以再向前跨越一大步了。

　　三、应用层的安全性

　　必须牢记(且须仔细品味): 网络层(传输层)的安全协议允许为主机(进程)之间的 数据通道增加安全属性。本质上，这意味着真正的(或许再加上机密的)数据通道 还是建立在主机(或进程)之间，但却不可能区分在同一通道上传输的一个具体文 件的安全性要求。比如说，如果一个主机与另一个主机之间建立起一条安全的IP 通道，那么所有在这条通道上传输的IP包就都要自动地被加密。同样，如果一个 进程和另一个进程之间通过传输层安全协议建立起了一条安全的数据通道，那么 两个进程间传输的所有消息就都要自动地被加密。

　　如果确实想要区分一个具体文件的不同的安全性要求，那就必须借助于应用层的 安全性。提供应用层的安全服务实际上是最灵活的处理单个文件安全性的手段。 例如一个电子邮件系统可能需要对要发出的信件的个别段落实施数据签名。较低 层的协议提供的安全功能一般不会知道任何要发出的信件的段落结构，从而不可 能知道该对哪一部分进行签名。只有应用层是唯一能够提供这种安全服务的层次。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有