服务端支持heartbeat是存在heartbleed漏洞的必要条件，如果判断出某SSL端口不支持heartbeat，那基本上就可以排除风险了。
在SSL握手阶段，如果Client Hello里声明了客户端支持heartbeat，那么服务端会在Server Hello中声明自己是否也支持heartbeat。
在ssl-enum-ciphers.nse的基础上，改了一个nse脚本(http://pan.baidu.com/s/1pJ37kF5)，来根据上述特征判断SSL是否支持Heartbeat，该脚本在nmap 6.40下正常工作，貌似在5.x下会出错，一些定义有冲突。
[kussa@Kussa scripts]$ nmap --script ssl-heartbeat -p 443 passport.baidu.com
Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-10 09:59 CST
Nmap scan report for passport.baidu.com (61.135.185.194)
Host is up (0.0039s latency).
PORT STATE SERVICE
443/tcp open https
|_ssl-heartbeat: no[kussa@Kussa scripts]$ nmap --script ssl-heartbeat -p 443 login.taobao.com
Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-10 10:00 CST
Nmap scan report for login.taobao.com (42.156.184.11)
Host is up (0.030s latency).
PORT STATE SERVICE
443/tcp open https
|_ssl-heartbeat: yes
这个脚本可能对我们这样使用闭源方案比较多的公司比较有用，主要是为了借用nmap比较成熟的扫描机制，可以对公司做一次全网扫描，以排除潜在的风险，然后对扫描出的支持hearbeat的端口再做重点排查。
nmap --script ssl-heartbeat -Pn -p 443,993,995 -iL ip.txt -oN hb.txt
当然对脚本后面再加一个heartbeat的请求，就和那个python的PoC一样了……
PS(下面的说法没有经过严格验证):
1.现在的那个python的PoC貌似在处理有些服务器发来的Server Hello请求时会出错，服务端明明发回了Server Hello，但因为格式不兼容这个脚本而被忽略，就卡在等待Server Hello这一步了，根本没发heartbeat包。所以用那个PoC检测出有问题的一定是有问题，但检测没问题的不一定没问题。
2.这个脚本恰恰相反。
3.貌似无论是客户端还是服务端，微软的产品都不支持heartbeat，除非特别引入了OpenSSL的。
