I want to send sensitive data through Cloud IoT Config, but not sure of if there is any encryption. Is there any form of encryption that happens for config messages between server and device?
Any references?
It does support TLS encryption, I've only implemented this over MQTT.
I'd recommend going over this page: https://cloud.google.com/iot/docs/concepts/device-security
Related
I have a simple app connected to a server via some sockets and the traffic is not yet encrypted users must log in or create accounts before using the app and afterwards traffic is shared between users and server. i want to know if i must encrypt all traffic or just the authentication and account creation?
Use https for all traffic (or an equivalent TLS-based protocol for non-HTTP traffic). Yes, encrypt and certificate-authenticate everything. For modern systems, there are vanishingly few cases where TLS is not the correct answer for network traffic. It is ubiquitously available across platforms, languages, and protocols.
On any modern network system you need an argument for why you wouldn't encrypt and authenticate the connection. It's not a matter of "must" you. It's a matter of "why wouldn't you?"
I'm currently developing an application for a client and their requirement is that the application needs in transit and at rest encryption. I assured that it was and was required to provide documentation for that. I referenced this documentation from Google Cloud's website. They replied by asking if my claim stands in light of the following section
Using a connection directly to a VM using an external IP or network load balancer IP
If you are connecting via the VM's external IP, or via a network-load-balanced IP, the connection does not go through the GFE. This connection is not encrypted by default and its security is provided at the user's discretion
My mobile application uses Firebase SDK to talk to the Firebase database and Firebase functions. I have no background in networking nor do I understand what is exactly being referenced here despite Googling the concepts. Is my data still encrypted? Does the above section apply to my use case?
No, that applies only to VMs and network load balancers. Both Cloud Functions (so long as you're using https for all requests) and the Firebase Realtime database encrypt data in transit.
As coTurn server provides the option to create multiple realms throught its database, and when turning the server on, a default realm can be provided in the configuration.
When configuring the webRTC client to access TURN, it only allows the URIs, username and credentials properties, but does not have any way to provide a realm or origin (as coturn supports origin).
The default realm is always considered.
If I try to utilize the realms concepts, providing different user credentials under different realms in the webRTC client config, the server accepts only turn requests with users under the default realm.
Questions
Is there a way to overcome this matter to provide realms/origin to the server?
If not, why have realms been added to the coturn if they cannot be used?
tl;dr: the realm is pretty useless in WebRTC.
In theory TURN as a protocol includes a realm. However, see the detailed example in the RFC this typically isn't sent in the initial allocate request, only subsequent ones. In theory the client could store the realm and use it for subsequent requests.
In WebRTC, the peerconnections are pretty much independent. There is no way to configure the realm in the ICE server configuration
See also this response from working on that in chrome/webrtc.org
We are using java library com.google.cloud:google-cloud-dlp to make Google Cloud DLP calls. On the client side, we are utilizing DlpServiceClient. I know for the fact that it internally uses gRPC. Wondering whether the default communication uses SSL/TLS?
The default communication doesn’t use SSL/TLS.
Token-based authentication with Google: gRPC provides a generic mechanism (described below) to attach metadata based credentials to requests and responses. Additional support for acquiring access tokens (typically OAuth2 tokens) while accessing Google APIs through gRPC is provided for certain auth flows.
For applications running in GCE, a default service account and corresponding OAuth2 scopes can be configured during setup. At run-time, this credential handles communication with the authentication systems to obtain OAuth2 access tokens and attaches them to each outgoing RPC on the corresponding channel.
gRPC-enabled Cloud APIs generally have both REST and RPC interfaces, so rather than just using JSON over HTTP to talk to the REST interface, gRPC-enabled API clients can also use protocol buffers and gRPC over HTTP2 to talk to the RPC interface.
I've been developing a mobile app (iOS) with gRPC via Firebase auth(z). My server is using GKE with the NGinx proxy - so now I'm developing the Web UI for the deeper configuration of a user account. I prefer not to fall back to REST API's, so I was wondering if Google Cloud Endpoints supports websockets, and would it also prevent non-authorised app users from trying to make a request? With websockets I know it's possible, but as I'm tied in with gRPC with Cloud Endpoints, I'm just checking before I fall back to REST API calls (I prefer not to!).
Summary: Does Google Cloud Endpoints support Websockets with JWT auth tokens from Firebase?
Thanks
It looks like ESP supports websockets now, using the "--enable_websocket" flag in the esp config.
Currently, Cloud Endpoints doesn't support WebSockets at all.
Btw, what is your use case for WebSockets? WebSocket won't work with gRPC either. If you just want to talk to your gRPC service from Web UI, transcoding should work. It works with JWT from Firebase auth.
The Google Cloud Endpoints ESP doesn't support websockets.
However, Google Cloud Endpoints have open sourced their Extensible Service Proxy implementation. Internally it's implemented as a custom nginx module. Since Nginx supports websockets, it should be feasible to add support to their nginx:esp module.
But it's definitely out of scope for me. :-)