我认为会很容易，但是我很快在Ubuntu 12.04 LTS上遇到了最新的OpenSSL 1.0.1g问题：
openssl version -a
我希望看到完整版本，相反，我得到了：
OpenSSL 1.0.1 14 Mar 2012 built on: Tue Jun 4 07:26:06 UTC 2013 platform: [...]
令我不愉快的是，没有显示版本字母。没有f，没有g，只有“ 1.0.1”就这样。列出的日期也无助于发现（非）脆弱版本。
1.0.1（af）和1.0.1g之间的区别至关重要。
问题：
为什么可靠地检查版本，最好是跨发行版？
为什么不首先显示版本字母？除了Ubuntu 12.04 LTS之外，我无法在其他任何设备上进行测试。
其他人也在报告此行为。一些示例：
https://twitter.com/orblivion/status/453323034955223040
https://twitter.com/axiomsofchoice/status/453309436816535554
以下一些（特定于发行版的）建议正在出现：
Ubuntu和Debian：
apt-cache policy openssl和apt-cache policy libssl1.0.0。在此处将版本号与软件包进行比较：http://www.ubuntu.com/usn/usn-2165-1/ Fedora 20：
yum info openssl（感谢Twitter上的@znmeb）和yum info openssl-libs 检查是否仍驻留旧版本的OpenSSL：
并不完全可靠，但是可以尝试
lsof -n | grep ssl | grep DEL。请参阅Heartbleed：如何可靠且可移植地检查OpenSSL版本？关于为什么这可能对您不起作用的原因。事实证明，在Ubuntu和Debian上更新OpenSSL软件包并不总是足够的。您还应该更新libssl1.0.0软件包，然后-然后-检查
openssl version -a是否指示built on: Mon Apr 7 20:33:29 UTC 2014。#1 楼
根据您的OpenSSL版本显示的日期，似乎您看到的是完整版本。Open SSL 1.0.1于2012年3月14日发布。1.0.1a于4月发布。 2012年19月19日。
因此，我继续说
openssl version -a是显示系统上安装的完整版OpenSSL的正确，跨发行版的方式。它似乎适用于我可以访问的所有Linux发行版，也是help.ubuntu.com OpenSSL文档中建议的方法。 Ubuntu LTS 12.04随附了香草OpenSSL v1.0.1，该版本看起来像是缩写版本，因为它后面没有字母。话虽如此，但似乎有一个Ubuntu中的主要错误（或它们如何包装OpenSSL），因为
openssl version -a从2012年3月14日起继续返回原始1.0.1版本，无论OpenSSL是否已升级到任何较新版本。而且，就像大多数下雨时一样，它会倾泻。 Ubuntu并不是唯一将更新反向移植到OpenSSL（或其他软件包）的习惯的发行版，而是依靠每个人都可以识别的上游更新和版本编号来进行评估。在OpenSSL的情况下，字母版本号仅表示错误修复和安全更新，这似乎难以理解，但是我被告知，这可能是由于与OpenSSL一起打包的，经过FIPS验证的主要Linux发行版。由于围绕重新验证的要求会因任何更改而触发，甚至会因安全漏洞而进行更改，因此它是版本锁定的。例如，在Debian上，固定版本显示的版本号为
1.0.1e-2+deb7u5而不是1.0.1g的上游版本。结果，目前，没有可靠，可移植的方法来检查Linux发行版中的SSL版本，因为它们都使用自己的向后移植的补丁程序和具有不同版本编号方案的更新。您将必须为运行的每个Linux发行版查找固定的版本号，并对照该发行版的特定版本号检查已安装的OpenSSL版本，以确定您的服务器是否正在运行易受攻击的版本。
评论
我的安装是一个简单的Ubuntu 12.04 LTS，没有我自己编译的东西或从Ubuntu仓库以外的其他来源下载的任何东西。如果Ubuntu发行带有缩写版本号的OpenSSL，则openssl version -a不是可移植的方法（至少不能移植到Ubuntu）。我已经检查了apt-cache策略openssl，它的响应是：安装：1.0.1-4ubuntu5.12，这是Ubuntu刚刚为12.04 LTS发布的1.0.1g。我注销并重新登录后再进行检查。
–马丁（Martijn）
2014年4月8日，0：11
HopelessN00b，对于将修补程序向后移植而不是版本升级的策略并没有什么可疑的。这是确保平台稳定性的好方法，这在服务器环境中非常需要。像任何决定一样，它也会产生后果，用户需要注意；但是仅仅因为它打破了“我正在/正在运行foo x.y.z，因此我/不容易受到最新漏洞利用”的推理，这并没有什么不好。
– MadHatter
2014年4月8日在9:16
@towo存在版本号是有原因的。如果我们只是因为“ enterprisey”之类的东西而将上游版本号从窗口中移出，那为什么还要麻烦版本号呢？也可能只是开始用头衔命名我们的所有东西。我们可以将易受攻击的OpenSSL版本称为“神圣之心”，而将其称为“狡猾的凝结剂”。
–HopelessN00b
2014年4月8日下午13:36
@ HopelessN00b我认为您正在陷入“此问题已在X.Y.Z版中修复”陷阱的情况，它们没有遵循版本号，因为导入到最新版本中的所有内容都是错误和安全修复程序。如果他们修改了版本号，您还会期望附加功能。“我有OpenSSL v X.Y.Z，为什么我没有ECDHA ???? .. etc”。当您了解这仅是错误修正时，这才有意义。
– NickW
2014年4月8日14:54
@NickW @Jubal @MadHatter但是，使用OpenSSL的问题是：在OpenSSL 1.0.0发布之后，版本控制方案发生了变化。 Letter版本（例如1.0.1a）只能包含错误和安全修复程序，不能包含任何新功能。因此，放弃上游版本控制方案不会有任何收获。向后移植更新与使用更新版本本质上相同，因为该更新仅包含安全性和错误修复。它所做的只是使事情变得混乱，使我们无法跨Linux发行版可移植地检查OpenSSL版本。
–HopelessN00b
2014年4月8日在22:13
#2 楼
如果您想要真正跨平台的产品，请检查漏洞本身，而不要依赖版本号。您可能具有报告已知易受攻击的版本号的代码，但实际代码并不易受攻击。相反的-安静易受攻击的代码-可能会更糟！
许多捆绑了OpenSSL和OpenSSH之类的开源产品的供应商将选择性地将紧急修复程序改造为旧版本的代码，以便保持API的稳定性和可预测性。
，但是静默执行此操作（不添加自己的版本字符串后缀）的供应商冒着在漏洞扫描程序中触发误报的风险（并且令人困惑的用户）。因此，为了使其透明和可验证，一些供应商在主要软件包版本中附加了自己的字符串。 Debian（OpenSSL）和FreeBSD（在OpenSSH中，通过
VersionAddendum sshd_config指令）有时都可以这样做。不这样做的供应商可能会这样做，以最大程度地减少由于许多原因而导致损坏的可能性其他程序检查版本号的直接和间接方式。
所以它看起来像这样：
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"
$ openssl version
OpenSSL 1.0.1 14 Mar 2012
...已修补：
$ dpkg -l openssl | grep openssl
ii openssl 1.0.1-4ubuntu5.12 [truncated]
$ ls -la `which openssl`
-rwxr-xr-x 1 root root 513208 Apr 7 12:37 /usr/bin/openssl
$ md5sum /usr/bin/openssl
ea2a858ab594905beb8088c7c2b84748 /usr/bin/openssl
这样的事情在起作用，如果您不信任版本号，您的状况会更好。
评论
显然，检查版本并不像我希望的那样容易和透明。检查漏洞是跨平台的，但也更困难：您必须具有可靠的PoC或可方便地测试正在运行的特定漏洞软件服务。在这种情况下，一切都始于针对Apache和nginx的PoC。如果那时我仅将SMTP和SSL一起使用，并且想检查自己是否容易受到攻击，该怎么办？最终，我们将对大多数服务进行测试，但这可能需要一段时间。
–马丁（Martijn）
2014年4月9日在8:30
马丁（Martijn），这很公平。当测试不可用时，次要方法（例如，跟踪目标系统上受影响二进制文件的校验和）不是最佳选择，但可能足以完成工作……然后继续进行下一个工作。 :-)
–罗伊斯·威廉姆斯
2014年4月9日下午13:49
#3 楼
不幸的是，我不确定是否有一种跨平台的方法。正如我在博客文章中讨论的那样，升级到固定版本后，Ubuntu 12.04 REMAINS 1.0.1上显示的OpenSSL版本。仅适用于Ubuntu 12.04，您可以知道是否已更新满足以下所有条件：dpkg -s openssl | grep Version显示版本1.0.1-4ubuntu5.12或更高版本。dpkg -s libssl1.0.0 | grep Version显示版本1.0.1。 -4ubuntu5.12或更高版本。openssl version -a显示日期为2014年4月7日或更高版本。感谢@danny提供其他信息。
评论
好的，在这种情况下，我必须添加仅适用于Ubuntu 12.04 LTS的软件包版本1.0.1-4ubuntu5.12。如果您使用的是Ubuntu 12.10，则应该至少看到版本1.0.1c-3ubuntu2.7；如果您使用的是13.10，则应该至少看到版本1.0.1e-3ubuntu1.2（根据消息来源：ubuntu.com/） usn / usn-2165-1
–马丁（Martijn）
2014年4月8日在7:51
不幸的是，这是不够的。您还必须在ubuntu上显式升级libssl1.0.0。即使openssl的版本正确（如果Ubuntu 12.04为1.0.1-4ubuntu5.12），如果您看到的构建日期早于2014年4月7日，则您可能仍然容易受到攻击。
–丹尼
2014年4月8日在12:04
@danny您刚刚为我节省了很多工作。我试图弄清楚为什么在某些12.04系统上构建日期正确而在其他系统上却错误。你是救星！
– Schof
2014年4月8日在15:29
openssl版本-a可能不需要4月7日的生成日期，因为该修复程序将反向移植到较早的版本。
–帕特里克·詹姆斯·麦克杜格（Patrick James McDougle）
2014年4月10日在22:06
#4 楼
请尝试以下方法。它将从ssh链接到的加密库中提取所有字符串。它产生多于一行的输出，但如有必要，可以转换为1行。ldd `which ssh` | awk '/\// { print }' | grep crypto | xargs strings | grep OpenSSL
产生
OpenSSLDie
DSA_OpenSSL
...
MD4 part of OpenSSL 1.0.1f 6 Jan 2014
MD5 part of OpenSSL 1.0.1f 6 Jan 2014
...
etc
例如在Gentoo出现之前
[ebuild U ] dev-libs/openssl-1.0.1f [1.0.1c] USE="bindist (sse2) tls-heartbeat%* zlib -gmp -kerberos -rfc3779 -static-libs {-test} -vanilla" 4,404 kB
上面的命令结果在
...
OpenSSL 1.0.1c 10 May 2012
之后
/>
...
OpenSSL 1.0.1f 6 Jan 2014
还好，还是没有。
评论
我以为您即将提供一个好的解决方案，但是不幸的是，这不适用于Ubuntu 12.04 LTS上的加密库。 daccess-ods.un.org daccess-ods.un.org它会在2012年3月14日显示带有OpenSSL 1.0.1版本的所有字符串，与openssl版本-a相同。这是一个技巧，但在其他情况下也可能有效！
–马丁（Martijn）
2014年4月8日15:14
@Martijn好吧，这很不幸，但是它确实在ubuntu 12.10上起作用。奇怪的是，它将在12.04上错误地标识自己。有多个库吗？ ssh是否可能不使用最新的？
–waTeim
2014年4月8日15:59
我找不到其他任何openssl二进制文件或加密库。其他人建议，不同之处在于，在LTS 12.04上，Ubuntu将更改反向移植到1.0.1，而不升级版本。虽然12.10不是LTS，所以Ubuntu在那使用最新版本而不是backport。
–马丁（Martijn）
14年4月8日在16:14
#5 楼
这些脚本中的任何一个是否测试所有服务，还是仅测试HTTPS？ AFAIK，PostgreSQL很容易受到攻击，但这只是谣言，直到狂野的攻击浮出水面。有一个metasploit脚本可供使用。
https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a
您可以键入此字符（已通过GnuWin32 OpenSSL二进制版本1.0.1.6测试，日期为2014-01-14），或仅使用此脚本下方的注释中的脚本。更准确，更简单！
s_client -connect a23-75-248-141.deploy.static.akamaitechnologies.com:443 -debug -state
一旦连接了B型，您将在易受攻击的主机上看到并且不会断开连接：
B
HEARTBEATING
write to 0x801c17160 [0x801cbc003] (66 bytes => 66 (0x42))
0000 - 18 03 03 00 3d 8f 6f 3c-52 11 83 20 9c a2 c0 49 ....=.o 5 (0x5))
0000 - 18 03 03 00 3d ....=
read from 0x801c17160 [0x801cb7008] (61 bytes => 61 (0x3D))
0000 - 05 4d f5 c0 db 96 d1 f5-c7 07 e5 17 1f 3b 48 34 .M...........;H4
0010 - 6e 11 9d ba 10 0c 3a 34-eb 7b a5 7c c4 b6 c0 c0 n.....:4.{.|....
0020 - b0 75 0e fe b7 fa 9e 04-e9 4e 4a 7d 51 d3 11 1f .u.......NJ}Q...
0030 - e2 23 16 77 cb a6 e1 8e-77 84 2b f8 7f .#.w....w.+..
read R BLOCK
您将获得与该信号相似的心跳响应。
在已修补的主机上，您将看到与以下内容相似的响应，并且您将断开连接：
输入B
HEARTBEATING
write to 0x801818160 [0x8019d5803] (101 bytes => 101 (0x65))
0000 - 18 03 03 00 60 9c a3 1e-fc 3b 3f 1f 0e 3a fe 4c ....`....;?..:.L
0010 - a9 33 08 cc 3d 43 54 75-44 7d 2c 7b f3 47 b9 56 .3..=CTuD},{.G.V
0020 - 89 37 c1 43 1c 80 7b 87-66 ff cb 55 5f 8d 1a 95 .7.C..{.f..U_...
0030 - 1b 4c 65 14 21 a1 95 ac-7a 70 79 fc cc a0 cf 51 .Le.!...zpy....Q
0040 - 0f 7e c5 56 14 c8 37 c1-40 0b b8 cb 43 96 8a e6 .~.V..7.@...C...
0050 - 21 42 64 58 62 15 fb 51-82 e6 7f ef 21 1b 6f 87 !BdXb..Q....!.o.
0060 - b9 c2 04 c8 47 ....G
来源：
博客文章如何测试您的OpenSSL heartbleeds
还有以下这些工具：
https://github.com/titanous/heartbleeder
http：// filippo.io/Heartbleed/
https://github.com/musalbas/heartbleed-masstest
#6 楼
对于Ubuntu，您可以使用：aptitude show libssl1.0.0 | grep Version
并与http://www.ubuntu.com/usn/usn-2165-1/进行比较。重新启动（!!!）后，您可以使用
http://possible.lv/tools/hb进行检查。#7 楼
您最好升级到最新的OpenSSL OpenSSL 1.0.1j。http://blog.vincosolution.com/2014/10/upgrade-openssl-1-0-1j-debianubuntu.html
#8 楼
我在devcentral中找到了此脚本：openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe
将
example.com替换为要检查的服务器的名称或IP地址。将返回如果您的服务器正常，请
"safe"，否则请"server extension "heartbeat" (id=15)"。这不依赖于版本号，而是列出导致问题的服务器扩展名，因此它应该不受库版本的影响。
您正在运行
openssl s_client的计算机必须使用OpenSSL 1.0.1或更高版本才能起作用。评论
有用，但不会告诉您是否具有带有扩展名和修补程序的版本。
–mattdm
2014年4月8日在9:14
这确实是检查漏洞的好方法，并且是某些脚本所做的事情。它实际上不需要SSH访问。
– Stefan Lasiewski
2014年4月9日在3:38
BIG SCARY重要警告-为了在此计算机上运行openssl s_client，必须使用OpenSSL 1.0.1或更高版本。如果在运行0.9.8或1.0.0的计算机上运行此命令，即使对于易受攻击的服务器，它也将始终报告“安全”。
–voretaq7
2014年4月9日在5:52
奇。我正在运行一个受此错误影响的OpenSSL版本，但该字符串未出现在输出中...
–迈克尔
2014年4月9日17:30
@StefanLasiewski我更新了答案，并删除了“需要的ssh”部分
– egarcia
2014年4月9日在18:05
评论
至少要确保您使用的OpenSSL版本不是g，因为它显示的日期这适用于CentOS [root @ null〜]＃openssl版本-a OpenSSL 1.0.1e-fips 2013年2月11日
@PatoSáinz我已经检查了apt-cache策略openssl，它的响应是：安装：1.0.1-4ubuntu5.12，这是Ubuntu刚刚为12.04 LTS发布的1.0.1g。我注销并重新登录。我还能做其他验证吗？
我会指出这一点，以防万一，如果有用的话... OpenSSL 1.0.1附带的Ubuntu 12.04 LTS（香草）。
如果该构建日期正确，则不能使用比1.0.1e更新的“发行版本”代码，因为1.0.1f根据OpenSSL 1.0.1发行说明于2014年问世。当然，在正式的OpenSSL 1.0.1f发行版之前，个别行或节可能已反向移植到Ubuntu版本。而且构建日期可能还没有那么完全有用。