It seems that Snap only has GRPC TLS implementation but not Rest API implementation. I'm going to change this issue catalog to feature enhancement instead of a bug.

Your post seems to indicate a deficit in Snap and a possibility for enhancement.
Let me please address the issue you seem to be indicating:

When Snap is secured with TLS, the scheme should be HTTPS instead of HTTP.

Right now snapteld is changing the scheme to HTTPS for REST API, when TLS is enabled with option --rest-https. On the other hand TLS in GRPC is about securing the internal communication with plugins.
Ideally user should enable TLS for both channels - REST API and the plugin communication.

If you propose automatic switching of REST API to HTTPS in case of TLS for GRPC then few more details need to be considered:

• should it work both ways? (ie. TLS for REST API triggering TLS encryption for GRPC?)
• what certificates should user provide at runtime? TLS for REST API requires a server certificate (a TLS cert valid for web server) while TLS for GRPC requires only a web client certificate
• right now snapteld is authenticating itself to listening plugins and presents its own certificate. Should it demand authentication from REST API clients?

I do believe this subject is worth consideration, so perhaps you could come up with a RFC?

@marcintao, very good questions. We need discussions on these. We can work on the RFC.

1. When TLS is supported for REST APIs, --rest-https, --insecure flags should be replaced.
2. REST API point view, Snap is server and snap-cli is a client. But from GRPC point view, it's the opposite. One thing I would like to clarify is that if a plugin is still using the pulling not pushing to communicate with Snap under GRPC? Do plugins initiate the connection during a plugin starts?
3. if we don't want bogus events from plugins, mutual TLS probably is a good idea. What do you think?

1. When TLS is supported for REST APIs, --rest-https, --insecure flags should be replaced.

Could you tell more about your idea? Which API version: do you refer to? v1 or v2?

2. [...] One thing I would like to clarify is that if a plugin is still using the pulling not pushing to communicate with Snap under GRPC? Do plugins initiate the connection during a plugin starts?

Nothing has changed here. Plugins are servers and are awaiting connection from snapteld.

3. if we don't want bogus events from plugins, mutual TLS probably is a good idea. What do you think?

TLS for GRPC was implemented with mutual authentication in mind, it's already working. That's why snapteld needs a certificate for connection as a client.

@marcintao, thanks for your reply. As https are globally enabled not per operation, this posts as none issue unless we decided to run both HTTP and HTTPS at the same time. Currently, the main issue is:

Non-GRPC plugins cannot be loaded with GRPC plugin TLS is enabled. snapteld has to be restarted in a different state in order to load both types of plugins. Did I miss anything? please share your thoughts if we can detect plugin types and act accordingly.