Any plan to support OpenSSL?

[cang-mang]

Currently, lsquic only support BoringSSL. But in many phone devices, app-packet size is very important, and the old version of the app often takes OpenSSL. Now we add lsquic to the app, then we must add BoringSSL to it, too. So the size of the app-packet becomes too big. In some other cases, the old version of the app takes a static library of OpenSSL, and when we add lsquic with BoringSSL to the app, if the BoringSSL is a static library, then many symbols conflict; else if the BoringSSL is a dynamic library, then at run-time the app crashes. So, can you develop a branch version of supporting OpenSSL? Thanks very much.

[dtikhonov]

Yes, supporting OpenSSL would be very nice. There are two obstacles to it:

1. It is not high on our priority list.
2. OpenSSL does not support QUIC yet. (There is a patched version, but it's unofficial).

Note that BoringSSL can be compiled where all exported symbols are prefixed with a custom prefix. That should allow you to use both OpenSSL and BoringSSL in your application.

[robmang]

How would we build lsquic to support boringssl with prefixed exported symbols? Would it be up to us to rename them in lsquic? Thanks

[dtikhonov]

No, you would not need to change any code. See BoringSSL documentation.

[jazune]

Yes, supporting OpenSSL would be very nice. There are two obstacles to it:

1. It is not high on our priority list.
2. OpenSSL does not support QUIC yet. (There is a patched version, but it's unofficial).

Note that BoringSSL can be compiled where all exported symbols are prefixed with a custom prefix. That should allow you to use both OpenSSL and BoringSSL in your application.

hi，@dtikhonov， any play to suport openssl? If not, I wll do this. my plan is: 1，use openssl QUIC patch to suppot quic sdk. 2，in lsquic, replace AEAD api in boringssl with evp api which both exist in boringssl and openssl. 3，replace boringssl with openssl.

for lsquic，the main change is replacing AEAD with evp。

[dtikhonov]

That would be super if you did it! 👍 💯

I think this would require writing a set of function pointers: one for OpenSSL and one for BoringSSL. But let's see what you come up with. Of course, if you simply replace BoringSSL with OpenSSL, we won't be able to merge it to mainline.

[jazune]

@dtikhonov I plan only change lsquic code that will be suitable for both boringssl and openssl with quic sdk patch. So, it won't effect current compile. And If one want to use openssl, it can also work.

[dtikhonov]

Great, I am looking forward to it!

[brjoha]

Another year. Has pluggable SSL percolated up the priority list at all?

[gegles]

Any update on this? BoringSSL is one of the reason we can't use this in our system at this point...

Thanks!