使用帶有 SSL (HTTPS) 的 Boost-Beast (Asio) http 客戶端

Question

我是 SSL 和 Boost-Beast 庫以及 C++ 的新手，但這是另一回事。 我有一個關於在 Beast 中使用 HTTPS (SSL) 的問題。 我將使用該庫連接到 REST 服務並將 JSON 發布到我不控制證書、API 等的服務器。

它有點工作。 問題是我不清楚它是如何工作的。 在 Beast 附帶的示例中，它被引用到一個文件example/common/root_certificates.hpp ，其中它是兩個 base64 格式或類似格式的證書。

當我嘗試這個例子時，我讓它可以使用 POST 一個 JSON 字符串到服務器，我們稱之為“exampleserver.com”。 連接到端口 80 和 443。即使我注釋掉了它調用根證書函數的行， load_root_certificates(ctx); . 沒有出現握手或其他任何錯誤。 並且服務器響應正確。

那么，我的問題是：

1) Beast 庫是從exampleserver.com獲得證書還是我已經安裝了它，這就是它工作的原因？ 如果是這樣，當它到期時會發生什么？ 我是否必須在使用我的應用程序的每個客戶端上重新安裝一個新的？ 我寧願在我的代碼中沒有任何硬編碼證書來檢查它。 證書說DigiCert Global Root CA -> DigiCert SHA2 Secure Server CA是瀏覽器附帶的標准證書嗎？

2）它是否只是在端口 443 上使用了普通 HTTP（無 SSL）？ 不知道這是否可能......

Answer 1

即使我注釋掉了它調用根證書功能的行，“load_root_certificates(ctx);”

在這種情況下，openssl 使用系統范圍的默認證書存儲（例如在 linux /etc/ssl/certs 上），因此將信任“通常”權限（就像您的瀏覽器一樣）。

1) Beast 庫是從“exampleserver.com”獲得證書還是我已經安裝了它，這就是它工作的原因？

是的。

如果是這樣，當它到期時會發生什么？

它將無法驗證。 測試它，如果你想： https : //expired.badssl.com/

該站點有許多出色的 SSL 測試（ https://badssl.com ）

證書上寫着“DigiCert Global Root CA -> DigiCert SHA2 Secure Server CA”是瀏覽器附帶的標准證書嗎？

瀏覽器的可信證書不相關（您沒有使用瀏覽器）。 但是，您可以看到 openssl（見上文），或者您可以使用類似的東西進行測試

openssl s_client  -connect exampleserver.com:443 -verify -showcerts 

打印出類似於

verify depth is 0
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = US, ST = TX, L = Houston, O = "cPanel, Inc.", CN = "cPanel, Inc. Certification Authority"
verify return:1
depth=0 CN = tradingfleet.com
verify return:1
---
Certificate chain
 0 s:/CN=tradingfleet.com
   i:/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
 1 s:/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFUjCCBDqgAwIBAgIQPI9I0oyjgNMrudesOYyqgDANBgkqhkiG9w0BAQsFADBy
MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxEDAOBgNVBAcTB0hvdXN0b24xFTAT
BgNVBAoTDGNQYW5lbCwgSW5jLjEtMCsGA1UEAxMkY1BhbmVsLCBJbmMuIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MDIxODAwMDAwMFoXDTE4MDUxOTIzNTk1
OVowGzEZMBcGA1UEAxMQdHJhZGluZ2ZsZWV0LmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBANe5zu81biDwwIloBMFHWc2OvoiGTNBr2aya8auWrzRm
rmbOfugZOaIAms79jnINCQ7jy0Qk2xwblgCifCg7y/UfSXvv7IWUWcEDywsAoyz/
sUc9myvQbot+kD1DaxVoyN85LnDehaYF5+myDznJISQe1ei01n/aIF8gwOz4k3Gn
R07Zh0sDRBjIiRsAL6ZljrPRk47cul2+8pD0qNJHHN0QX6hz/KPOugTiivI1+ymo
onSeeN29oh5oTtCHP2yj9+RNsCNcPAnbDawy0RAgFi2W5GyHiIo/NkUxBXN8tQxH
2xrPnY+MQJHUcKXJd//DTX6tWoQqo4xisN6Q9iZ3+R8CAwEAAaOCAjkwggI1MB8G
A1UdIwQYMBaAFH4DWmVBa6d+CuG4nQjqHY4dasdlMB0GA1UdDgQWBBQKTFmhmBNx
pS9uBbXjqE1ZjCOiFjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwTwYDVR0gBEgwRjA6BgsrBgEEAbIx
AQICNDArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8uY29tL0NQ
UzAIBgZngQwBAgEwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9j
YS5jb20vY1BhbmVsSW5jQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwfQYIKwYB
BQUHAQEEcTBvMEcGCCsGAQUFBzAChjtodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9j
UGFuZWxJbmNDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNydDAkBggrBgEFBQcwAYYY
aHR0cDovL29jc3AuY29tb2RvY2EuY29tMIGXBgNVHREEgY8wgYyCEHRyYWRpbmdm
bGVldC5jb22CF2NwYW5lbC50cmFkaW5nZmxlZXQuY29tghVtYWlsLnRyYWRpbmdm
bGVldC5jb22CGHdlYmRpc2sudHJhZGluZ2ZsZWV0LmNvbYIYd2VibWFpbC50cmFk
aW5nZmxlZXQuY29tghR3d3cudHJhZGluZ2ZsZWV0LmNvbTANBgkqhkiG9w0BAQsF
AAOCAQEAPFIZv1oHXm79+uoLnP9Sya2qEghOn/uPpNtappgUSrh2Pb0MueX84C0P
4HRS4yHRO1TD9ZOfCuPsguzXhl+RUB7Asl2iAhwthoZGMLhv6uaUnAUHZbpdkJY3
r/quuWHXDGNoe2quAOxGLPDO7WMvrDh1hFi7x7AGshkRSZ4DREBnCS7iprKzKL6H
BaNqtAlWgoXcSSg1RpnbU2o4bWIv8mZG0ATr7Cc8VSf04SjBLZnLTNeqo6Z+ALQ3
yrFsAytim6857FB231V5NEvLh+iZjSOuBG9xv+4Nw46bVz9z8QxB3czAodrDGXbB
lgH1s5f486lRq45dRn/hGY+DZjJXgg==
-----END CERTIFICATE-----
subject=/CN=tradingfleet.com
issuer=/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4988 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
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-AES256-GCM-SHA384
    Session-ID: 24CB439538212A23E0391887F856E369858AB6864B25DA5F1FD618550C41EB92
    Session-ID-ctx: 
    Master-Key: 1B8A3028923478527196B429D10F3584C5FA5DE4175C834CBBEF9EB19013FBFE58E7668CED9C0877E15F4F214A61F80C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - ca 83 5a 76 c2 51 7b c7-68 15 12 a7 cb c9 f5 35   ..Zv.Q{.h......5
    0010 - 0a dc c1 2a 90 fd 61 69-0a d9 89 09 f0 c4 b3 40   ...*..ai.......@
    0020 - 79 dc 97 8a c5 0d a1 67-85 5e b4 25 47 94 ed 23   y......g.^.%G..#
    0030 - 42 df b2 99 25 ec b1 fa-d7 3e 3e 24 37 ef 67 ef   B...%....>>$7.g.
    0040 - 56 f4 d2 57 cd 47 48 bd-d7 86 b1 2f b5 76 d6 db   V..W.GH..../.v..
    0050 - 12 9d 7a d3 94 b0 58 bf-c5 c4 3e 7d 05 98 75 1d   ..z...X...>}..u.
    0060 - 31 bc 9b 23 4f a7 ce 37-af 77 8a 96 89 20 20 64   1..#O..7.w...  d
    0070 - 3d bf de 25 b2 09 02 20-49 09 b5 57 a1 c3 75 ed   =..%... I..W..u.
    0080 - 97 ec 51 d2 46 f7 c6 b7-4a d8 b2 db 95 eb ac d6   ..Q.F...J.......
    0090 - be 76 14 80 ca 08 dc b7-b6 cb e9 c9 cc 8b 45 bd   .v............E.
    00a0 - d7 1d a7 88 9b a4 91 33-aa 23 fe 23 65 b8 e1 d9   .......3.#.#e...
    00b0 - 98 f6 55 1e 25 32 97 b5-22 ac d0 58 01 a6 42 60   ..U.%2.."..X..B`

    Start Time: 1522150150
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
^C

2）它是否只是在端口 443 上使用了普通的 http（沒有 SSL）？ 不知道這是否可能......

不，它沒有。

可能只提供了一個糟糕的服務器配置，但通常如果您的服務器從瀏覽器連接 https，則無法連接普通：

• https://askubuntu.com/questions/860511/is-it-possible-to-set-same-port-work-with-http-and-https
• 在奇怪的配置上： Nodejs HTTP 和 HTTPS 在同一端口上

Answer 2

正如 Vinnie Falco 所建議的，在文件example/common/root_certificates.hpp ，使用以下僅標頭庫https://github.com/djarek/certify

在您的代碼中添加以下包括

#include <boost/certify/extensions.hpp>
#include <boost/certify/https_verification.hpp>

並替換初始代碼：

    // This holds the root certificate used for verification
    load_root_certificates(ctx);

    // Verify the remote server's certificate
    ctx.set_verify_mode(ssl::verify_peer);

通過這個：

    ctx.set_verify_mode(ssl::context::verify_peer );
    boost::certify::enable_native_https_server_verification(ctx);

使用網站 badssl.com 和具有良好 ssl 證書的網站進行了快速測試。 它的工作就像一個魅力。

Answer 3

可能，你現在已經想通了。

我嘗試了相同的野獸示例（Boost 庫 1.70），並且必須對會話的構造函數進行以下更改（我在那里進行了更改，可能也可以在代碼的其他位置進行更改）：

    ws_.next_layer().set_verify_mode(boost::asio::ssl::verify_peer);
    ws_.next_layer().set_verify_callback(std::bind(&session::verify_certificate, this, _1, _2));

並添加了一個方法（我從 Asio 客戶端示例中按原樣復制了該方法）：

bool verify_certificate(bool pverified_ok, ssl::verify_context& ctx)
{
    char subject_name[256];
    X509 *cert = X509_STORE_CTX_get_current_cert(ctx.native_handle());
    X509_NAME_oneline(X509_get_subject_name(cert), subject_name, 256);
    std::cout << "Verifying " << subject_name << std::endl;

    return pverified_ok;
}

此更改導致驗證失敗（我已刪除硬編碼證書，因為我不想使用它們）。 回調有助於記錄服務器證書實際上正在被驗證。

就像 Asio 示例將 CA 證書添加到 ssl::context 例如

    boost::asio::ssl::context ctx(boost::asio::ssl::context::sslv23);
    ctx.load_verify_file("ca.pem"); // CA certificate

導致驗證通過。

您需要創建自簽名 CA 證書和由它簽名的服務器證書，並將其放置在服務器代碼中（同樣來自 Asio 示例）例如

    context_.use_certificate_chain_file("..\\sample-server1.pem");
    context_.use_private_key_file("..\\sample-server1-key.pem", boost::asio::ssl::context::pem);
    context_.use_tmp_dh_file("..\\dh2048.pem");