密钥密码系统介绍

　　这篇文章向大家阐述了Netscape公司是如何使用RSA的公用密钥密码系统来实现因特网安全的。Netscape的安全套接层的实现就利用了这篇文章中所讨论的技术。
　　RSA的公用密钥密码系统广泛地应用于计算机工业的认证和加密方面。Netscape得到RSA数据安全公司的许可可以使用公用密钥密码系统以及其它产品，尤其是认证方面的产品。
　　公用密钥加密技术使用不对称的密钥来加密和解密，每对密钥包含一个公钥和一个私钥，公钥是公开，而且广泛分布的，而私钥从来不公开，只有自己知道。
　　用公钥加密的数据只有私钥才能解密，相反的，用私钥加密的数据只有公钥才能解密，正是这种不对称性才使得公用密钥密码系统那么有用。

使用公用密钥密码系统进行认证

　　认证是一个验证身份的过程，目的是使一个实体能够确信对方是他所声称的实体。下面的例子包括Alice和Bob，并且向我们演示了如何使用公用密钥密码系统来轻易的验证身份。下面的 {something}key 表示something 已经用密钥 key 加密或解密。
　　假设Alice要认证Bob，Bob有一个密钥对，即一个公钥和一个私钥，Bob透露给Alice他的公钥（至于他是怎么做的将在以后讨论）。然后Alice产生一段随机的消息，然后把它发给Bob。
　　 A-->B random--message

　　Bob用自己的私钥来加密这段消息，然后把加密后的消息返回给Alice。
　　 B-->A {random--message}bobs--private--key

　　Alice接到了这段消息，然后用Bob以前发过来的公钥来解密。她把解密后的消息和原始的消息做比较，如果匹配的话，她就知道自己正在和Bob通信。一个入侵者应该不知道Bob的私钥，因此就不能正确的加密那段Alice要检查的随机消息。
　　但是，等一下，还有......
　　除非你确切的知道你在加密什么，否则用你的私钥加密一些东西，然后发给别人永远不是一件好事。这是因为加密后的数据可能会背叛你（记住，只有你能加密，因为只有你才有密钥）。
　　所以，我们不加密Alice发送的原始消息，取而代之的是，由Bob构造一个消息信息段，然后加密它。消息信息段是从随机消息中以某种方式提取出来的，并且具有以下特点：
　　 信息段很难逆转，任何假冒Bob的人不能从信息段得到原始消息
      假冒者无法找到具有相同信息段的不同消息
　　 通过使用信息段，Bob能够保护自己。他首先计算出Alice发给他的随机消息的信息段并加密，然后把加密后的信息段返回给Alice，Alice可以计算出相同的信息段，通过解密Bob的消息然后对比一下就可以认证Bob的身份。

      近一点......
　　刚才描述的技术称为数字签名。Bob为Alice产生的消息签名，这样做其实和加密Alice产生的随机消息一样危险。因此我们的认证协议需要一次以上的变形。部分（或者全部）的数据需要由Bob产生。
　　 A-->B hello,are you bob?
　　B-->A Alice,This Is bob{digest[Alice,This Is Bob]}bobs-private-key

　　当Bob使用这个协议的时候，他知道自己发给Alice的是什么消息，并且不介意签名。他首先发送没有加密的消息“Alice,This Is Bob。”然后发送加密的信息段。Alice能够轻易的判断Bob是Bob，并且Bob没有签任何他不愿意签的东西。

分发公钥

　　Bob如何以一种可信赖的方式分发他的公钥呢？我们假设认证协议是这个样子的：
　　 A-->B hello
　　B-->A Hi, I'm Bob, bobs-public-key
　　A-->B prove it
　　B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key

　　如果使用这个协议的话，任何人都可以是Bob。你需要的只是一个公钥和私钥，你跟Alice慌称你是Bob，接着你用自己的公钥代替Bob的公钥，然后你通过用你的私钥加密的东西来证明，这样Alice就不能分辨出你不是Bob。
　　为了解决这个问题，标准化组织发明了一个叫做证书的东西，一个证书包括下面的一些内容：
　　 证书发行者的名字
　　 证书发送给的团体
　　 主题的公钥
　　时间戳

　　证书是由证书发行者的私钥签名的，每个人都知道证书发行者的公钥（即证书发行者有一个证书，等等）。证书是一种把公钥绑定到名字的标准方式。
　　通过使用证书这种技术，每个人都可以通过检查Bob的证书来判断Bob是不是伪造的。假设Bob严格的控制着他的私钥，并且的确是Bob得到了他的证书，那么一切都好。下面是修订后的协议：
　　 A-->B hello
　　B-->A Hi, I'm Bob, bobs-certificate
　　A-->B prove it
　　B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key

　　当Alice收到Bob的第一条消息，她可以检查证书，核实签名（如上，使用信息段和公钥加密），然后，核实主题（Bob的名字）来判断那是不是真的Bob。这样她就相信公钥是Bob的公钥，然后要求Bob证明他的身份。Bob则重新进行一次上面的相同过程，计算消息的信息段，签名之后发给Alice，Alice可以用从证书得到的公钥检查Bob的消息信息段，从而判断Bob的身份。

一个坏家伙 - 我们不妨叫他Mallet - 可以做下面的事情：
　　 A-->M hello
　　M-->A Hi, I'm Bob, bobs-certificate
　　A-->M prove it
　　M-->A 不能建立一个令甲相信的从乙的消息。

　　但是Mallet在最后的消息中不能满足Alice。Mallet没有Bob的私钥，所以他无法构造一条使Alice相信来自Bob的消息。

交换密码

　　一旦Alice认证了Bob，她就可以做另外一件事-她能发给一条只有Bob才能解码的消息：
　　 A-->B {secret}bobs-public-key

　　发现这个秘密的唯一方法就是用Bob的私钥来解密上面的消息，交换秘密是公用密钥密码系统的另一种强大的用法。即使Alice和Bob之间的通信被监视，除了Bob，也没有人能够得到秘密。
　　这项技术加强了因特网的安全性，它把这个密码当作另一个密钥，但是这时它是对称性密码系统算法的密钥（如DES，RC4，IDEA）。Alice知道这个秘密，因为这是自己在发送给Bob之前产生的。Bob知道这个秘密，因为Bob有私钥，能够解密Alice的消息。因为他们都知道这个秘密，所以他们就可以初始化一个对称的密码算法然后开始传输用它加密的消息。下面是订正的协议：
　　 A-->B hello
　　B-->A Hi, I'm Bob, bobs-certificate
　　A-->B prove it
　　B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
　　A-->B ok bob, here is a secret {secret} bobs-public-key
　　B-->A {some message}secret-key

　　secret-key 的计算取决于协议的定义，但是它可以简化成一个 secret 的副本。
　　你说什么？
　　Mallet的袋子里有很多诡计。虽然Mallet不能发现Alice和Bob交换的秘密，但是他可以干预并且破坏他们的对话。举例来说，如果Mallet位于Alice和Bob，他可以选择让大多数的消息返回以及向前继续传输没有改变，但是破坏了特定位的消息（这对他来说很容易，因为他知道Alice和Bob之间通信的协议）。
　　 A-->M hello
　　M-->B hello
B-->M Hi, I'm Bob, bobs-certificate
　　M-->A Hi, I'm Bob, bobs-certificate
　　A-->M prove it
　　M-->B prove it
　　B-->M Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
　　M-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
　　A-->M ok bob, here is a secret {secret} bobs-public-key
　　M-->B ok bob, here is a secret {secret} bobs-public-key
　　B-->M {some message}secret-key
　　M-->A Garble[ {some message}secret-key ]

　　Mallet一直让数据没有改变的通过，直到Alice和Bob分享一个秘密。然后Mallet通过改变Bob发送给Alice的消息来进入这个方式中。这时候Alice是相信Bob的，因此她就可能相信这个改变的消息，然后按照它来做。注意Mallet并不知道这个秘密-他能做的所有事就是破坏用这个秘密的密钥加密的数据。他可能不能利用这个协议制造出一条有效的消息，但是下一次，他可能幸运一点。
　　为了防止这种破坏，Alice和Bob在他们的协议中引入了一种消息认证码（MAC）。MAC是根据秘密的密钥和传输的数据计算出来的，上面描述的信息段算法的属性正好可以用于构造抵抗Mallet的MAC功能。
　　MAC := Digest[ some message, secret ]

　　因为Mallet不知道这个秘密的密钥，所以他无法计算出这个信息段的正确数值。即使Mallet随机的改变消息，如果信息段数据很大的话，他成功的可能性也很小。举例来说，通过使用MD5（RSA公司发明的一种很好的密码信息段算法），Alice和Bob能和他们的消息一起发送128位的MAC值。Mallet猜中这个正确的MAC值的几率是1/18，446，744，073，709，551，616，约等于零。
　　下面是样本协议，又订正了一次：
　　A-->B hello
　　B-->A Hi, I'm Bob, bobs-certificate
　　A-->B prove it
　　B-->A {digest[Alice, This Is Bob] } bobs-private-key
　ok bob, here is a secret {secret} bobs-public-key
　　{some message,MAC}secret-key

　　Mallet现在有麻烦了，Mallet可以改变任何的消息，但是MAC的计算将揭露他的欺诈行为。Alice和Bob能发现伪造的MAC值并停止会话，Mallet就不能伪造Bob的消息了。

　　这是什么时候的事？

　　最后的，但是同样重要的是要防范Mallet鹦鹉学舌。如果Mallet记录了会话的过程，他虽然可能不知道会话的内容，但是他可以重放这些会话。实际上，Mallet能在Alice和Bob之间做一些真正龌龊的事。解决的办法就是从会话的双方因如随机因素。

一 前言
　　
　　首先要澄清一下名字的混淆：
　　1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。
　　2 IETF(www.ietf.org)将SSL作了标准化，即RFC2246,并将其称为TLS（Transport Layer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别，本文中这两个名字等价。
　　3 在WAP的环境下，由于手机及手持设备的处理和存储能力有限，wap论坛（www.wapforum.org）在TLS的基础上做了...S协议（Wireless Transport Layer Security），以适应无线的特殊环境。
　　
　　我们从各式各样的文章中得知，SSL可以用于保密的传输，这样我们与web server之间传输的消息便是“安全的”。
　　而这种“安全”究竟是怎么实现的，最终有能实现多大程度的保密？本文希望能用通俗的语言阐明其实现原理。
　　
　　
二 整体结构概览
　　
　　SSL是一个介于HTTP协议与TCP之间的一个可选层，其位置大致如下：
　　
　　－－－－－－－－－
　　| HTTP |
　　－－－－－－－－－
　　| SSL |
　　－－－－－－－－－
　　| TCP |
　　－－－－－－－－－
　　| IP |
　　－－－－－－－－－
　　
　　如果利用SSL协议来访问网页，其步骤如下：
　　用户：在浏览器的地址栏里输入https://www.sslserver.com
　　HTTP层：将用户需求翻译成HTTP请求，如
　　GET /index.htm HTTP/1.1
　　Host http://www.sslserver.com
　　
　　SSL层：借助下层协议的的信道安全的协商出一份加密密钥，并用此密钥来加密HTTP请求。
　　TCP层：与web server的443端口建立连接，传递SSL处理后的数据。
　　
　　接收端与此过程相反。
　　
　　SSL在TCP之上建立了一个加密通道，通过这一层的数据经过了加密，因此达到保密的效果。
　　
　　SSL协议分为两部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。
　　
　　
三 需要的加密方面的基础知识

　　了解SSL原理需要一点点加密的概念，这里把需要的概念做一下简单阐述：
　　
　　加密一般分为三类，对称加密，非对称加密及单向散列函数。
　　
　　对称加密：又分分组密码和序列密码。
　　分组密码是将明文按一定的位长分组，明文组经过加密运算得到密文组，密文组经过解密运算
　　（加密运算的逆运算），还原成明文组。
　　序列密码是指利用少量的密钥（制乱元素）通过某种复杂的运算（密码算法）产生大量的伪随机位流，用于对明文位流的加密。
　　解密是指用同样的密钥和密码算法及与加密相同的伪随机位流，用以还原明文位流。
　　
　　CBC(Cipher Block Chaining)模式这个词在分组密码中经常会用到，它是指一个明文分组在被加密之前要与前一个的密文分组进行异或运算。当加密算法用于此模式的时候除密钥外，还需协商一个初始化向量（IV），这个IV没有实际意义，只是在第一次计算的时候需要用到而已。采用这种模式的话安全性会有所提高。
　　
　　分组密码的典型例子为DES,RC5,IDEA。
　　序列密码的典型例子为RC4。
　　
　　公钥加密：
　　简单的说就是加密密钥与解密密钥不同，分私钥和公钥。这种方法大多用于密钥交换，RSA便是一个我们熟知的例子。
　　还有一个常用的称作DH，它只能用于密钥交换，不能用来加密。
　　
　　单向散列函数：
　　由于信道本身的干扰和人为的破坏，接受到的信息可能与原来发出的信息不同，一个通用的办法就是加入校验码。
　　单向散列函数便可用于此用途，一个典型的例子是我们熟知的MD5,它产生128位的摘要，在现实中用的更多的是安全散列算法（SHA），SHA的早期版本存在问题，目前用的实际是SHA－1，它可以产生160位的摘要，因此比128位散列更能有效抵抗穷举攻击。
　　
　　由于单向散列的算法都是公开的，所以其它人可以先改动原文，再生成另外一份摘要。解决这个问题的办法可以通过HMAC（RFC 2104）,它包含了一个密钥，只有拥有相同密钥的人才能鉴别这个散列。
　　
　　
四 密钥协商过程
　　
　　由于对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。
　　
　　
　　SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。
　　
　　
　　Client Server
　　
　　Clienth*llo -------->
　　Serverh*llo
　　Certificate*
　　ServerKeyExchange*
　　CertificateRequest*
　　<-------- Serverh*lloDone
　　Certificate*
　　ClientKeyExchange
　　CertificateVerify*
　　[ChangeCipherSpec]
　　Finished -------->
　　[ChangeCipherSpec]
　　<-------- Finished
　　Application Data <-------> Application Data
　　
　　简单的说便是：SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个Clienth*llo来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个Serverh*llo，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。
　　
　　
五 密钥协商的形象化比喻
　　
　　如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。
　　
　　A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。
　　
　　B：我们用DES－RSA－SHA这对组合好了。
　　这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
　　目前没有别的可说的了。
　　
　　A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
　　（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
　　我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
　　注意，下面我就要用加密的办法给你发消息了！
　　（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
　　[我说完了]
　　
　　B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
　　注意，我也要开始用加密的办法给你发消息了！
　　[我说完了]
　　
　　A: [我的秘密是...]
　　
　　B: [其它人不会听到的...]
　　
　　
六 加密的计算

　　上一步讲了密钥的协商，但是还没有阐明是如何利用加密密钥，加密初始化向量和hmac的密钥来加密消息的。
　　其实其过程不过如此：
　　1 借助hmac的密钥，对明文的消息做安全的摘要处理，然后和明文放到一起。
　　2 借助加密密钥，加密初始化向量加密上面的消息。
　　
　　
七 安全性

　　SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论，
　　目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以
　　通过man in the middle攻击来截获https的消息。
　　
　　从上面的原理可知，SSL的结构是严谨的，问题一般出现在实际不严谨的应用中。常见的攻击就是
　　middle in the middle攻击，它是指在A和B通信的同时，有第三方C处于信道的中间，可以完全
　　听到A与B通信的消息，并可拦截，替换和添加这些消息。
　　
　　1 SSL可以允许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便无法验证B的公钥
　　和身份的真实性，从而C可以轻易的冒充，用自己的密钥与双方通信，从而窃听到别人谈话的内容。
　　而为了防止middle in the middle攻击，应该采用有证书的密钥交换算法。
　　2 有了证书以后，如果C用自己的证书替换掉原有的证书之后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？
　　3 由于美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，如果只采用浏览器自带的加密功能的话，理论上存在被破解可能。
　　
　　
八 代理

　　下面探讨一下SSL的代理是怎样工作的(可参见[6])。这可能与你开始想的不太一样：）
　　当在浏览器里设置了https的代理，而且在浏览器里输入了https://www.example.com之后，
　　浏览器会与proxy建立tcp链接，然后向其发出这么一段消息：
　　CONNECT server.example.com:443 HTTP/1.1
　　Host: server.example.com:443
　　
　　然后proxy会向webserver端建立tcp连接,之后，这个代理便完全成了个内容转发装置。浏览器
　　与web server会建立一个安全通道，因此这个安全通道是端到端的，尽管所有的信息流过了proxy,
　　但其内容proxy是无法解密和改动的（当然要由证书的支持，否则这个地方便是个man in the middle攻击的好场所，见上面的讨论）。
　　
　　
九 关于证书
　　
　　注意，如果对于一般的应用，管理员只需生成“证书请求”（后缀大多为.csr），它包含你的名字和公钥，然后把这份请求交给诸如verisign等有CA服务公司（当然，连同几百美金），
　　你的证书请求经验证后，CA用它的私钥签名，形成正式的证书发还给你。管理员再在web server上导入这个证书就行了。如果你不想花那笔钱，或者想了解一下原理，可以自己做CA。
　　从ca的角度讲，你需要CA的私钥和公钥。从想要证书的服务器角度将，需要把服务器的证书请求交给CA.
　　
　　如果你要自己做CA，别忘了客户端需要导入CA的证书（CA的证书是自签名的，导入它意味着你“信任”这个CA签署的证书）。
　　而商业CA的一般不用，因为它们已经内置在你的浏览器中了。
　　
　　
十 wtls
　　
　　在WAP的环境中，也有安全加密的需求，因此wapforum参照在WWW世界里最为流行的SSL协议设计了WTLS.从原理上说，这份协议与SSL是基本相同的，但在具体的地方作了许多改动。这些改动的大多没有什么技术上的需要，而是由于考虑到手持设备运算与存储的局限而尽量做了简化。不过我的感觉是这些改动意义实在不大，其获得的计算和存储上节省出来的时间和空间并不多。在硬件速度突飞猛进的时代，这种改动能获得的好处也许并不很多（一个新的协议便需要大量新的投入，而且与原有体制并不兼容，关于这点有文章[7]做了精彩阐述，可参看）。
　　
　　这里我简单举一些SSL与WTLS的差别。
　　
　　1 WTLS在一般udp这类不可靠信道之上工作，因此每个消息里要有序列号，协议里也要靠它来处理丢包，重复等情况。
　　此外，拒绝服务攻击也因此变得更加容易。
　　2 WTLS建立的安全连接是在wap网关和手持设备之间，wap网关和web server之间如果也要保密，便要采再用SSL，即在这种模型中无法实现端到端的加密。
　　
　　---------- ------------- ---------
　　| Mobile |----------->| WAP |---------->| WEB |
　　| Device |<-----------| Gateway |<----------|Server |
　　| | WTLS | | SSL | |
　　---------- ------------- ---------
　　
　　3 WTLS协议里加了一种成为key_refresh的机制,当传递了一定数量数据包后，双方通过同样的算法将自己的密钥做一下更新。付出了很小的代价，安全性得以增强。

    当PC客户机向UNIX计算机发起telnet请求时，PC的telnet客户程序就产生一个TCP包并把它传给本地的协议栈准备发送。接下来，协议栈将这个TCP包“塞”到一个IP包里，然后通过PC机的TCP/IP栈所定义的路径将它发送给UNIX计算机。在这个例子里，这个IP包必须经过横在PC和UNIX计算机中的防火墙才能到达UNIX计算机。

    现在我们“命令”（用专业术语来说就是配制）防火墙把所有发给UNIX计算机的数据包都给拒了，完成这项工作以后，“心肠”比较好的防火墙还会通知客户程序一声呢！既然发向目标的IP数据没法转发，那么只有和UNIX计算机同在一个网段的用户才能访问UNIX计算机了。

还有一种情况，你可以命令防火墙专给那台可怜的PC机找茬，别人的数据包都让过就它不行。这正是防火墙最基本的功能：根据IP地址做转发判断。但要上了大场面这种小伎俩就玩不转了，由于黑客们可以采用IP地址欺骗技术，伪装成合法地址的计算机就可以穿越信任这个地址的防火墙了。不过根据地址的转发决策机制还是最基本和必需的。另外要注意的一点是，不要用DNS主机名建立过滤表，对DNS的伪造比IP地址欺骗要容易多了。 

服务器TCP/UDP 端口过滤

    仅仅依靠地址进行数据过滤在实际运用中是不可行的，还有个原因就是目标主机上往往运行着多种通信服务，比方说，我们不想让用户采用 telnet的方式连到系统，但这绝不等于我们非得同时禁止他们使用SMTP/POP邮件服务器吧？所以说，在地址之外我们还要对服务器的TCP/ UDP端口进行过滤。

比如，默认的telnet服务连接端口号是23。假如我们不许PC客户机建立对UNIX计算机（在这时我们当它是服务器）的telnet连接，那么我们只需命令防火墙检查发送目标是UNIX服务器的数据包，把其中具有23目标端口号的包过滤就行了。这样，我们把IP地址和目标服务器TCP/UDP端口结合起来不就可以作为过滤标准来实现相当可靠的防火墙了吗？不，没这么简单。 

客户机也有TCP/UDP端口

    TCP/IP是一种端对端协议，每个网络节点都具有唯一的地址。网络节点的应用层也是这样，处于应用层的每个应用程序和服务都具有自己的对应“地址”，也就是端口号。地址和端口都具备了才能建立客户机和服务器的各种应用之间的有效通信联系。比如，telnet服务器在端口23侦听入站连接。同时telnet客户机也有一个端口号，否则客户机的IP栈怎么知道某个数据包是属于哪个应用程序的呢？

    由于历史的原因，几乎所有的TCP/IP客户程序都使用大于1023的随机分配端口号。只有UNIX计算机上的root用户才可以访问1024以下的端口，而这些端口还保留为服务器上的服务所用。所以，除非我们让所有具有大于1023端口号的数据包进入网络，否则各种网络连接都没法正常工作。

    这对防火墙而言可就麻烦了，如果阻塞入站的全部端口，那么所有的客户机都没法使用网络资源。因为服务器发出响应外部连接请求的入站（就是进入防火墙的意思）数据包都没法经过防火墙的入站过滤。反过来，打开所有高于1023的端口就可行了吗？也不尽然。由于很多服务使用的端口都大于1023，比如X client、基于RPC的NFS服务以及为数众多的非UNIX IP产品等（NetWare/IP）就是这样的。那么让达到1023端口标准的数据包都进入网络的话网络还能说是安全的吗？连这些客户程序都不敢说自己是足够安全的。
双向过滤

    OK，咱们换个思路。我们给防火墙这样下命令：已知服务的数据包可以进来，其他的全部挡在防火墙之外。比如，如果你知道用户要访问Web服务器，那就只让具有源端口号80的数据包进入网络：

不过新问题又出现了。首先，你怎么知道你要访问的服务器具有哪些正在运行的端口号呢？ 象HTTP这样的服务器本来就是可以任意配置的，所采用的端口也可以随意配置。如果你这样设置防火墙，你就没法访问哪些没采用标准端口号的的网络站点了！反过来，你也没法保证进入网络的数据包中具有端口号80的就一定来自Web服务器。有些黑客就是利用这一点制作自己的入侵工具，并让其运行在本机的80端口！ 

检查ACK位

    源地址我们不相信，源端口也信不得了，这个不得不与黑客共舞的疯狂世界上还有什么值得我们信任呢？还好，事情还没到走投无路的地步。对策还是有的，不过这个办法只能用于TCP协议。

    TCP是一种可靠的通信协议，“可靠”这个词意味着协议具有包括纠错机制在内的一些特殊性质。为了实现其可靠性，每个TCP连接都要先经过一个“握手”过程来交换连接参数。还有，每个发送出去的包在后续的其他包被发送出去之前必须获得一个确认响应。但并不是对每个TCP包都非要采用专门的ACK包来响应，实际上仅仅在TCP包头上设置一个专门的位就可以完成这个功能了。所以，只要产生了响应包就要设置ACK位。连接会话的第一个包不用于确认，所以它就没有设置ACK位，后续会话交换的TCP包就要设置ACK位了。

举个例子，PC向远端的Web服务器发起一个连接，它生成一个没有设置ACK位的连接请求包。当服务器响应该请求时，服务器就发回一个设置了ACK位的数据包，同时在包里标记从客户机所收到的字节数。然后客户机就用自己的响应包再响应该数据包，这个数据包也设置了ACK位并标记了从服务器收到的字节数。通过监视ACK位，我们就可以将进入网络的数据限制在响应包的范围之内。于是，远程系统根本无法发起TCP连接但却能响应收到的数据包了。

    这套机制还不能算是无懈可击，简单地举个例子，假设我们有台内部Web服务器，那么端口80就不得不被打开以便外部请求可以进入网络。还有，对UDP包而言就没法监视ACK位了，因为UDP包压根就没有ACK位。还有一些TCP应用程序，比如FTP，连接就必须由这些服务器程序自己发起。 

FTP带来的困难

    一般的Internet服务对所有的通信都只使用一对端口号，FTP程序在连接期间则使用两对端口号。第一对端口号用于FTP的“命令通道”提供登录和执行命令的通信链路，而另一对端口号则用于FTP的“数据通道”提供客户机和服务器之间的文件传送。

    在通常的FTP会话过程中，客户机首先向服务器的端口21（命令通道）发送一个TCP连接请求，然后执行LOGIN、DIR等各种命令。一旦用户请求服务器发送数据，FTP服务器就用其20端口 (数据通道)向客户的数据端口发起连接。问题来了，如果服务器向客户机发起传送数据的连接，那么它就会发送没有设置ACK位的数据包，防火墙则按照刚才的规则拒绝该数据包同时也就意味着数据传送没戏了。通常只有高级的、也就是够聪明的防火墙才能看出客户机刚才告诉服务器的端口，然后才许可对该端口的入站连接。

UDP端口过滤

    好了，现在我们回过头来看看怎么解决UDP问题。刚才说了，UDP包没有ACK位所以不能进行ACK位过滤。UDP 是发出去不管的“不可靠”通信，这种类型的服务通常用于广播、路由、多媒体等广播形式的通信任务。NFS、DNS、WINS、NetBIOS-over-TCP/IP和 NetWare/IP都使用UDP。

    看来最简单的可行办法就是不允许建立入站UDP连接。防火墙设置为只许转发来自内部接口的UDP包，来自外部接口的UDP包则不转发。现在的问题是，比方说，DNS名称解析请求就使用UDP，如果你提供DNS服务，至少得允许一些内部请求穿越防火墙。还有IRC这样的客户程序也使用UDP，如果要让你的用户使用它，就同样要让他们的UDP包进入网络。我们能做的就是对那些从本地到可信任站点之间的连接进行限制。但是，什么叫可信任！如果黑客采取地址欺骗的方法不又回到老路上去了吗？

    有些新型路由器可以通过“记忆”出站UDP包来解决这个问题：如果入站UDP包匹配最近出站UDP包的目标地址和端口号就让它进来。如果在内存中找不到匹配的UDP包就只好拒绝它了！但是，我们如何确信产生数据包的外部主机就是内部客户机希望通信的服务器呢？如果黑客诈称DNS服务器的地址，那么他在理论上当然可以从附着DNS的UDP端口发起攻击。只要你允许DNS查询和反馈包进入网络这个问题就必然存在。办法是采用代理服务器。

    所谓代理服务器，顾名思义就是代表你的网络和外界打交道的服务器。代理服务器不允许存在任何网络内外的直接连接。它本身就提供公共和专用的DNS、邮件服务器等多种功能。代理服务器重写数据包而不是简单地将其转发了事。给人的感觉就是网络内部的主机都站在了网络的边缘，但实际上他们都躲在代理的后面，露面的不过是代理这个假面具。

小结

    IP地址可能是假的，这是 由于IP协议的源路有机制所带来的，这种机制告诉路由器不要为数据包采用正常的路径，而是按照包头内的路径传送数据包。于是黑客就可以使用系统的IP地址获得返回的数据包。有些高级防火墙可以让用户禁止源路由。通常我们的网络都通过一条路径连接ISP，然后再进入Internet。这时禁用源路由就会迫使数据包必须沿着正常的路径返回。

    还有，我们需要了解防火墙在拒绝数据包的时候还做了哪些其他工作。比如，防火墙是否向连接发起系统发回了“主机不可到达”的ICMP消息？或者防火墙真没再做其他事？这些问题都可能存在安全隐患。ICMP“主机不可达”消息会告诉黑客“防火墙专门阻塞了某些端口”，黑客立即就可以从这个消息中闻到一点什么气味。如果ICMP“主机不可达”是通信中发生的错误，那么老实的系统可能就真的什么也不发送了。反过来，什么响应都没有却会使发起通信的系统不断地尝试建立连接直到应用程序或者协议栈超时，结果最终用户只能得到一个错误信息。当然这种方式会让黑客无法判断某端口到底是关闭了还是没有使用。

附录:Windows XP SP2防火墙的工作原理 

    对于只使用浏览、电子邮件等系统自带的网络应用程序，Windows防火墙根本不会产生影响。也就是说，用IE、OutlookExpress等系统自带的程序进行网络连接，防火墙是默认不干预的。微软在设置防火墙内置规则时，已经为自家的应用程序开了“绿色通道”，所以装上SP2后，即使打开其防火墙并且启用“不允许例外”，无需将IE加到“例外”就能上网，而防火墙也不会询问是否要允许IE通过。


SP2防火墙与第三方防火墙软件的区别

　　仅就防火墙功能而言，Windows防火墙只阻截所有传入的未经请求的流量，对主动请求传出的流量不作理会。而第三方病毒防火墙软件一般都会对两个方向的访问进行监控和审核，这一点是它们之间最大的区别。如果入侵已经发生或间谍软件已经安装，并主动连接到外部网络，那么Windows防火墙是束手无策的。不过由于攻击多来自外部，而且如果间谍软件偷偷自动开放端口来让外部请求连接，那么Windows防火墙会立刻阻断连接并弹出安全警告，所以普通用户不必太过担心这点。这就好像宾馆里的房门一样——外面的人要进入必须用钥匙开门，而屋里的人要出门，只要拉一下门把手就可以了。