[转帖]给你选择 SSL VPN 的理由 (相对于IPSec VPN)...

游客，如果您要查看本帖隐藏内容请回复

[此贴子已经被作者于2004-5-11 11:35:05编辑过]

很好的东西呀。。大家不来看看吗？

好，我来看下！

看看

看看

look

大家喜欢看SSL VPN组网方案吗？

应用简便成本低是最大的好处。

我对两种产品都有接触，不否认SSL有它的特点，但是最近SSL VPN对产品的介绍有一定误导的趋势 从应用范围上，IPSec VPN比SSL肯定有明显的优势， 从配置管理上，如果需要，IPSec VPN的配置，尤其是客户端的配置完全可以简化到和SSL VPN的程度，唯一多的就是需要安装客户端。目前IPSec VPN复杂的原因多数在于协议的复杂性（由于考虑了更多情况的适用性），还有一个原因就是由于IPSec VPN开始的早，很多厂商无法突破原有的使用模式（例如Cisco的IPSec配置超复杂，害了一帮做网络设备的厂商）。另外一个重点是由于SSL VPN是全新的冬冬，没有参考，所以很多新兴的SSL VPN厂商为了吸引用户，将SSL VPN的配置能省则省，算法，安全等级等去掉，甚至在身份认证部分也有太过简单，实际上有很大的安全隐患。 例如，尽管SSL VPN依靠IE对服务器证书进行了认证，但是无法限定对端CA，对端DN，因此很容易采用第三方攻击。有的服务器端也不对客户端的身份进行认证，或者简化认证，而这些存在重要安全性的地方却在SSL VPN产品中往往被略过。 从网络的适用性上看，SSL VPN通常只适合C/S的网络，客户端之间不能互相访问，VPN网络之间不能互联。而IPSec VPN在这方面显然更有生命力，例如星形，网状的VPN拓扑。 至于扩展性，我可以明确的说，好的IPSec VPN产品完全可以做到只定义一到两条隧道适应整个VPN网络，并且后期的维护，增删设备都不会影响配置，更无需谈到“要考虑网络的拓扑结构，如果增添新的设备，往往要改变网络结构，那么IPSec VPN就要重新部署”。事实上，目前，IPSec VPN中客户端全部采用动态IP（拨号），或位于NAT之后，甚至两端动态都是可以解决的问题，不知道你们认为网络还会怎么改变？ 最后，我声明我从事的产品开发包括PKI，IPSec VPN和少量SSL VPN，个人不喜欢IPSec/IKE协议，（可能是一群学究搞的，太复杂了，不切合使用，SSL定义的更好），但在产品方面，我认为IPSec VPN目前有更广泛的实用性。

首先我们没有必要把IPSec VPN与SSL VPN放到一个对立的角度来考虑，存在的就是合理的。IPSec 与 SSL的VPN各有其价值，在目前两个产品还没法互相代替，那一天出现的可能性也不是很大，即使网络协议发展到IPV6（协议本身已经有了安全性的考虑），SSL协议或IPSec协议我认为也依然会存在。 技术方面 首先把实现SSL协议软件叫做VPN那是非常错误的，虽然目前大多数人都是这么认为的。SSL是SecureSocketLayer,哪怕用新的名字TSL（Transfar Security Layer）来称呼它都应该意识到单纯的SSL协议并不能构成VPN，因为 既然是虚拟专用网就不应该只支持某个或某几个协议或应用，而是应该对上层应用协议都做支持。有的人把HTTPS叫做SSL VPN，我有点无法理解，因为HTTPS是直接与上层应用绑定的，无法向IPSec那样与做到与应用分离，所以无法做到HTTPS与浏览器或Web服务器分离。我们所称的SSL VPN努力做到SSL层与上成应用分离，力求最大程度地支持上层应用，也就是为了解决紫式雾所提出的第一个问题，（----从应用范围上，IPSec VPN比SSL肯定有明显的优势），当然SSL VPN无法支持UDP协议，这是因为SSL必须工作在可靠的通信通道上，幸运的是UDP并没有被大多数的应用层协议采用，所以我们放弃了对于UDP的支持。但是对于采用TCP通信的上层协议我们做了很好的支持。我来给大家举几个简单的例子。 浏览器：IE,Netscape Browser,Opera,Mozilla,甚至是consol方式的lynx,curl等 单通道的TCP协议,比如说 SMTP,POP3,IMAP,Lotos Notes,微软的网络邻居等，Telnet,远程桌面等等。 双通道甚至多通道的应用，比如FTP,Oracle, BEA tuxedo中间件等 所以要做好SSL VPN，并不是只实现SSL协议就可以了，要能够在多种上成协议中切换，同时支持多种上成协议也是非常重要的。在TCP传输领域中SSL 的支持上层应用的能力并不比IPSec差多少。好多安全产品厂商将IPSec VPN作为防火墙中的一个模块，找到网络管理员的抱怨，原因很简单，速度变慢，网管不买账。 关于身份认证与访问控制，我们的SSL VPN的身份认证模块支持数字证书，双因素，NT域，LDAP，RADIUS以及本地管理的用户名口令方式，对于不同角色的用户具有不同的访问权限，与IPSec 相比可定是进步，紫式雾说的（将SSL VPN的配置能省则省，算法，安全等级等去掉，甚至在身份认证部分也有太过简单）绝对有失公道（也许个别厂商是这么做的）。所谓SSL管理简单是通过更为人性化的配置界面换来得，而不是靠损失功能与安全性换来的。 在加密强度方面我们目前已经达到了256位的对称密码与2048位的非对称密码，并且支持国产的加密算法，而有些IPSec 厂商还在以56位的DES与168位的3DES为荣。 所谓遭受第三方攻击更是没有道理，紫式雾忽略了一点，我们的VPN客户端并不是IE,我们也没有采用任何微软的加密手段，正式因为我们的VPN客户端，才能够使我们的VPN方案满足大量的上层安全应用。而SSL协议在认证的时候绝对能够发现第三方的攻击行为，而IPSec 用于密钥交换的IKE可能会有此弱点。 回到适用性上， 其实B/S结构的应用也是客户端之间无法互访的。现在的网络结构都采用了集中式管理的方式，服务器与数据中心的集中为SSL VPN的发展铺平了道路，也许在服务器分散的结构中IPSec VPN是主角，在服务器集中的结构中站主角地位的将会使SSL VPN. 最后，我也感谢紫式雾给我们提出的建议，也许我对VPN的看法还不够全面，通过与诸位的交流我们将会提供我们对VPN的认识，同时提高我们的产品。

谢谢vicky0318的回复，很高兴和你讨论IPSec和SSL的技术问题。其实SSL和IPSec应该是有很多类似的地方，所以大家喜欢放到一起比较，由于也许前面的发言对SSL也有偏见，之所以谈到部分SSL VPN存在的问题，也和目前一些SSL VPN的使用方式相关。 目前SSL VPN普遍采用的做法是SSL服务器＋USB卡（U盘或IC卡）的方式，通常不再安装客户端软件（或者安装一个基本无配置的客户端），由于不安装客户端软件，所以一些本来是双方进行SSL协商时确定的参数实际只能由服务器端决定。当然这不是什么大问题（客户通常也不想配置这些冬冬），我只是认为这不是SSL客户端和IPSec客户端配置难度的区别（IPSec 客户端同样也经常这样做）。 从支持的应用看，SSL VPN支持的应用肯定会更少，而且每增加一种稍微复杂的应用都需要重新开发，调试，（我相信你谈到的支持FTP，Oracle一定是SSL VPN开发中比较耗时的部分）。反过来说，正是由于SSL VPN针对更专一，才是SSL VPN相对IPSec VPN的真正优势，因为应用范围更明确，所以SSL VPN的厂商可以将配置做的更简单，甚至可以带来很多新意。 至于加密强度和性能，由于SSL VPN处于IP层之上，因此在协议处理中消费的时间更多一些，而加密时间，大家都是对称加密，AES，3DES，没有什么区别。因此总的来说，IPSec的性能应该高一些，尤其是上高端设备，会更容易（因为采用硬件加密后，协议处理的时间就会变突出）。至于算法，没啥可比的, : ) 身份认证部分，IPSec和SSL是比较象的，应该没有太大的优劣之分。IPSec支持预共享密钥，证书，扩展认证，也能做到基于证书，身份信息进行访问控制等。 你谈到的SSL VPN支持的认证方式对应的是IPSec的证书和扩展认证（包括RADIUS等），而双因素认证是一种表现形式，一些IPSec VPN也有这种冬冬，就是说用户需要PIN口令开启USB钥匙，并用USB卡中的机密信息完成认证（比如一次一密，或者USB中存放证书私钥等）。 至于我说的第三方攻击，也是和目前SSL的普遍应用方式有关，和SSL，IKE协议，以及密钥强度无关。 我们假设两种情况，采用IE作为SSL客户端，或安装自己的客户端 第一种情况，由于Windows默认信任的CA太多，信任关系复杂，客户端根本不会注意到当前的服务器证书是否是正确的CA颁发的，而且即使采用一个自签名证书也很容易骗过去（Windows仅会弹出一个警告）。 第二种情况，采用自己的客户端，那么可能是在USB卡中存放了CA信息，但这通常只能保证对端的证书有效，而不能保证对端的身份正确。因此可能出现拥有同样CA签发的证书的攻击者冒充服务器的可能（当然这和使用方式，管理等有关，我不清楚你们是否会存在这个问题，SSL和IKE协议本身都考虑了对第三方攻击的防御）。 我的看法是，SSL VPN针对更专一，才是SSL VPN相对IPSec VPN的真正优势，而正是因为IPSec试图解决的问题太多，所以很多厂商忽视了对最基本的典型应用领域的解决方案。

两位MM的辩论确实厉害，各有千秋，令俺佩服！

最终的选择权还是要放到客户身上，平台一样，只不过就是在技术上面做一些改进和增强！

我在你们讨论的话题之中学到了不少，谢谢！

[此贴子已经被作者于2004-7-22 1:38:13编辑过]

好东西啊

首先非常谢谢紫式雾跟我讨论。。希望我们在彼此的沟通中都能有所收获。。同时也欢迎做VPN的朋友们都加入进来。。使我们可以在技术和理论上都能得到进步。。 > 至于加密强度和性能，由于SSL VPN处于IP层之上，因此在协议处理中消费的时间更多一些，而加密时间，大家都是对称加密，AES，3DES，没有什么区别。因此总的来说，IPSec的性能应该高一些，尤其是上高端设备，会更容易（因为采用硬件加密后，协议处理的时间就会变突出）。至于算法，没啥可比的, : ) SSL VPN的加密处理在TCP协议之上，应用层之下，IPSec VPN的加密处理在IP层中，非常明显 -- IPSec对于IP层中的数据进行加密，其实需要保密的仅仅是部分数据，而SSL VPN正好可以做到这一点，IPSec的全部数据的加密将会占用更多的系统资源，在相同配置的设备上，两种解决办法的性能优略的比较很容易得到结果。 > 我们假设两种情况，采用IE作为SSL客户端，或安装自己的客户端 > 第一种情况，由于Windows默认信任的CA太多，信任关系复杂，客户端根本不会注意到当前的服务器证书是否是正确的CA颁发的，而且即使采用一个自签名证书也很容易骗过去（Windows仅会弹出一个警告）。 > 第二种情况，采用自己的客户端，那么可能是在USB卡中存放了CA信息，但这通常只能保证对端的证书有效，而不能保证对端的身份正确。因此可能出现拥有同样CA签发的证书的攻击者冒充服务器的可能（当然这和使用方式，管理等有关，我不清楚你们是否会存在这个问题，SSL和IKE协议本身都考虑了对第三方攻击的防御）。 无论对于第一种情况还是第二种情况，第三方攻击都不能发生，SSL协议本身可以有效实时发现第三方攻击。 也许紫式雾指的是下面的情况（这种第三方攻击不是实施的第三方攻击），正常情况下S---C之间通信，如果有第三方M出现,就形成了如下的通信方式，S--M--C,这个时候M必须充当S的客户端，本来是C-S之间的通信，这个时候变成了C-S之间的通信有M来转发，也就是说C-M之间建立起一段SSL连接，M-S之间建立起一段SSL连接，M也许有这个能力，甚至利用SSLdump等工具分析VPN网关与客户端之间的通信协议，但是M无法向S证明自己就是是C(除非M拿到C的私要与证书--这是SSL安全性的保证)，所以S不会将M当作C来对待。M也不能向C证明自己就是S(除非M拿到了S的私钥和数字证书)，所以C不会将M当成S来对待，S和C都无法被骗，原因在于公信第三方CA,C和S通过CA来确定对方的身份。M对于S来说是合法的客户端，M对于C来说是合法的网关，也就到此为止，到目前为止M可以通过S作自己权限范围内的访问，M也无法以S的身份来欺骗C获得一些信息。其他关于SSL发现第三方攻击的能力可以察看协议说明。