記錄個人學習過程吧，順便翻譯一下。另外，本文並不會包括原連接中的所有內容，僅包括個人在工作中會經常遇到的。
前言
由於協議特性和實現的復雜性，有時很難確定安全服務器的確切配置和特性。盡管存在許多用於此目的的工具，但通常很難確切知道它們是如何實現的，這有時會使完全信任它們的結果變得困難。盡管我花了很多年的時間測試安全服務器，並且能夠使用好的工具，但當我真的想了解發生了什么時，我還是求助於使用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參數的強度
暫未找到測試環境，后續補充。