如果你在互联网上访问某些网站时在浏览器窗口的下方有一个锁的小图标，就表示它表示该网页被SSL保护着。但用SSL防护的网站真的能够防范黑客吗？现在国内有很多人对SSL存在这么一个认识误区：SSL很安全，受到SSL防护网页服务器的资料就一定是万无一失的，这也导致这样一个局面，只要有着SSL防护的网站服务器很少接受审查以及监测。其实不然，对于安全要求不甚高的交易或认证，SSL还是一个相当不错的安全机制，然而若应用在特殊要求方面，它还存在有这样那样的问题。在下面的文中我将为大家简单介绍SSL存在的安全漏洞及解决方案，希望本文对你有所帮助。
一、认识SSL
一般人认为SSL是保护主机或者只是一个应用程序，这是一个误解，SSL不是设计用来保护操作系统的。SSL是Secure Sockets Layer通讯协议的简称，它是被设计用来保护传输中的资料，它的任务是把在网页以及服务器之间的数据传输加密起来。这个加密（encryption）的措施能够防止资料窃取者直接看到传输中的资料，像是密码或者信用卡号码等等。在这里谈到SSL，你就必须了解数字证书（Digital Certificates）的概念。
数字证书是一种能在完全开放系统中准确标识某些主体的机制。一个数字证书包含的信息必须能鉴定用户身份，确保用户就是其所持有证书中声明的用户。除了唯一的标识信息外，数字证书还包含了证书所有者的公共密钥。数字证书的使用允许SSL提供认证功能－－保证用户所请求连接的服务器身份正确无误。在信用卡号或PIN号码等机密信息被发送出去前让用户确切知道通讯的另一端的身份是毫无疑问的重要的。很明显的，SSL技术提供了有效的认证。然而大多数用户并未能正确意识到通过SSL进行安全连接的必需性。除非越来越多的用户了解SSL和安全站点的基本知识，否则SSL仍不足以成为保护用户网络连接的必需技术。除非用户能够充分意识到访问站点时应该注意安全连接标识，否则现有的安全技术仍不能称为真正有效。
目前几乎所有处理具有敏感度的资料，财务资料或者要求身分认证的网站都会使用SSL加密技术（当你看到https在你的网页浏览器上的URL出现时，你就是正在使用具有SSL保护的网页服务器。）。在这里我把SSL比喻成是一种在浏览器跟网络服务器之间“受密码保护的导管”（cryptographic pipe），也就是我们常说的安全通道。这个安全通道把使用者以及网站之间往返的资料加密起来。但是SSL并不会消除或者减弱网站所将受到的威胁性。在SSL这个安全通道的背后，一般没有受到SSL防护的网站一样具备了相同的网页服务器程序，同样的网页应用程序，CGI的script以及后端数据库。目前普遍存在这么一个错误的认识：很多系统管理者却认为，受到SSL防护的网页服务器自动就变得安全了。其实不然，事实上，受到SSL防护的网页服务器同样还是会受到与一般其它网站服务器遭受攻击的威胁，受到SSL防护的网页服务器不一定是万无一失的。
||||||二、SSL的安全漏洞
虽然一个网站可能使用了SSL安全技术，但这并不是说在该网站中正在输入和以后输入的数据也是安全的。所有人都应该意识到SSL提供的仅仅是电子商务整体安全中的一小部份解决方案。SSL在网站上的使用可能会造成管理员对其站点安全性的某些错觉。使用了SSL的网站所可能受到的攻击和其它服务器并无任何区别，同样应该留意各方面的安全性。简言之，加密和数字证书，SSL的主要组成，从来都无法保护服务器－－它们仅仅可以保护该服务器所收发的数据。SSL常见安全问题下面三种：
1、攻击证书
类似Verisign之类的公共CA机构并不总是可靠的，系统管理员经常犯的错误是过于信任Verisign等的公共CA机构。例如，如果Verisign发放一个证书说我是“某某某”，系统管理员很可能就会相信“我是某某某”。但是，对于用户的证书，公共CA机构可能不象对网站数字证书那样重视和关心其准确性。例如，Verisign发放了一个“keyman"组织的证书，而我是其中一员“JACK”。当一个网站要求认证用户身份时，我们提交了“JACK”的证书。你可能会对其返回的结果大吃一惊的。更为严重的是，由于微软公司的IIS服务器提供了“客户端证书映射”（Client Certificate Mapping）功能，用于将客户端提交证书中的名字映射到NT系统的用户帐号，在这种情况下我们就能够获得该主机的系统管理员特权！
如果黑客不能利用上面的非法的证书突破服务器，他们可以尝试暴力攻击（brute-force attack）。虽然暴力攻击证书比暴力攻击口令更为困难，但仍然是一种攻击方法。要暴力攻击客户端认证，黑客编辑一个可能的用户名字列表，然后为每一个名字向CA机构申请证书。每一个证书都用于尝试获取访问权限。用户名的选择越好，其中一个证书被认可的可能性就越高。暴力攻击证书的方便之处在于它仅需要猜测一个有效的用户名，而不是猜测用户名和口令。
2、窃取证书
除上面的方法外，黑客还可能窃取有效的证书及相应的私有密钥。最简单的方法是利用特洛伊木马。这种攻击几乎可使客户端证书形同虚设。它攻击的是证书的一个根本性弱点：私有密钥－－整个安全系统的核心－－经常保存在不安全的地方。对付这些攻击的唯一有效方法或许是将证书保存到智能卡或令牌之类的设备中。
3、安全盲点
系统管理员没办法使用现有的安全漏洞扫描（vulnerability scanners）或网络入侵侦测系统（intrusion detection systems，IDS），来审查或监控网络上的SSL交易。网络入侵侦测系统是通过监测网络传输来找寻没有经过认证的活动。任何符合已知的攻击模式或者并未经过政策上授权的网络活动都被标起来以供系统管理者检视。而要让IDS能够发生作用，IDS必须能够检视所有的网络流量信息，但是SSL的加密技术却使得通过http 传输的信息无法让IDS辨认。再者，虽然我们可以用最新的安全扫描软件审查一般的网页服务器来寻找已知的安全盲点，这种扫描软件并不会检查经过SSL保护的服务器。受到SSL保护的网页服务器的确拥有与一般服务器同样的安全盲点，可是也许是因为建立SSL连结所需要的时间以及困难度，安全漏洞扫描软件并不会审查受到SSL 保护的网页服务器。没有网络监测系统再加上没有安全漏洞审查，使得最重要的服务器反而成为受到最少防护的服务器。
||||||三、解决方法
至于如何保护证书的安全，你可以采用IDS（Intrusion Detection System），它是一种用于监测攻击服务器企图的技术和方法。典型的IDS监视网络通讯，并将其与保存在数据库中的已知攻击“特征”或方法比较。如果发现攻击，IDS可以提醒系统管理员、截断连接或甚至实施反攻击等。问题在于如果网络通讯是加密的，IDS将无法监视。这反而可能会使攻击更为轻松。假设在一个典型的被防火墙和IDS防护的DMZ环境中，黑客能轻松地探测被SSL保护的网站，因为SSL对数据的加密使得IDS无法正常监测攻击。通常一台单一的网站服务器会同时使用SSL和普通的TCP协议。由于黑客攻击的服务器而不是网络连接，他们可以选择任意一种途径。通过SSL途径，黑客知道SSL加密为他们带来的好处，这样更容易避开IDS系统的监测。在这里我主要介绍的是如何解决系统管理员没办法使用现有的安全漏洞扫描或网络入侵侦测系统而存在的网页服务器安全盲点的情况，目前解决这个困扰的常用方法大致有以下三种：
1、通过Proxy代理服务器的SSL
我们可以在一个SSL Proxy代理程序上使用这项资料审查技术。SSL Proxy是一个在连接埠80上接收纯文字的 HTTP通讯请求的软件，它会将这些请求通过经由SSL加密过的连结，转寄到目标网站。我们在连接埠80开一个听取的socket，通过上述的OpenSSL指令，将所有进入这个proxy的数据传送出去。这在Unix上，只是个小技巧：你只须将以下的指令加到你们的/etc/inetd.conf档案里面，这个inetd.conf包含所有inetd所提供的网络服务的设定：
www stream tcp nowait root /usr/sbin/tcpd /usr/local/bin/ssl_proxy.sh
而/usr/local/bin/ssl_proxy.sh的内容则如下所述：
#!/bin/sh
/usr/local/ssl/bin/openssl s_client -no_tls1 -quiet -connect 168.172.100.10:443 2>/dev/null
168.172.100.10是SSL防护下的网站的地址所在。其中“-no_tls1”以及“-quiet”选项将SSL交谈（handshake）的标题显示关掉，并且也删除了SSL对于尚未经过授权的网站认证所发出的警告。
如果你要想测试你的proxy连结，那么你只要以纯文字的方式，在执行SSL proxy的系统的连接端口80建立联机。这个proxy会使用SSL来转寄接收的请求到目标网站。
$ telnet 182.197.110.180 GET / HTTP/1.0
在这里，服务器正在182.197.110.1的地址执行SSL proxy机制，而真正受到SSL保护的地址则是在 168.172.100.10。通过这个SSL proxy机制，我们只要将安全扫描软件指向proxy的IP地址，就可以使用它来审查一个SSL服务器。
在这里，你可以使用whisker程序（网址：http://www.wiretrip.net/rfp/p/doc.asp?id=21&iface=2）来审查 SSL防护的网站服务器。Whisker是一个由Rain Forest Puppy写出来的script，可以用来检查已知的比较容易受到入侵的网站应用程序以及CGI script。
||||||./whisker.pl -h 168.172.100.2
-- whisker / v1.3.0a / rain forest puppy / ADM / wiretrip --
- Loaded script database of 1691 lines
= - = - = - = - = - =
= Host: 168.172.100.2
= Server: Microsoft-IIS/4.0
+ 404 Object Not Found: GET /cfdocs/
+ 404 Object Not Found: GET /cfide/Administrator/startstop.html
+ 404 Object Not Found: GET /cfappman/index.cfm
+ 404 Object Not Found: GET /cgi-bin/
+ 403 Access Forbidden: HEAD /scripts/
+ 403 Access Forbidden: HEAD /scripts/cpshost.dll
+ 404 Object Not Found: HEAD /samples/search/queryhit.htm
+ 404 Object Not Found: HEAD /adsamples/config/site.csc
+ 403 Access Forbidden: HEAD /scripts/counter.exe
+ 403 Access Forbidden: HEAD /scripts/samples/
以上情况是在182.197.110.1上执行whisker，然后whisker使用SSL将所有的HTTP请求转寄到168.172.100.10。
SSL proxy的观念已经存在一阵子了。目前有一个名为sslproxy.c的程序可以执行以上的功能（网址：http://www.obdev.at/Products/sslproxy.html）。另外还有一个最近才出来，执行SSL proxy还有它额外功能的工具程序，叫做stunnel（http://www.stunnel.org/），是由Brian Hatch开发的。然而，因为使用命令列模式操作OpenSSL软件相对来说比较简单的，所以我将在下面介绍这种方式。
2、OpenSSL
OpenSSL（相关资料网址：http://www.openssl.org/）包含了一套程序以及函式库，提供前端使用者SSL功能，并且允许软件工程师将SSL模块与他们的程序结合。在众多由SSL提供的产品里面，最能够用来让我们在这里讨论的是命令列模式的（command-line）SSL客户端以及伺服端工具软件。OpenSSL程序是一个指令列接口的程序，它是用来以手动的方式起始SSL连结。OpenSSL让你重新导引与其它程序之间的资料输入以及输出。
使用普遍可得的安全扫描软件来审查SSL服务器在研究技术文件时，我们在Apache提供给OpenSSL的接口模块mod_ssl(相关资料网址：http://www.modssl.org/)读到了一些有趣的信息。其中有一段常见问题讨论到有关测试在SSL保护下的网站服务器。你可以利用Telnet连到网页服务器第80号连接埠，然后下达如下的http get指令，从网页服务器取得网页：
||||||因为SSL通联必须要经过一个安全的连接埠，而在这里我们使用的是没有安全防护的连接埠80，因此，这个技巧在HTTPS通讯协议上是行不通的。然而，如果我们用的是OpenSSL程序，我们就可以在SSL连接上做同样的一件事情。
下面是OpenSSL连结的细节
openssl：s_client -connect www.ramsec.com:443
CONNECTED(00000003)
depth=0 /C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
i:/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
---
||||||Server certificate
-----BEGIN CERTIFICATE-----
MIIClTCCAgICEGJTOhcnU+VNQDZ7fqS1K8UwDQYJKoZIhvcNAQEEBQAwXzELMAkG
A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYD
VQQLEyVTZWN1cmUgU2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAw
MDEyNDAwMDAwMFoXDTAxMDEyMzIzNTk1OVowgbsxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpXYXNoaW5ndG9uMRMwEQYDVQQHFApOZXcgQ2FzdGxlMSMwIQYDVQQKFBpS
YW1wYXJ0IFNlY3VyaXR5IEdyb3VwIExMQzEMMAoGA1UECxQDV2ViMTMwMQYDVQQL
FCpUZXJtcyBvZiB1c2UgYXQgd3d3LnZlcmlzaWduLmNvbS9SUEEgKGMpOTkxGjAY
BgNVBAMUEXNlY3VyZS5yYW1zZWMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQD+0K9xpPTh79iWWXc5JmTeJrg5YNdmwP5EwfKSPqOk2E8QSRNk8+Huv7h7
h636cDbmIh+J+VuRO5x5YP8apUCcqRfIMmQevTFzaIyCf3Mwm/OKNTs+4tqA5kjT
SedbBUGaaY2A1VcK0uby1djc+oX8XoCMoRWy+VGBkBrLK51t2QIDAQABMA0GCSqG
SIb3DQEBBAUAA34AhT7v59KwTvldIHJV7U4Doca+/wQ6ivbyd35K9hC/wxwE/jnO
oBXFKaJvV6mHk9hVz37CtLauUGYIZb3x7Cw6GajhhPicLi0l6ndH4VF9C4tbUb4t
2yw/6Jy9i+TfsO/Ldcu4KV0688vfORWm663+6miLYHKGNqFMaR3QaXc=
-----END CERTIFICATE-----
subject=/C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
issuer=/C=US/O=RSA Data Security, Inc./OU=Secure Server
Certification
Authority
---
No client certificate CA names sent
---
SSL handshake has read 801 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
||||||Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID:
020000001E9F693D9F9D5FF87E6DF24A0BAFC85391992415991DF3AB74522BCB
Session-ID-ctx:
Master-Key:
08FD7A5E6D058A45D0855AD359C0428F3BB5A685E6D74DFB9CDAB6D6A2ED7D53
E97147155DC7B9C61B946BE6
Key-Arg : None
Start Time: 963184785
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
GET / HTTP/1.0
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Content-Location: http://216.182.36.154/index.html
Date: Mon, 10 Jul 2000 11:41:25 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Thu, 23 Mar 2000 01:41:15 GMT
ETag: "305fc7e06894bf1:38441"
Content-Length: 886
通过上面OpenSSL这项技术，我们就可以直接传送资料到有SSL保护的网站，然后用我们一般审查任何HTTP服务器安全性的方式来审查这个SSL网页服务器。
3、监测SSL服务器
现在的网络IDS只能够监视纯文字资料内容，所以我们只能够有两项选择：监视服务器上的SSL连结或者将整个连结资料转为纯文字格式。大部分的网页服务器都有一些基本的日志纪录功能。例如：Microsoft的IIS Web server有内建的日志制作功能，使用的是W3svc1格式，它可以侦测到很多一般的网络攻击状况。我通过前述的SSL proxy针对Windows NT 4.0上具备有SSL防护的IIS服务器，来作示范性的攻击。我们用的是由Rain Forest Puppy发现的一般性常见的msadc安全穿透技术。我们的IIS服务器在C:\WINNT\system32\LogFiles 的目录下，记载了以下的日志：
12:25:45 10.0.0.1 GET /msadc/msadcs.dll 200
12:25:48 10.0.0.1 POST / msadc/msadcs.dll 200
||||||然而，因为这些日志文件通常是存在网页服务器上面，因此，一个成功的攻击事件表示黑客很可能已经对日志文件下了手脚了。此外，安全管理员必须每天检查服务器上的日志文件（另外还有IDS，防火墙等等），这实在不是个最佳的解决方案。
除了使用主机日志文件的以外，另一个方式是将SSL连结转换成纯文字格式。如此一来网络的IDS就能够监视资料往来。有几种产品提供这项功能，不过他们主要是为了要提升数据处理效能，而不是为了网络安全的理由。建立以及维护SSL连结，必须耗用相当的CPU时间，如此一来会减损网页服务器的效能。市面上有几家厂商提供“电子商务加速器”，用来将与SSL交涉的工作移到不同的装置或处理器。你可以将IDS置放于加速器跟网页服务器之间，以监控纯文字格式的网络交通。用这种方式监控的话，有一个问题。那就是你必须有至少一个网络区隔（network segment）。这个网络区隔必须是安全的，而且与其它的网络装置分开来。
四、结论
总的来说SSL仍然不失为一套全面完善的安全策略中有效的组成元素。然而，与网络安全的其它工具软件一样，仅使用单一的防护软件都是无效的。对SSL的过高评价有可能带来安全风险。它仅是网络安全工具的一种，必须和其它网络安全工具紧密结合，方能构造出全面、完善、安全可靠的网络。最后有两件重要的事情是你必须牢记在心的，首先，SSL并不能够防护你的网站安全。它仅仅防护使用者的网页服务器以及目标网站之间的点对点数据链路，网页服务器跟后端的网页应用软件，仍旧会受到跟一般没有SSL防护的网站同样的攻击威胁；第二点，虽然SSL会使网络黑客很难用目前已知的攻击模式直接攻击SSL防护网站，不过，这些防卫仍旧是有可能用诸如SSL proxy等工具来加以突破，然而，相同的技术却也可以被用来监视以及审查系统的安全漏洞。
