Currently working on a project that uses Swift-gRPC; which uses BoringSSL. I would like to know if it is possible to use a custom SSL Provider, such as OpenSSL.
I found this post that allows you to specify an SSL provider for the gRPC C++ library. I would like to know if the same thing is possible in the Swift gRPC library.
So to answer your question: Yes, this is possible because in SwiftNIO an SSL implementation is really just a
ChannelHandler
that happens to encrypt/decrypt.BUT: Are you really sure that you want to use an OpenSSL-based implementation? I see absolutely no upsides but many many downsides of doing so. We ship the BoringSSL for you inside the Swift Package so there's no extra work for you and it should support all relevant SSL configurations (Google Chrome also uses BoringSSL so it should work :) ). Is this some legal or so requirement?
Again, I would very much advise against doing that but if you still want to do it, read on.
It it super easy to use an OpenSSL-based TLS implementation with gRPC Swift? No, for at least two reasons:
debugChannelInitializer
which you can (ab)use to insert any TLS encryptingChannelHandler
you want. So you'd tell gRPC Swift to use unsafe, unencrypted HTTP and then just shove the TLS handler into the pipeline ($0.debugChannelInitializer = { channel in channel.pipeline.addHandler(MyTLSHandler(), position: .first) }
).swift-nio-ssl
and the one that uses Network.framework on Apple platforms inswift-nio-transport-services
.In case you really want to go down the route of adding an OpenSSL-based implementation, I can help you a little bit: Very old swift-nio-ssl implementations for SwiftNIO 1 (unusable with gRPC Swift, deprecated and unsupported) did use an OpenSSL-based implementation. And I just ported that to SwiftNIO 2 (the current version, usable with gRPC Swift) in this branch. If you actually wanted to use that, you'd need to create a new Swift Package hosted somewhere. And please, please do rename the modules from
NIO*
to something not with aNIO
prefix if you actually release this.Again, I advise against doing so and the code comes with zero promises etc. It needs OpenSSL 1.0 or 1.1 installed on your system and passes its own test suite. But this code has never been used in production anywhere and is based on code that hasn't been touched in years. The actual TLS implementation comes from your system's libraries though.