[译]OpenSSL Cookbook
记录个人学习过程吧，顺便翻译一下。另外，本文并不会包括原连接中的所有内容，仅包括个人在工作中会经常遇到的。
前言
由于协议特性和实现的复杂性，有时很难确定安全服务器的确切配置和特性。尽管存在许多用于此目的的工具，但通常很难确切知道它们是如何实现的，这有时会使完全信任它们的结果变得困难。尽管我花了很多年的时间测试安全服务器，并且能够使用好的工具，但当我真的想了解发生了什么时，我还是求助于使用OpenSSL和Wireshark。我不是说您应该在日常测试中使用OpenSSL；相反，您应该找到一个您信任的自动化工具。但是，当您真的需要确定某些事情时，唯一的方法就是用OpenSSL。
OpenSSL附带了一个客户端工具，您可以使用它连接到安全服务器。该工具类似于telnet或nc，从某种意义上说，它处理SSL/TLS层，但允许您完全控制接下来的层。
帮助信息
openssl帮助信息很丰富，需要慢慢消化。
# openssl -h openssl:Error: '-h' is an invalid command. Standard commands asn1parse ca ciphers cms crl crl2pkcs7 dgst dh dhparam dsa dsaparam ec ecparam enc engine errstr gendh gendsa genpkey genrsa nseq ocsp passwd pkcs12 pkcs7 pkcs8 pkey pkeyparam pkeyutl prime rand req rsa rsautl s_client s_server s_time sess_id smime speed spkac ts verify version x509 Message Digest commands (see the `dgst' command for more details) md2 md4 md5 rmd160 sha sha1 Cipher commands (see the `enc' command for more details) aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc aes-256-ecb base64 bf bf-cbc bf-cfb bf-ecb bf-ofb camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb camellia-256-cbc camellia-256-ecb cast cast-cbc cast5-cbc cast5-cfb cast5-ecb cast5-ofb des des-cbc des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb des-ofb des3 desx idea idea-cbc idea-cfb idea-ecb idea-ofb rc2 rc2-40-cbc rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb rc4 rc4-40 rc5 rc5-cbc rc5-cfb rc5-ecb rc5-ofb seed seed-cbc seed-cfb seed-ecb seed-ofb zlib
连接测试
要连接到服务器，需要提供主机名和端口。例如：
# openssl s_client -connect www.baidu.com:443
输出信息：
# openssl s_client -connect www.baidu.com:443 CONNECTED(00000003) depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA verify return:1 depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2 verify return:1 depth=0 C = CN, ST = beijing, L = beijing, OU = service operation department, O = "Beijing Baidu Netcom Science Technology Co., Ltd", CN = baidu.com verify return:1 --- Certificate chain 0 s:/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIIJrzCCCJegAwIBAgIMLO4ZPBiCeOo+Q3VzMA0GCSqGSIb3DQEBCwUAMGYxCzAJ BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH bG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g RzIwHhcNMTkwNTA5MDEyMjAyWhcNMjAwNjI1MDUzMTAyWjCBpzELMAkGA1UEBhMC Q04xEDAOBgNVBAgTB2JlaWppbmcxEDAOBgNVBAcTB2JlaWppbmcxJTAjBgNVBAsT HHNlcnZpY2Ugb3BlcmF0aW9uIGRlcGFydG1lbnQxOTA3BgNVBAoTMEJlaWppbmcg QmFpZHUgTmV0Y29tIFNjaWVuY2UgVGVjaG5vbG9neSBDby4sIEx0ZDESMBAGA1UE AxMJYmFpZHUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtMa/ 2lMgD+pA87hSF2Y7NgGNErSZDdObbBhTsRkIsPpzRz4NOnlieGEuVDxJfFbawL5h VdVCcGoQvvW9jWSWIQCTYwmHtxm6DiA+SchT7QKPRgHroQeTc7vt8bPJ4vvd8Dkq g630QZi8huq6dKim49DlxY6zC7LSrJF0Dv+AECM2YmUItIf1VwwlxwDY9ahduDNB pypf2/pwniG7rkIWZgdp/hwmKoEPq3Pj1lIgpG2obNRmSKRv8mgKxWWhTr8EekBD HNN1+3WsGdZKNQVuz9Vl0UTKawxYBMSFTx++LDLR8cYo+/kmNrVt+suWoqDQvPhR 3wdEvY9vZ8DUr9nNwwIDAQABo4IGGTCCBhUwDgYDVR0PAQH/BAQDAgWgMIGgBggr BgEFBQcBAQSBkzCBkDBNBggrBgEFBQcwAoZBaHR0cDovL3NlY3VyZS5nbG9iYWxz aWduLmNvbS9jYWNlcnQvZ3Nvcmdhbml6YXRpb252YWxzaGEyZzJyMS5jcnQwPwYI KwYBBQUHMAGGM2h0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9nc29yZ2FuaXph dGlvbnZhbHNoYTJnMjBWBgNVHSAETzBNMEEGCSsGAQQBoDIBFDA0MDIGCCsGAQUF BwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAIBgZn gQwBAgIwCQYDVR0TBAIwADBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzb3JnYW5pemF0aW9udmFsc2hhMmcyLmNybDCCA0kG A1UdEQSCA0AwggM8ggliYWlkdS5jb22CEmNsaWNrLmhtLmJhaWR1LmNvbYIQY20u cG9zLmJhaWR1LmNvbYIQbG9nLmhtLmJhaWR1LmNvbYIUdXBkYXRlLnBhbi5iYWlk dS5jb22CEHduLnBvcy5iYWlkdS5jb22CCCouOTEuY29tggsqLmFpcGFnZS5jboIM Ki5haXBhZ2UuY29tgg0qLmFwb2xsby5hdXRvggsqLmJhaWR1LmNvbYIOKi5iYWlk dWJjZS5jb22CEiouYmFpZHVjb250ZW50LmNvbYIOKi5iYWlkdXBjcy5jb22CESou YmFpZHVzdGF0aWMuY29tggwqLmJhaWZhZS5jb22CDiouYmFpZnViYW8uY29tgg8q LmJjZS5iYWlkdS5jb22CDSouYmNlaG9zdC5jb22CCyouYmRpbWcuY29tgg4qLmJk c3RhdGljLmNvbYINKi5iZHRqcmN2LmNvbYIRKi5iai5iYWlkdWJjZS5jb22CDSou Y2h1YW5rZS5jb22CCyouZGxuZWwuY29tggsqLmRsbmVsLm9yZ4ISKi5kdWVyb3Mu YmFpZHUuY29tghAqLmV5dW4uYmFpZHUuY29tghEqLmZhbnlpLmJhaWR1LmNvbYIR Ki5nei5iYWlkdWJjZS5jb22CEiouaGFvMTIzLmJhaWR1LmNvbYIMKi5oYW8xMjMu Y29tggwqLmhhbzIyMi5jb22CDiouaW0uYmFpZHUuY29tgg8qLm1hcC5iYWlkdS5j b22CDyoubWJkLmJhaWR1LmNvbYIMKi5taXBjZG4uY29tghAqLm5ld3MuYmFpZHUu Y29tggsqLm51b21pLmNvbYIQKi5zYWZlLmJhaWR1LmNvbYIOKi5zbWFydGFwcHMu Y26CESouc3NsMi5kdWFwcHMuY29tgg4qLnN1LmJhaWR1LmNvbYINKi50cnVzdGdv LmNvbYISKi54dWVzaHUuYmFpZHUuY29tggthcG9sbG8uYXV0b4IKYmFpZmFlLmNv bYIMYmFpZnViYW8uY29tggZkd3ouY26CD21jdC55Lm51b21pLmNvbYIMd3d3LmJh aWR1LmNughB3d3cuYmFpZHUuY29tLmNuMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr BgEFBQcDAjAdBgNVHQ4EFgQUdrXm1kn4+DbqdaltXk1VWzdc/ccwHwYDVR0jBBgw FoAUlt5h8b0cFilTHMDMfTuDAEDmGnwwggEEBgorBgEEAdZ5AgQCBIH1BIHyAPAA dgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAAAWqaLuGaAAAEAwBH MEUCICx7TcD5hUeKLQrAeTvWtLVm+Kr7glitIzb+Frymg5khAiEAwC/NnJkgy32R X9KLxhMQc7XBVAMzQZ+masUUk89pK2sAdgBvU3asMfAxGdiZAKRRFf93FRwR2QLB ACkGjbIImjfZEwAAAWqaLt5PAAAEAwBHMEUCIAMyaJ450OtfGWHbpxJpbyhEgQKl PMKjE9V+mCZfIBqgAiEAp4tis7C0RDLiEf9FjVURLDarKZNEyDRcznw1VzGuqxIw DQYJKoZIhvcNAQELBQADggEBAKq5zVKO3DZdR9SL8zIXBkaDYKMnBUkpsRtGbjj+ k/4JQ2zSoVgkEkK3q0H4Rwp9ZLV13FpFFLKkGGuctzuPs37SvcBySzUFrg0tGR9Q c3Ja35cYO9sq895EzmQtwR6EzHYkPjBnIyboT/cL9uxp139RqaBvuMQU4sBKSsQA XVdqyUHEJSsyGKpiqB5JgXMcgV9e+uSUMsNQbY6qzGxMUwz6j040eZ+lYMD4UHW4 oZ0B5qslIww7JAJAWCT/NAKLlGEQaC+2gOPQX0oKpwLSwJg+HegCyCdxJrKoh7bb nRBHS8ITYjTG0Dw5CTklj/6i9PP735snPfzQKOht3N0X0x8= -----END CERTIFICATE----- subject=/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 4265 bytes and written 415 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 2328E4C2957DA5FBAEEE5B3E6F6B0D2211E5F5DD16F13264B8DDF89F4A1E6D3E Session-ID-ctx: Master-Key: AB4C95789327147E8CA120FD72263C1CDD317F73D485C6BC6D80A0A282F7579FC8DCDBBCCA69C0089279899E7EE8F771 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket: 0000 - 75 c7 57 c0 16 bd 32 33-cd fc 26 e2 0d 46 75 09 u.W...23..&..Fu. 0010 - c8 7d d0 f1 04 be a8 46-da 3f 2c c5 ce 3a 8a c0 .}.....F.?,..:.. 0020 - 7f 06 fe d8 2c 03 30 c3-3c 78 92 8c da 5c dd 73 ....,.0.<x...\.s 0030 - 61 69 a2 16 32 ad aa f1-8e 27 43 63 33 55 df de ai..2....'Cc3U.. 0040 - b6 23 15 96 ec 39 17 66-c6 ee 88 8a 7a 9b b5 bb .#...9.f....z... 0050 - 85 03 eb a8 a3 27 eb 0b-c3 e9 ef 64 5c 28 9a 3f .....'.....d\(.? 0060 - fe 74 f3 31 13 fd a2 dd-df 4c 72 b0 9b d6 f5 b6 .t.1.....Lr..... 0070 - 99 de dc 0d a1 d8 af 71-59 a3 b9 16 dd 99 54 1f .......qY.....T. 0080 - 0f 9a 74 29 e9 94 89 40-4a f2 fd cd 99 d1 6e 8a ..t)...@J.....n. 0090 - 70 21 46 0f b7 a9 17 e3-8d 14 d6 31 48 15 1a 56 p!F........1H..V Start Time: 1561509736 Timeout : 300 (sec) Verify return code: 0 (ok) --- ... # 等待输入
一旦您输入命令，您将看到大量的诊断输出（稍后会了解更多信息），然后有机会输入您想要的任何类型。
HTTP请求
因为我们正在与HTTP服务器通信，所以最明智的做法是提交一个HTTP请求。在下面的示例中，我使用head请求，因为它指示服务器不要发送响应主体：
--- HEAD / HTTP/1.0 Host: www.baidu.com HTTP/1.0 200 OK Accept-Ranges: bytes Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform Content-Length: 277 Content-Type: text/html Date: Wed, 26 Jun 2019 00:45:21 GMT Etag: "575e1f8a-115" Last-Modified: Mon, 13 Jun 2016 02:50:50 GMT Pragma: no-cache Server: bfe/1.0.8.18 closed
现在我们知道了TLS通信层正在工作：我们通过HTTP服务器，提交了一个请求，并收到了一个响应。
服务器端证书
让我们回到诊断输出。前几行将显示有关服务器证书的信息：
CONNECTED(00000003) depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA verify return:1 depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2 verify return:1 depth=0 C = CN, ST = beijing, L = beijing, OU = service operation department, O = "Beijing Baidu Netcom Science Technology Co., Ltd", CN = baidu.com verify return:1 ---
在我的系统上（可能在您的系统上），s_client不会获取默认的可信证书；它会抱怨证书链中存在自签名证书。在大多数情况下，您不关心证书验证；但如果这样做，则需要将s_client指向受信任的证书，如下所示：
此处就不展示了...
输出中的下一部分列出了服务器按交付顺序提供的所有证书：
Certificate chain 0 s:/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA --- Server certificate ... # 详细内容请查看上述折叠的部分
对于每个证书，第一行显示主题，第二行显示颁发者信息。
当您需要确切地查看发送的证书时，此部分非常有用；浏览器证书查看器通常会显示重建的证书链，这些证书链与显示的证书链几乎完全不同。要确定链是否名义上正确，您可能希望验证主题和发行者是否匹配。您从顶部的叶子（Web服务器）证书开始，然后沿着列表向下走，将当前证书的颁发者与下一个证书的主题匹配。您看到的最后一个颁发者可以指向不在链中的某个根证书，或者如果包含自签名根，则可以指向自身。
输出中的下一项是服务器证书；它包含大量文本，但为了简洁起见，我将删除其中的大部分内容：（详细请查看上述折叠的部分）
Server certificate -----BEGIN CERTIFICATE----- MIIJrzCCCJegAwIBAgIMLO4ZPBiCeOo+Q3VzMA0GCSqGSIb3DQEBCwUAMGYxCzAJ BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH ... nRBHS8ITYjTG0Dw5CTklj/6i9PP735snPfzQKOht3N0X0x8= -----END CERTIFICATE----- subject=/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 ---
[注]每当您在主题中看到一个由数字组成的长字符串而不是名称时，这意味着OpenSSL不知道所讨论的对象标识符（OID）。OID是全局唯一且不含糊的标识符，用于引用“事物”。例如，在先前的输出中，OID 1.3.6.1.4.1.311.60.2.1.3应替换为司法管辖区FindCorporationCountryName，后者用于扩展验证（EV）证书。
如果您想更好地查看证书，首先需要从输出中复制它，并将其存储在单独的文件中。我将在下一节讨论这个问题。
TLS连接信息
以下是有关TLS连接的大量信息，其中大部分都是不言而喻的：
--- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 4265 bytes and written 415 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 61D5849D3ADE5DD8CD2B4C4083EEAE7BE55FD3014AA295B163863D088065F4E2 Session-ID-ctx: Master-Key: BB2F16BADCE13227EA40E8F2B23C25B49A7EBF32ACA6B020E8FA9BD7A2CE48733A590CAF0527861A5A78540B09185865 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket: 0000 - 75 c7 57 c0 16 bd 32 33-cd fc 26 e2 0d 46 75 09 u.W...23..&..Fu. 0010 - f9 29 96 be 01 ff 90 23-59 28 6e 40 c2 b1 1e 6c .).....#Y(n@...l 0020 - 33 d1 e2 5d f6 58 44 c9-a1 9c 3a 9e 82 56 16 06 3..].XD...:..V.. 0030 - 32 a2 dc 28 e4 7d 33 9c-9c 38 d9 a2 a3 cf b2 1d 2..(.}3..8...... 0040 - fe 7f 93 da 9d 10 ba 35-c8 09 43 22 3e a6 bc 18 .......5..C">... 0050 - 44 76 34 a0 fa 33 52 a2-bb 40 c2 03 f8 06 78 08 Dv4..3R..@....x. 0060 - dd aa 00 26 d8 71 1a ad-86 33 ec 06 13 46 39 a6 ...&.q...3...F9. 0070 - 1b f1 31 39 6a f7 e0 3c-5f cc 5a dd ee d8 64 3d ..19j..<_.Z...d= 0080 - 8e 8f ac 7d 1b 15 df d8-ff 99 8b 4c 91 d0 db 75 ...}.......L...u 0090 - 5d 39 46 b8 6d 6c 72 25-9b cc f4 97 87 81 b1 ab ]9F.mlr%........ Start Time: 1561509914 Timeout : 300 (sec) Verify return code: 0 (ok) ---
这里最重要的信息是协议版本（TLSv1.2）和使用的密码套件（ECDHE-RSA-AES128-GCM-SHA256）。您还可以确定服务器已向您颁发了会话ID和TLS会话票证（一种在不保持服务器维护状态的情况下恢复会话的方法），并且支持安全重新协商。一旦理解了所有这些输出包含的内容，您将很少看到它。
测试升级到SSL的协议
当使用HTTP时，TLS包裹住明文通信信道就成了HTTPS。有些协议开始是明文的，但随后升级到加密。如果你想测试这样一个协议，你必须告诉告诉Openssl是哪个协议，这样才能代你升级。提供使用启动开关-starttls。如：
# openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
目前支持的协议有：smtp、pop3、imap、ftp和xmpp。
使用不同的握手格式
有时，当您尝试使用openssl测试服务器时，即使您知道服务器支持TLS，您尝试与服务器通信也可能失败（例如，当您尝试使用浏览器时，您可以看到TLS正在工作）。出现这种情况的一个可能原因是服务器不支持旧的ssl 2握手。
因为openssl尝试协商它理解的所有协议，并且因为ssl 2只能使用旧的ssl2握手进行协商，所以它使用这个握手作为默认值。尽管它与一个非常老且不安全的协议版本相关联，但旧的握手格式在技术上并不是不安全的。它支持升级，这意味着可以协商更好的协议。但是，这种握手格式不支持在ssl 2之后设计的许多连接协商功能。
因此，如果某些东西不起作用，并且您不确定它到底是什么，那么您可以尝试强制OpenSSL使用新的握手格式。您可以通过禁用ssl 2来做到这一点：
# openssl s_client -connect www.baidu.com:443 -no_ssl2
实现相同效果的另一种方法是在命令行上指定所需的服务器名称：
# openssl s_client -connect ww.baidu.com:443 -servername www.baidu.com
为了指定服务器名称，OpenSSL需要使用更新握手格式的功能（该功能称为服务器名称指示[sni]），这将强制它放弃旧格式。
测试协议支持
默认情况下，s_client将尝试使用最佳协议与远程服务器对话，并在输出中报告协商的版本。
Protocol : TLSv1.2
如果您需要测试对特定协议版本的支持，您有两个选项。通过提供-ssl2、-ssl3、-tls1、-tls1_1或-tls1_2开关之一，可以显式选择要测试的协议。或者，您可以使用以下一个或多个选项来选择不想测试的协议：-无ssl2、-无ssl3、-无tls1、-无tls1_1或-无tls1_2。
[注]并非所有OpenSSL版本都支持所有协议版本。例如，旧版本的openssl将不支持tls 1.1和tls 1.2，新版本可能不支持旧协议，如ssl 2。
openssl支持的协议如下： -ssl3 - just use SSLv3 -tls1_2 - just use TLSv1.2 -tls1_1 - just use TLSv1.1 -tls1 - just use TLSv1 -dtls1 - just use DTLSv1
例如，以下是测试不支持特定协议版本的服务器时可能得到的输出:
$ openssl s_client -connect www.example.com:443 -tls1_2 CONNECTED(00000003) 140455015261856:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3↩ _pkt.c:340: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 7 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1339231204 Timeout : 7200 (sec) Verify return code: 0 (ok) ---
测试加密套件支持
如果您希望使用openssl来确定远程服务器是否支持特定的密码套件，则需要一些技巧。密码配置字符串用于选择要使用的套件，但如果仅指定一个套件并成功与服务器握手，则表明服务器支持该套件。如果握手失败，您知道不存在支持。
例如，要测试服务器是否支持RC4-SHA，请键入：
# openssl s_client -connect www.baidu.com:443 -cipher RC4-SHA
如果要确定特定服务器支持的所有套件，请首先调用openssl ciphers all以获取您的openssl版本支持的所有套件的列表。然后一个接一个地将它们提交到服务器，单独测试它们。我不是建议你手动操作；在这种情况下，一点点的自动化会有很长的路要走。实际上，在这种情况下，四处寻找一个好的工具可能是合适的。
然而，这种测试方式有一个缺点。您只能测试OpenSSL支持的套件。这曾经是一个更大的问题；在1.0版本之前，OpenSSL支持的套件数量要少得多（例如，在我的服务器上，0.9.8K版本为32个）。使用1.0.1分支的版本，您可以测试100多个套件，可能还可以测试大多数相关的套件。
没有单一的SSL/TLS库支持所有密码套件，这使得综合测试变得困难。对于SSL实验室，我使用部分握手来实现这一目的，使用一个定制的客户机来假装支持任意套件。实际上，它甚至不能协商一个套件，但是仅仅建议协商就足以让服务器告诉您它们是否支持一个套件。不仅可以用这种方式测试所有套件，而且还可以非常有效地进行测试。
a.查看所有的密码套件: # openssl ciphers -v b.所有openssl密码的详细列表，包括空密码： # openssl ciphers -v 'ALL:eNULL' c.包括除空和匿名dh之外的所有密码，然后按强度排序： # openssl ciphers -v 'ALL:!ADH:@STRENGTH' d.仅包括3DES密码，然后将RSA密码放在最后： # openssl ciphers -v 'ALL:!ADH:@STRENGTH'
测试会话重用
当与-reconnect开关结合使用时，可以使用s_client命令来测试会话重用。在此模式下，s_client将连接到目标服务器六次；它将在第一个连接上创建一个新会话，然后在随后的五个连接中尝试重用同一会话：
# echo | openssl s_client -connect example.com:443 -reconnect
前面的命令将产生大量的输出，其中大部分您不关心。关键部分是关于新会话和重用会话的信息。开始时应该只有一个新会话，由以下行指示：
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
接下来是五个会话重用，用如下行表示：
Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
大多数情况下，您不希望看到所有输出，并希望快速得到答案。您可以使用以下命令行获得它：
# echo | openssl s_client -connect example.com:443 -reconnect -no_ssl2 2> /dev/null | grep 'New\|Reuse' New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
命令解释如下：
-reconnect开关激活会话重用模式。 -no_sl2开关表示我们不希望尝试ssl2连接，这会将第一个连接的握手更改为ssl 3或更好的连接。旧的ssl 2握手格式不支持tls扩展，并且会干扰支持会话票证的服务器上的会话重用机制。 2>/dev/null部分隐藏stderr输出，这是您不关心的。 piped grep命令过滤掉其余输出，只显示您关系的部分。
测试重协商
S_client工具有几个功能，可以帮助您手动测试重新协商。首先，当您连接时，该工具将报告远程服务器是否支持安全重新协商。这是因为支持安全重新协商的服务器通过握手阶段交换的特殊TLS扩展来表示对它的支持。当支持可用时，输出可能如下所示：
--- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported
如果不支持安全重新协商，则输出将略有不同：
Secure Renegotiation IS NOT supported
即使服务器指示支持安全重新协商，您也可能希望测试它是否允许客户端启动重新协商。客户端发起的重新协商是一种在实践中不需要的协议功能（因为服务器总是可以在需要时启动重新协商），并使服务器更容易受到拒绝服务攻击。
要启动重新协商，您可以在一行上单独键入R字符。
--- R RENEGOTIATING depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert verify error:num=21:unable to verify the first certificate verify return:1
表示重协商成功。
重新协商时，服务器将再次向客户端发送其证书。您可以在输出中看到证书链的验证。之后的下一行继续使用主机请求头。查看Web服务器的响应可以证明支持重新协商。由于在不同版本的ssl/tls库中处理重新协商问题的方式不同，不支持重新协商的服务器可能会中断连接或保持连接打开，但拒绝继续进行协商（这通常会导致超时）。
不支持重新协商的服务器将直接拒绝连接上的第二次握手：
--- R RENEGOTIATING 140643029268384:error:14094153:SSL routines:ssl3_read_bytes:no renegotiation:s3_pkt.c:1481:
测试BEAST漏洞
Beast攻击利用了所有版本的ssl和tls 1.1之前的tls协议中存在的弱点。弱点影响到所有CBC套件以及客户机和服务器数据流；但是，Beast攻击仅针对客户机。大多数现代浏览器使用所谓的1/N-1分割作为一种解决方案来防止利用，但一些服务器继续在其端部署缓解措施，特别是如果它们的用户群依赖于较旧（和未修补）的浏览器。
因此，测试是否存在该漏洞仅需测试是否支持ssl协议和tls 1版本的加密协议即可。如下：
# openssl s_client -connect example.com:443 -ssl3 CONNECTED(00000003) ... SSL-Session: Protocol : SSLv3 ...
# openssl s_client -connect example.com:443 -tls1 CONNECTED(00000003) ... SSL-Session: Protocol : TLSv1 Cipher : ECDHE-RSA-AES256-SHA ...
可以看到是存在该漏洞的。
测试心脏滴血
暂未找到测试环境，后续补充。
确定Diffie-Hellman参数的强度
暂未找到测试环境，后续补充。
-------------------------------------------
个性签名：如果世上的事都按你说的道理走 世界就不是现在这样了！
如果觉得这篇文章对你有小小的帮助的话，记得在右下角点个“推荐”哦，博主在此感谢！
