At https://github.com/boostorg/asio/pull/283 <https://github.com/boostorg/asio/pull/283> I’ve attached a proof-of-concept which explores making ASIO secure by default. The C++ committee is discussing what secure-by-default networking would look like in the soon to be published papers P1860 and P1861. Since the C++ Networking TS is based on ASIO, this seems like a good place to try things out. The implementation uses BoringSSL for its crypto and Security.framework to evaluate certificates against the root certificates trusted by the system. I've implemented enough to see what the API shape would need to be, and it works with basic client and server programs. I’d love to get your feedback on this initial work, including any implementation concerns you have and suggestions on portability. I don’t think the patch is ready to commit as-is.
On Tue, Sep 10, 2019 at 6:04 PM Alex Christensen via Boost <boost@lists.boost.org> wrote:
At https://github.com/boostorg/asio/pull/283 <https://github.com/boostorg/asio/pull/283> I’ve attached a proof-of-concept which explores making ASIO secure by default.
This looks like nonsense to me. `asio::ssl::stream` is a layered stream [1] which is implemented in terms of operations on an instance of the NextLayer type. For example, given: asio::ssl::stream<tcp::socket> ss{...}; the next layer type is tcp::socket, which meets the requirements of SyncReadStream, SyncWriteStream, AsyncReadStream, and AsyncWriteStream. Asio's ssl::stream can work with any type which meets the requirements. Here's an example that uses Beast's test stream [2]: asio::ssl::stream<beast::test::stream> ss{...}; What you have done is ignore the elegant concept-driven design of Asio, and instead invest energy to pursue some religious agenda ("secure by default"). The result is a less functional networking component. Here's are two more examples which cannot be implemented with your design: This one provides real-time counts of encrypted bytes read and written [3] asio::ssl::stream<beast::counted_stream<tcp::socket>> ss{...}; This one supports inline timeouts, delivered as the error code beast::error::timeout [4]: asio::ssl::stream<beast::tcp_stream> ss{...}; You should have come to me first so I could spare you the wasted effort by explaining that your design is crippled out of the box. It isn't too late, I am more than happy to help you find more productive uses of your time. Regards [1] <https://www.boost.org/doc/libs/1_71_0/libs/beast/doc/html/beast/using_io/layered_streams.html> [2] <https://www.boost.org/doc/libs/1_71_0/libs/beast/doc/html/beast/ref/boost__beast__test__stream.html> [3] <https://www.boost.org/doc/libs/1_71_0/libs/beast/doc/html/beast/using_io/layered_streams/counted_stream_example.html> [4] <https://www.boost.org/doc/libs/1_71_0/libs/beast/doc/html/beast/using_io/timeouts.html>
On Wed, 11 Sep 2019 at 00:35, Alex Christensen via Boost <boost@lists.boost.org> wrote:
At https://github.com/boostorg/asio/pull/283 <https://github.com/boostorg/asio/pull/283> I’ve attached a proof-of-concept which explores making ASIO secure by default. The C++ committee is discussing what secure-by-default networking would look like in the soon to be published papers P1860 and P1861. Since the C++ Networking TS is based on ASIO, this seems like a good place to try things out.
I cannot find P1860 or P1861 anywhere. In any case I'm pretty sure a lot of people will be voting against that. Let's have the first round of opinions before considering changing boost.
participants (3)
-
Alex Christensen
-
Mathias Gaunard
-
Vinnie Falco