Re: [asio-users] Native Windows ssl::stream support

[Kasper L. <la...@st...>]

On 21/07/2020 22.45, Vinnie Falco wrote:
> 
> Buffer-oriented ("bring your own socket") would be the most
> straightforward, and also the area in which my colleagues and I have
> the most experience. We can collaborate in the free C++ Language Slack
> Workspace (get the invite at https://cppalliance.org/slack).
> 
> And we can help with setting up a GitHub repository for CI and testing
> workflow - the benefit of setting up a public repository early is that
> stakeholders can look at code and comment on it, submit reviews, even
> contribute by writing tests or example programs.
> 

Sorry for taking so long to reply, but I have spent the time I had 
available on creating a very basic proof-of-concept using Windows 
SSPI/SChannel with boost::asio on Windows:

https://github.com/laudrup/boost-asio-windows-sspi

There are tons of things missing. I am not even able to create a TLS 
connection to boost.org unless I provide a hostname for validation to 
SSPI/SChannel (which is not currently possible in this implementation), 
but I think it works pretty well as a proof-of-concept.

There are also many things wrong with the code that I'm fully aware of, 
but as you suggested Vinnie, I think I'd better get something out there 
sooner than later.

Apart from all the things that are wrong, I do actually feel quite 
confident that I could make this a usable implementation for using 
SSPI/SChannel with boost::asio on Windows and avoid having to use 
OpenSSL, but as my time is limited as well, I probably need some help.

Before I start moving any further with this, I think the next step is to 
think about the design, as this current POC isn't really designed at all.

I've looked quite a bit at the GnuTLS implementation that Arvid was kind 
enough to link to as well as the current OpenSSL implementation and 
while I like the idea of having a "drop in replacement" which seems to 
be the goal of the GnuTLS implementation, I really think the current 
OpenSSL implementation in boost::asio is extremely well designed with 
the actual OpenSSL details being (mostly) abstracted away very nicely.

It looks to me as if I could actually reimplement the "engine" class for 
use with SSPI/SChannel and get all the async behaviour, buffer handling 
etc. for "free". I would still need to hide some of the OpenSSL 
specifics currently "leaking" from the implementation, especially in the 
context class, but that seems comparatively trivial.

My ambitious goal is, that it should be possible for the user to choose 
which implementation to use while getting the same behavior. I'm not 
really sure what would be the best way to move in that direction.

One way would be to simply fork the current asio repository and rewrite 
the OpenSSL parts to use SSPI/SChannel instead. That would probably be 
the easiest, as my first goal would then be to simply make it compile 
without having OpenSSL available and then knowing which stub 
functions/classes etc. I'd need to implement. It would require a bit of 
cleanup later on if I actually got it to work though.

Anyway, most importantly I would really like to work on this so I wanted 
to share this sooner than later. This is only something I'm doing in my 
spare time which is already limited, so don't expect too much from me 
but I hope you guys will appreciate my efforts as I would be extremely 
proud if I could actually end up contributing something like this to the 
boost project.

Please let me know what you think.

Thanks a lot and kind regards,

Kasper Laudrup