boost asio ssl async_shutdown 总是以错误结束？

Question

我有一个在 boost 1.55 asio 中编写的小型 ssl 客户端，我想弄清楚为什么boost::asio::ssl::stream::async_shutdown()总是失败。 客户端与 boost 文档中的 ssl 客户端示例非常相似（几乎相同），因为它通过boost::asio::ip::tcp::resolver::async_resolve() -> boost::asio::ssl::stream::async_connect() -> boost::asio::ssl::stream::async_handshake()回调序列。 所有这些都按预期工作，并且async_handshake()回调得到一个完全清晰的boost::system::error_code 。

从async_handshake()回调中，我调用async_shutdown() （我不传输任何数据——这个对象更多地用于测试握手）：

void ClientCertificateFinder::handle_handshake(const boost::system::error_code& e)
{
    if ( !e )
    {
        m_socket.async_shutdown( boost::bind( &ClientCertificateFinder::handle_shutdown_after_success, 
            this, 
            boost::asio::placeholders::error ) );
    }
    else
    {
        m_handler( e, IssuerNameList() );
    }
}

然后调用handle_shutdown_after_success() ，但总是出错？ 错误是asio.misc value=2 ，即“文件结束”。 我已经在各种 ssl 服务器上尝试过这个，我似乎总是得到这个asio.misc错误。 这不是潜在的 openssl 错误向我表明我可能以某种方式滥用 asio ......？

有谁知道为什么会发生这种情况？ 我的印象是使用async_shutdown()关闭连接是正确的async_shutdown() ，但我想我可以调用boost::asio::ssl::stream.lowestlayer().close()来关闭套接字如果这是执行此操作的预期方式，则从 openssl 下退出（实际上 asio ssl 示例似乎表明这是关闭的正确方式）。

Answer 1

对于加密安全关闭，双方必须通过调用shutdown()或async_shutdown()并运行io_service对boost::asio::ssl::stream执行关闭操作。 如果操作以没有SSL 类别的error_code完成并且在部分关闭可能发生之前没有被取消，则连接已安全关闭，底层传输可能会被重用或关闭。 简单地关闭最低层可能会使会话容易受到截断攻击。

---

协议和 Boost.Asio API

在标准化的TLS协议和非标准化的SSLv3协议中，安全关闭涉及各方交换close_notify消息。 在Boost.Asio API 方面，任何一方都可以通过调用shutdown()或async_shutdown()来发起关闭，导致向close_notify发送close_notify消息，通知接收方发起方不会再发送更多消息SSL 连接。 根据规范，接收者必须使用close_notify消息进行响应。 Boost.Asio 不会自动执行此行为，并要求接收者显式调用shutdown()或async_shutdown() 。

该规范允许关闭的发起者在收到close_notify响应之前关闭连接的读取端。 这用于应用程序协议不希望重用底层协议的情况。 不幸的是，Boost.Asio 目前 (1.56) 不提供对此功能的直接支持。 在 Boost.Asio 中， shutdown()操作在出现错误或一方已发送和接收close_notify消息时被认为已完成。 操作完成后，应用程序可以重用底层协议或关闭它。

场景和错误代码

建立 SSL 连接后，关机期间会出现以下错误代码：

• 一方发起关闭，另一方关闭或已经关闭底层传输，而没有关闭协议：
  • 发起方的shutdown()操作将因 SSL 短读错误而失败。
• 一方发起关闭，等待对方关闭协议：
  • 发起者的关闭操作将完成，错误值为boost::asio::error::eof 。
  • 远程方的shutdown()操作成功完成。
• 一方发起关闭然后关闭底层协议，无需等待远程方关闭协议：
  • 发起者的shutdown()操作将被取消，导致boost::asio::error::operation_aborted 。 这是以下详细信息中指出的解决方法的结果。
  • 远程方的shutdown()操作成功完成。

下面详细介绍了这些不同的场景。 每个场景都用类似游泳线的图表来说明，指示每一方在完全相同的时间点正在做什么。

invokes shutdown() after closes connection without negotiating shutdown.所调用shutdown()后关闭，不谈判关机连接。

violates the shutdown procedure by closing the underlying transport without first invoking shutdown() on the stream.在这种情况下， 通过关闭底层传输而不首先在流上调用shutdown()来违反关闭程序。 attempts to initiate a shutdown() .一旦底层传输关闭， 尝试启动shutdown() 。

 PartyA                              | PartyB
-------------------------------------+----------------------------------------
 ssl_stream.handshake(...);          | ssl_stream.handshake(...);
 ...                                 | ssl_stream.lowest_layer().close();
 ssl_stream.shutdown();              |

will attempt to send a close_notify message, but the write to the underlying transport will fail with boost::asio::error::eof . 将尝试发送close_notify消息，但对底层传输的写入将失败并显示boost::asio::error::eof 。 violated the SSL shutdown procedure. Boost.Asio 将明确地将底层传输的eof错误映射到 SSL 短读错误，因为违反了 SSL 关闭程序。

if ((error.category() == boost::asio::error::get_ssl_category())
     && (ERR_GET_REASON(error.value()) == SSL_R_SHORT_READ))
{
  // Remote peer failed to send a close_notify message.
}

invokes shutdown() then closes connection without negotiating shutdown. 调用shutdown()然后关闭连接而不协商关闭。

initiates a shutdown.在这种情况下，发起关闭。 receives the close_notify message, violates the shutdown procedure by never explicitly responding with a shutdown() before closing the underlying transport.然而，当收到close_notify消息时，在关闭底层传输之前从未明确响应shutdown() ，从而违反了关闭程序。

 PartyA                              | PartyB
-------------------------------------+---------------------------------------
 ssl_stream.handshake(...);          | ssl_stream.handshake(...);
 ssl_stream.shutdown();              | ...
                                     | ssl_stream.lowest_layer().close();

will send a close_notify then wait for a response.作为Boost.Asio的的shutdown()操作被认为是完整的一次close_notify已经发送和接收的或发生错误时，将发送close_notify ，然后等待响应。 closes the underlying transport without sending a close_notify , violating the SSL protocol.关闭底层传输不发送close_notify ，违反SSL协议。 's read will fail with boost::asio::error::eof , and Boost.Asio will map it to an SSL short read error. 的读取将因boost::asio::error::eof而失败，并且 Boost.Asio 会将其映射到 SSL 短读取错误。

initiates shutdown() and waits for to respond with a shutdown() . 启动shutdown()并等待响应shutdown() 。

will initiate a shutdown and wait for to respond with a shutdown.在这种情况下，会发起关机，等待响应关机。

 PartyA                              | PartyB
-------------------------------------+----------------------------------------
 ssl_stream.handshake(...);          | ssl_stream.handshake(...);
 ssl_stream.shutdown();              | ...
 ...                                 | ssl_stream.shutdown();

这是一个相当基本的关闭，双方发送和接收close_notify消息。 一旦双方协商关闭，底层传输可以重新使用或关闭。

• 's shutdown operation will complete with an error value of boost::asio::error::eof . 的关闭操作将完成，错误值为boost::asio::error::eof 。
• 's shutdown operation will complete with success. 的关机操作将成功完成。

initiates shutdown() but does not wait for to responsd.发起shutdown()但不等待响应。

will initiate a shutdown and then immediately close the underlying transport once close_notify has been sent.在这种情况下， 将启动关闭，然后在发送close_notify后立即关闭底层传输。 does not wait for to respond with a close_notify message.不等待回应了close_notify消息。 这种类型的协商关闭是根据规范允许的，并且在实现中相当普遍。

如上所述，Boost.Asio 不直接支持这种类型的关机。 Boost.Asio 的shutdown()操作将等待远程对等方发送其close_notify 。 但是，可以在仍然支持规范的同时实施变通方法。

 PartyA                              | PartyB
-------------------------------------+---------------------------------------
 ssl_stream.handshake(...);          | ssl_stream.handshake(...)
 ssl_stream.async_shutdown(...);     | ...
 const char buffer[] = "";           | ...
 async_write(ssl_stream, buffer,     | ...
  [](...) { ssl_stream.close(); })   | ...
 io_service.run();                   | ...
 ...                                 | ssl_stream.shutdown();

will initiate an asynchronous shutdown operation and then initiate an asynchronous write operation. 会先发起异步关机操作，然后再发起异步写操作。 用于写入的缓冲区必须是非零长度（上面使用了空字符）； 否则，Boost.Asio 会将写入优化为无操作。 , causing SSL to close the write side of 's SSL stream, and then asynchronously wait for 's close_notify .当shutdown()操作运行时，它会发送close_notify给，从而导致SSL关闭的写入端的SSL流，然后异步地等待的close_notify 。 's SSL stream has closed, the async_write() operation will fail with an SSL error indicating the protocol has been shutdown.但是，由于的 SSL 流的写入端已关闭，因此async_write()操作将失败并显示 SSL 错误，表明协议已关闭。

if ((error.category() == boost::asio::error::get_ssl_category())
     && (SSL_R_PROTOCOL_IS_SHUTDOWN == ERR_GET_REASON(error.value())))
{
  ssl_stream.lowest_layer().close();
}

's close_notify to be cancelled.失败的async_write()操作则显式关闭底层传输，造成async_shutdown()正在等待的操作close_notify被取消。

• performed a shutdown procedure permitted by the SSL specification, the shutdown() operation was explicitly cancelled when underlying transport was closed.尽管执行了 SSL 规范允许的关闭过程，但在shutdown()底层传输时， shutdown()操作被明确取消。 因此， shutdown()操作的错误代码的值为boost::asio::error::operation_aborted 。
• 's shutdown operation will complete with success. 的关机操作将成功完成。

---

综上所述，Boost.Asio 的 SSL 关闭操作有点棘手。 正确关闭期间发起方和远程对等方的错误代码之间的不一致可能会使处理变得有点尴尬。 作为一般规则，只要错误代码的类别不是 SSL 类别，协议就会被安全关闭。