2000年10月，一位名叫凯文·福的年轻人披露了有关SSL和Akamai的一个相当敏感的问题，Akamai是一个能够提供快捷可靠服务的Web宿主机。福在发给BUGTRAQ的邮件清单中报告了他的发现：他在通过Akamai服务器为自己的个人站点（fooworld.org）申请代理服务时，Web浏览器收到的却是一份代表Akamai服务器的证书，而不是由他本人在fooworld.org签名发出的那份证书。这一事实造成的后果是，用户可能很轻易地被欺骗，以为自己访问了一个持有有效证书的站点。更有甚者，有人还可以制造对某个所谓的有效站点的连接，而用户只凭在浏览器上看到的有效证书，也就相信了它。在Akamai的案例中，这种情况表现为：Akamai代理服务器接收到一个非法的或者自签名的证书时，它将它自身的证书回送给了用户。正常情况下应该是Akamai拒绝对有此类问题的服务器提供代理服务。
一些大型站点为解决SSL密钥交换带来的吞吐量下降，采用了将SSL代理服务器安置在网页服务器之前的方法。这也就意味着用户的机密数据在到达安全设备前的最后几米的网络上处于一种未加密状态。不要忘记，你的数据一旦被存储在一个电子商务站点，SSL对它的保护就无能为力了。它们有可能被人通过一些没有安全防范措施的站点加以窃取。
重新审视“魔法”
虽然SSL确实增强了网上电子交易的安全性，但它并不是一个成熟完善的解决方案。较弱的加密技术，意外的口令泄密 ，以及种种错误认证的发生等等，它们结合在一起，使得人们对SSL安全方案的所谓完善性产生了动摇。
现今应用的SSL甚至还存在着一个更大的、还未被指认的隐患。在SSL所依赖的网页浏览器里预先安装了一系列经过确认的顶级认证中心的证书，我们可以通过选择Navigator浏览器的“安全\证书\签发者”选项看到这些证书列表。但是浏览器无法核查这些证书是否已被撤销。如果一个证书的所有者不能控制与该证书对应的专用密钥，那这张证书就不能再被使用了，并且必须撤销。但现今的浏览器都不具备撤销证书的内在机制。
以上所述的目的并不是要废弃SSL，而是向公众指出SSL在当前的使用方式中存在着缺陷。Web用户必须记住：看到有安全挂锁标志的图标并不意味着您的数据信息正处于安全状态，只有当那些数据通过因特网安全地传输到正确的服务器端之后才能称之为安全，否则，一切所谓安全保证都不可信。
在一个不可靠的世界里，人们往往寄希望于一些他们自己觉得可以信赖的事物。SSL就是那种能给广大Web浏览器用户带来某种温暖而又含混的感觉的东西。SSL在以加密的形式传送数据信息给有关的服务器同时，还能够对这些服务器进行身份认证。人们在经历了对各种软件产品的不断失望之后，似乎感到SSL终于要为这个不可知的世界带来一片安全空间了。然而遗憾的是，SSL的过去和现在都始终是变幻莫测的。如同其它所有涉及加密包的安全问题一样，目前可供SSL使用并获取支持的配给还远不如软件业那么多。SSL原是要向人们承诺某种安全保证的，但在时有曝光的失败事件之后，它能留给大家的只是一个虚幻的安全。
布鲁斯·斯西纳在他新出版的一本名为《秘密与谎言》的书中写道，曾经他认为加密技术好象一种魔法，能够解决所有的安全问题。在经过一段时期并有了更多的经验以后，他认识到其实安全不是一个产品，而是一个过程，并且象SSL这样的加密技术方案不可能置身在真空之中。在这里，我们将审视SSL是如何操作的，它到底能做些什么，还存在什么问题，它在2000年网景的Navigator浏览器、微软的IE浏览器以及因特网信息资源服务器业界引起了什么样的风波。
SSL的起源
HTTP（定义为 RFC 2616）具有非常简单的安全支持，Web服务器能够通过认证客户的用户名和口令，来决定是否提供连接服务。这一机制不能对已经送至因特网上的口令提供保护，也无法确保Web浏览器一定能够连接到正确的服务器上。事实上，通过HTTP传送的任何数据都可能被窃取，引起诸如信用卡号码、私人或公司信息等的失密。
在HTTP成为因特网访问的支柱后不久，就有几家公司公布了他们关于Web应用的安全协议。有一个由IETF发起的官方支持协议，被称作Secure HTTP（缩写为SHTTP,定义为 RFC 2660）。还有几个非官方协议方案，其中就包括一项由网景公司提出的、获得网景浏览器众多用户全力支持的安全方案。直到今天，网景的这套名为SSL的加密方案还未成为因特网的一种安全标准。您可以从网景开发商的Web站点上查找到有关SSL的资料，并且能够在OpenSSL.org上很方便地使用它。
SSL的运作
你开始使用SSL时，必须进入运行https而不是http的URL。相应地，SSL使用的缺省端口为443而不是80。首先由你的浏览器向服务器端发送使用SSL的联络信号，其中包括加密方法和压缩模式。如果服务器支持SSL应用，就回应一个信号，也向客户发送自己的加密方法和压缩模式，包括它的证书以及随机产生的数据 ，后者将会在执行协议时用到。
客户端用服务器发送的信息验证服务器身份，检查所连服务器名与其证书是否相符，并确定其证书是否有效。
该认证过程还包括检验证书上的数字签名，这种数字签名必须是由客户端信任的认证机构签发的公钥中的一个，它们或是预先存放在浏览器里，或是后来提供给用户的。如果发现证书与服务器名不符合，或者不是由某个认证机构签发的，客户可立即终止连接。
客户完成认证之后，就发送他自身的随机数据，并且根据所选择的密钥交换协议，来决定发送一个加密密钥还是发送一组确定该密钥的数据。这个密钥将用来产生会话密钥，以及在交换数据信息时为数据加密，同时还将为这些数据信息进行数字化签名，以维护被交换数据的完整性并对其提供认证。服务器端也可以要求客户端提供证书，并对浏览器用户进行认证。
如果双方握手成功，浏览器就向Web服务器发送完成信号，服务器也报以自己的完成信号作为响应，于是双方交换加密信息和经数字签名的数据。
密钥交换在计算机操作中需要花费一段较长的时间。因此，SSL协议中还包括减少不必要的密钥交换量。假如Web浏览器连接另一个同样使用SSL的服务器，就可以向它发送一个会话标识符，如果服务器接受该标识符，那么它们则可以使用原来约定的加密、压缩算法以及公用的密钥，相互间进行信息交换。网景浏览器还具有某种特殊功能，使得每次完成数据交换之后，TCP还能保持一段开放时间，即使没有进一步的约定，也能进行信息交易。
阿基里斯的脚踝
阿基里斯，希腊神话传奇中的英雄，出生时被其母亲倒抓脚踝，泡入圣水中，故全身能刀枪不入，但被其母握住未能浸入圣水里的脚踝，就成为他身上唯一的致命之处。
SSL最大的问题是密钥长度。短密钥容易被人通过尝试各种可能的密钥组合而得到破解。有人利用几台当前最时新的PC电脑，只用了不到一天的时间就破译出一个40位的密钥。现在国际上流行的网景和IE浏览器版本的用户采用的正是40位的SSL。Linux操作系统比如RedHat开发于美国，由于受到美国国家安全局的出口限制，其密钥长度也只有40位。
网景公司还出现了另外一个安全问题。2000年5月，麻省理工学院的学生凯文·福发现网景浏览器可以被无效的证书所欺骗。他在访问一个站点时，发现该站点服务器的名字与其证书上授权使用的名字不符。但他选择继续进行以后，网景浏览器却再也检测不出上述名字不符的情况了。
斯洛文尼亚ACROS公司的卡勒斯克也发现了一个问题，并就此写了一个CA-2000-05报告。卡勒斯克发现，Navigator浏览器把对同一个IP地址的并发访问，当成了合法使用SSL session的一部分。只要在DNS上稍做手脚，就可以利用Navigator浏览器访问另外的站点，破坏其对服务器名字和服务器证书上的名字的认证机制。微软也在2000年发现了SSL的问题。两个版本的因特网信息资源服务器（IIS4.0和IIS5.0）相互发送同样的会话数据，它们使用的是普通的HTTP和SSL相结合的安全协议。但是IE浏览器泄露了此前输入的受SSL保护的口令。实际情况可能是：当您使用SSL访问站点服务器时，需要在浏览器弹出的对话框中输入您的用户名和口令。本来用户名和口令作为HTTP全部认证内容的一部分应该受到保护，因为所有用于交换的数据都已由SSL作了加密处理。但接下来如果您不使用SSL访问同一站点下的其它页面，您的用户名和口令将会以非加密的形式被发送出来，从而存在被任何窃听者截获的潜在威胁。鉴于这个问题的危害性，微软公司特地发布了有关的安全建议和相应的补丁程序 。总之，SSL并不像大家想象的那样安全可靠，还没有100%的解决方案保护你网络中的一切安全。 |
