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:
gRPC Swift AFAIK doesn't let you choose arbitrary SSL implementation. It supports two and will let you choose but I don't think it by default lets you just inject one. But that's easy to work around: It allows you to specify a debugChannelInitializer which you can (ab)use to insert any TLS encrypting ChannelHandler 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) }).
As far as I know, there are only two TLS implementations for SwiftNIO: The BoringSSL-based one in swift-nio-ssl and the one that uses Network.framework on Apple platforms in swift-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 a NIO 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.
Related
I have a java codebase that seems to be using "com.google.api.services.cloudkms.v1.CloudKMS" to call KMS. The online docs says to use "com.google.cloud.kms.v1.KeyManagementServiceClient"
When i looked up both packages seem to be updated, however the reference docs recommend using the latter.
https://developers.google.com/resources/api-libraries/documentation/cloudkms/v1/java/latest/com/google/api/services/cloudkms/v1/CloudKMS.html
https://cloud.google.com/kms/docs/reference/libraries
Could someone tell me what is the difference between these 2 clients packages and if i should move to the one the reference links to?
In general, you should prefer the library referenced on the Reference Libraries page, currently com.google.cloud.kms. The examples and tutorials on the website will use this client library.
Probably more history than you need to know, but we have two client libraries because they run over different protocols. The new libraries (the one's listed on the reference page) use gRPC to communicate. This means less bandwidth and less time spent serializing/de-serializing JSON. On the flip side, gRPC requires HTTP/2, and some organizations can't/won't support HTTP/2 yet. As a result, we still publish and maintain legacy libraries that are REST over HTTP/1. It is strongly recommended you use the gRPC ones unless you can't use HTTP/2.
You can read more about the background and technical details in Kickstart your cryptography with new Cloud KMS client libraries and samples.
We're sending REST requests from our application. The remote service will be switching off all security protocols, except for TLS1.2 soon and we need to comply. We modified our code to make sure we use TLS1.2, however we received a message from the folks running the external service that we still use an older protocol (communication with them is a little slow). We are familiar with ways to use TLS1.2 in .Net (in which our app is made), but we would like to check which protocol we actually use. Is there a public Rest service out there that we could use to check protocol used for a request?
Optionally a public Rest service that would only accept TLS1.2 would do.
So I needlessly restricted myself to looking for a rest service, which explains why I couldn't find anything (a more general question would give more google results). A similar question to mine was already asked on stack (What version of TLS does my C# program use?) and one of the answers contains this link https://www.howsmyssl.com/a/check, which is exactly what I was looking for.
If I develop Booking REST service in Golang (i.e., in package booking). Is it a "GO way" to create BookingClient interface (backed up by struct) with business operations allowed, so that clients of my restful service would use BookingClient (imported from package booking) instead of sending http requests directly?
In general, no – if you provide a client in a particular language it'd only be a convenience, so (some) users can use your API easier. This of course assumes your client is well designed. I wouldn't provide merely an interface in Go just to indicate a set of possible API calls. This would be beneficial to a very narrow range of audience, probably for people developing a client for your API themselves, in programming language which just happened to be the same as implementation of your server. And even then they might not really like the idea of using the interface (e.g. they might only need a specific set of methods).
If you want to provide a client for your API, go ahead, do it, but separate it from the actual server (different package, maybe even different repo). In general one develops APIs over HTTP to allow for wide range of clients to access it, which could be written in any language. Instead of providing some interfaces I would invest my time in writing a good documentation.
In my opinion the answer to your question, assuming there is no more context provided, should be no different if you asked yourself if you should provide a client in, say, Python. The whole situation might change though if, for example, your API is used internally by your company and you develop mainly in Go.
It's usually preferable to do this, and most companies do, but provide documentation for working directly with the API. The main use case for that is people working with different languages than the ones you intended.
You can have a look at a new RESTful framework I wrote, that includes infrastructure to automatically compile clients with Go templates, although I haven't gotten to writing a Go client compiler. If you want to write one it would be greatly appreciated :) https://github.com/EverythingMe/vertex
Testing is important in Go, so writing testable code is something you should do. If you use direct http requests you will have a harder time writing unit tests, compared to using a mocked struct.
Is there any reason to use a Client rather than calling the functions that call the REST endpoints? It's usually harder to mock a bigger thing, such as a Client struct, rather than a group of small functions.
You should put the client at booking.Client to avoid repeating yourself (booking.BookingClient) and maybe rename Client to something more descriptive.
I am looking for an open source framework to build a proprietary protocol onto (Agent/Client talks to a Receiver/Server that stuffs things into a SQL database).
I need session handling (ie login/logout) and some kind of encryption.
I found the Spread Framework which looks great, but does not appear to support authentication or encryption of any kind out of the box.
My preferred language is C, C++, Python, or Perl.
Anyone know of anything off hand? Hoping for something to be out there to save me time rather than doing it the hard way all in *nix sockets ;)
Thanks in advance!
Why not use libcurl, as it can do SSL.
http://curl.haxx.se/libcurl/c/example.html
DJango and DJango ORM, or SQLAlchemy combinations can be a good start. A python base framework and ORM.
Since you are working at the socket level, I assume that you are trying to write an application from the ground up. Or are you trying to run within an existing web server?
Could you use lighttpd with HTTPS & mod_cgi? This isn't really a framework, per se, but it would keep your application portable to other infrastructures.
On the server side, CGI::Session could take care of the session management. Authentication could be done using mod_auth.
Why not use SSL/TLS? On the client you can use libcurl, which works with C, C++, Python, and Perl. On the server, use Apache, lightttp etc, with cgi or your favorite language. You can use mutual authentication to ensure verify the identify of both the client and server, as well as provided an encrypted channel.
For a college project i'm thinking of implementing the business layer in Erlang and then accessing it via multiple front-ends using REST. I would like to avail of OTP features like distributed applications, etc.
My question is how do I expose gen_server calls/casts to other applications? Obviously I could make RPC calls via language specific "bridges" like OTP.net or JInterface, but I want a consistent way to access it like REST.
As already mentioned Yaws or Mochiweb are a great way to go but if you'd like a dead simple way to get your RESTful API done quickly and correctly then use Webmachine. It's a layer on top of Mochiweb that implements proper HTTP behavior based on Alan Dean's amazing HTTP flow diagram and makes it easy to get REST done right.
I'm using it right now to expose a REST API as well as handle a COMET application and it's been pretty easy to do, even for an Erlang newbie such as myself.
I did something similar for my job and found it best to use REST to expose the business layer because even Legacy languages such as SoftwareAG's Natural is able to access it. The best mechanism that I have found in Erlang is to use Mochiweb.
You can find more information about using it from the screencast located at
Erlang In Practice Screencast. Episode 6 is particularly helpful but all of them are excellent.
A resource to walk you through installation is How To Quickly Set Up Ubuntu 8.04 loaded with Erlang, Mochiweb and Nginx and Migrating a native Erlang interface to RESTful Mochiweb (with a bit of TDD) provides a good start if you don't find the screencasts to your liking.
The HTTP flow diagram link is dead. The original version and a updated version created in collaboration between Alan Dean and Justin Sheehy ist also hosted in the Webmachine project: link to latest version of the HTTP Diagramm.
There is valuable approach to design gen_server calls/casts in flavor of REST if possible. You can use messages as
{get, Resource}
{set, Resource, Value} % aka PUT
{delete, Resource}
{add, Resource, Value} % aka POST (possible another names are append, modify or similar)
Then its mapping is easy. You can make some transformation URI->RESOURCE or use identity. For most of your application this should be wort approach and special cases you should handle specially. You can think there will be big margin, where you can't use this approach, but this should be mostly premature optimization.
Do you really mean a RESTful interface or RPC over HTTP? Building a RESTful interface on top of an existing layer is more work than just exposing existing methods via HTTP.
I'd suggest to use mochiweb or yaws to implement a (generic) rpc layer.
Just an update, Webmachine has moved to bitbucket: new link to Webmachine