Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile-time option to disable SSL completely #136

Open
ysc3839 opened this issue Aug 7, 2023 · 14 comments
Open

Compile-time option to disable SSL completely #136

ysc3839 opened this issue Aug 7, 2023 · 14 comments

Comments

@ysc3839
Copy link

ysc3839 commented Aug 7, 2023

Currently even if SSL is not used, the library still requires OpenSSL. Can you provide a compile-time option to disable SSL completely?

@mzimbres
Copy link
Collaborator

mzimbres commented Sep 4, 2023

I am not finding the time to implement this right now as I have other priorities in the project. It might take some time.

@RayDavidWhitmer
Copy link

I would vote for this fix. While openssl is easy to provide in a Linux environment, this is less the case in Windows. When building libcurl, for example, there are options besides openssl which integrate better with the native Windows environment.

It would be nice for asio to support options besides openssl which are more native to Windows, like libcurl does.

It would be also nice to also be able to avoid unnecessary dependencies between boost::redis and anything for those who didn't need an encrypted connection to redis in the first place.

When I include redis.hpp, it winds up including detail/handshaker.hpp which includes asio/ssl/context.hpp which includes asio/ssl/context_base.hpp which includes asio/ssl/detail/openssl_types.hpp which tries to include openssl_conf.h which is not likely to be on my Windows systems.

Eliminating the hard dependency either in favor of nothing if ssl is not required (easier fix?) or in favor of Windows facilities, like CURL does, would make the redis libraries usable more broadly.

I can investigate whether I have the permission and time to propose specific modifications for one or both of these.

@RayWhitmer
Copy link

The asio/openssl dependencies as written seem too convoluted for me to reasonably to fix. I think someone else may need to address making ssl code truly optional (and/or to optionally use schannel on windows) starting in the asio ssl layer which is getting used all over the place on paths where the functionality is NOT conditional on ssl functionality.

@mzimbres
Copy link
Collaborator

mzimbres commented Jan 3, 2024

Hi, if https://wintls.dev/ gets included in Boost it would be simpler to get rid of openssl. Otherwise, the problem is that I have to use asio::stream<tcp::stream> to support dynamically switching from one to the other. However, I don't think this is too difficult ifdef openssl away in Boost.Redis, it is just a matter of my own free time. I am going to have a look at how Boost.MySql (@anarthal ) solved this.

@anarthal
Copy link
Collaborator

anarthal commented Jan 3, 2024

I never solved it. MySQL needs hashing functions regardless of whether you're using TLS or not, and reimplementing sha256 wasn't something I wanted. I may change my mind at some point (since people also asked for it).

I don't know if this helps, but ssl::stream<tcp::socket&> is a valid idiom I've found useful for conditionally enabling SSL, at least at runtime.

@mzimbres
Copy link
Collaborator

mzimbres commented Jan 3, 2024

@ysc3839 Do you need this to get rid of openssl on windows or in general? AFAICS https://wintls.dev/ would solve most peoples problems.

@laudrup Do you have any idea when are you going to submit Boost.Wintls for inclusion in Boost?

@ysc3839
Copy link
Author

ysc3839 commented Jan 4, 2024

@mzimbres It's not for Windows. My program does not use TLS. By disabling SSL, the program would not have external dependency (the only dependency is headers-only part of boost), so it can run on many Linux distro without rebuild. And maybe it can run on Windows.

@laudrup
Copy link

laudrup commented Jan 6, 2024

@mzimbres

I did consider trying to get Boost.Wintls included in Boost at some point but it's not really something I've done anything about. I think it might make more sense if it could be included in Asio (standalone and Boost) but I haven't done anything about that either.

Seeing as you are the maintainer of a Boost library I assume you have some experience with getting a library included with Boost. Would you recommend that I try to get my Boost.Wintls library included and if so do you think you could help me submitting it?

Thanks a lot.

@anarthal
Copy link
Collaborator

anarthal commented Jan 6, 2024

I'd recommend that you asked in Boost's mailing list first if you haven't before. You can act in consequence depending on the answers you get. If you move forward with getting it into Boost, I may be able to provide some guidance to you, too.

@laudrup
Copy link

laudrup commented Jan 6, 2024

@anarthal

Thanks. First of all I was mostly interested in knowing whether it might make sense to even try getting it included but I guess the mailing list might be a good way to get some feedback on that as well. I'll probably try writing there at some point.

@anarthal
Copy link
Collaborator

anarthal commented Jan 6, 2024

I think it can be useful, either as a standalone library or as part of asio.

@mzimbres
Copy link
Collaborator

mzimbres commented Jan 6, 2024

@chriskohlhoff Do you think https://wintls.dev could be incorporated by Asio?

@mzimbres
Copy link
Collaborator

mzimbres commented Jan 6, 2024

Seeing as you are the maintainer of a Boost library I assume you
have some experience with getting a library included with Boost.
Would you recommend that I try to get my Boost.Wintls library
included and if so do you think you could help me submitting it?

I think Boost.Wintls fits well into Boost. I am not windows user, but as you have seen above there are people that don't want to depend on openssl on windows. If it is part of Boost I could use it as the default stream type on Windows.

As others said, announce your library on the Boost developer's ML and ask for endorsement. After that you can ask for a review manager, which will arrange a review with the wizards. Reviews last for 10 days usually and you have to answer a lot of questions.

After the library is accepted you have to integrate it in Boost, but there is no time pressure and the whole process might take one year.

@laudrup
Copy link

laudrup commented Jan 10, 2024

I think Boost.Wintls fits well into Boost. I am not windows user, but as you have seen above there are people that don't want to depend on openssl on windows. If it is part of Boost I could use it as the default stream type on Windows.

I'm not a Windows user either and don't have much experience developing anything for Windows. The reason I wrote this in the first place was that I write cross platform C++ at work where native TLS support on Windows might be relevant. I don't have any use for this library myself personally or at work currently, but of course I'm very happy if any work I've done can actually be used by someone.

As others said, announce your library on the Boost developer's ML and ask for endorsement. After that you can ask for a review manager, which will arrange a review with the wizards. Reviews last for 10 days usually and you have to answer a lot of questions.

I'll consider doing that sooner or later. I think it might make more sense to integrate it in Asio instead but I guess that discussion could be had on the mailing list as well.

Thanks a lot for your encouragement, I really appreciate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants