I want to connect to Snowflake using ODBC, and I saw that it is SSL enabled by default(Does snowflake support ssl?).
Appreciate where I can have it formally from Snowflake, as I yet to find as such documentation..
Thanks !
All snowflake connectivity is to:
https://..snowflakecomputing.com
Even the ODBC connector is just a wrapper for HTTPS calls to then https URL above. That means that everything in snowflake, Web UI, JDBC, ODBC, snowsql, Python etc all runs over HTTPS and SSL.
It's also worth noting to meet the security standards here, all traffic must be SSL:
https://www.snowflake.com/snowflakes-security-compliance-reports/
I would read the following document, which has a bunch of different sections that reference SSL, OCSP, and openSSL key-pair settings.
https://docs.snowflake.com/en/user-guide/odbc-parameters.html
Appreciate where I can have it formally from Snowflake
The Snowflake Security Policy specifies that all customer data in transit is encrypted with TLS 1.2.
https://www.snowflake.com/wp-content/uploads/2018/07/2018July12-Snowflake-Security-Policy.pdf
Reference section 3.1. Encryption of Customer Data, which states "Snowflake leverages Transport Layer Security (TLS) 1.2 (or better) for Customer Data in-transit over untrusted networks."
This statement applies to all customer data in transit, so ODBC is included.
Related
I'm going to be using gRPC for a device to device connection over a network (my device will be running Linux and collecting patient data from various monitors, gRPC will be used by a Windows client system to grab and display that data).
I obviously want to encrypt the data on the wire, but dealing with certificates is going to be a problem for various reasons. I can easily have the server not ask for the client cert, but so far I've been unable to find a way around the client validating the server's cert.
I've got several reasons I don't want to bother with a server cert:
The data collection device (the gRPC server) is going to be assigned an IP and name via DHCP in most cases. Which means that when that name changes (at install time, or when they move the device to a different part of the hospital), I have to automatically fixup the certs. Other than shipping a self-signed CA cert and key with the device, I don't know how to do that.
There are situations where we're going to want to point client to server via IP, not name. Given that gRPC can't do a cert for an IP (https://github.com/grpc/grpc/issues/2691), this becomes a configuration that we can't support without doing something to give a name to a thing we only have an IP for (hosts file on the Windows client?). Given the realities of operating in a hospital IT environment, NOT supporting use of IPs instead of names is NOT an option.
Is there some simple way to accommodate this situation? I'm far from an expert on any of this, so it's entirely possible I've missed something very basic.
Is there some simple way to set the name that the client uses to check the server to be different than the name it uses to connect to the server? That way I could just set a fixed name, use that all the time and be fine.
Is there some way to get a gRPC client to not check the server certificate? (I already have the server setup to ignore the client cert).
Is there some other way to get gRPC to encrypt the connection?
I could conceivably set things up to have the client open an ssh tunnel to the server and then run an insecure gRPC connection across that tunnel, but obviously adding another layer to opening the connection is a pain in the neck, and I'm not at all sure how comfortable the client team is going to be with that.
Thanks for raising this question! Please see my inline replies below:
I obviously want to encrypt the data on the wire, but dealing with
certificates is going to be a problem for various reasons. I can
easily have the server not ask for the client cert, but so far I've
been unable to find a way around the client validating the server's
cert.
There are actually two types of checks happening on the client side: certificate check and the hostname verification check. The former checks the server certificate, to make sure it is trusted by the client; the latter checks the target name with server's identity on the peer certificate. It seems you are suffering with the latter - just want to make sure because you will need to get both of these checks right on the client side, in order to establish a good connection.
The data collection device (the gRPC server) is going to be assigned
an IP and name via DHCP in most cases. Which means that when that name
changes (at install time, or when they move the device to a different
part of the hospital), I have to automatically fixup the certs. Other
than shipping a self-signed CA cert and key with the device, I don't
know how to do that.
There are situations where we're going to want to point client to
server via IP, not name. Given that gRPC can't do a cert for an IP
(https://github.com/grpc/grpc/issues/2691), this becomes a
configuration that we can't support without doing something to give a
name to a thing we only have an IP for (hosts file on the Windows
client?). Given the realities of operating in a hospital IT
environment, NOT supporting use of IPs instead of names is NOT an
option.
gRPC supports IP address(it is also mentioned in the last comment of the issue you brought up). You will have to put your IP address in the SAN field of server's certificate, instead of the CN field. It's true that it will be a problem if your IP will change dynamically - that's why we need DNS domain name, and set up the PKI infrastructure. If that's a bit heavy amount of work for your team, see below :)
Is there some simple way to accommodate this situation? I'm far from
an expert on any of this, so it's entirely possible I've missed
something very basic.
Is there some simple way to set the name that the client uses to check
the server to be different than the name it uses to connect to the
server? That way I could just set a fixed name, use that all the time
and be fine.
You can directly use IP address to connect, and override the target name in the channel args. Note that the overridden name should match the certificate sent from the server. Depending on which credential type you use, it could be slightly different. I suggest you read this question.
Is there some way to get a gRPC client to not check the server
certificate? (I already have the server setup to ignore the client
cert).
Is there some other way to get gRPC to encrypt the connection?
Note that: Even if you don't use any certificate on the wire, if you are sure the correct credential type(either SSL or TLS) is used, then the data on the wire is encrypted. Certificate helps you to make sure the endpoint to which you are connecting is verified. Failing to use certificates will leave your application to Man-In-The-Middle attacks. Hope this can help you better understand the goals and make the right judgement for your team.
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.
There are the following parameters:
I use the FirebirdSql.Data.FirebirdClient library in asp .net
Now, at the test level, I connect to the remote database using the line:
string workbase = "Server="public ip";Port="port";User=sysdba;Password=masterkey;Database=C:/path/db.FDB";
Further are connection methods, requests, transactions, commits, etc.
string sqlcardpin = $"SELECT.....";
var connection = new FbConnection(workbase);
Question: is it safe? Is traffic encrypted? where can I read about it? How should I connect?
From my modest brain efforts, the following goes: I need to have a service in a local network with a database, to which a secure connection goes, and this service has credentials for connecting to the database and performs operations with it, maybe I'm wrong, please correct me.
If 'public ip' is a publicly routed IP address, and port 3050 is open to the whole world, that is not safe. Don't expose your database server to the world, it will create a very wide attack surface to get at your data.
For example, Firebird 2.5 and earlier have a very weak authentication system (max 8 character passwords), and while Firebird 3 introduces a new, more secure authentication mechanism that allows much longer passwords, for various reasons, a lot of servers are still configured with the weak authentication (also) enabled. Also consider bugs that might allow people to circumvent authentication, or that could allow people to remotely crash your database server, etc.
As to encryption, Firebird 2.5 and earlier have no encryption of the connection. This was introduced in Firebird 3, and only for connections authenticating with the new SRP (Secure Remote Password) authentication mechanism, and only if the WireCrypt setting of the server is Required or Enabled and the client actually requests authentication. For C#, this requires Firebird ADO.net provider version 7.0.0.0 or higher. However, the wire protocol encryption offered in Firebird 3 is the relatively insecure RC4 encryption; Firebird 4 will introduce ChaCha-20 as an alternative wire protocol encryption.
So, your database should be on the same network as your application, preferably on an IP address that is not routable over the internet (ie in one of the private ranges), or at least shielded from the internet by a firewall. If for some reason you need to connect to a remote database over the internet, do not expose the database directly to the internet, but use a VPN solution, or maybe something like an SSH-based tunnel.
And as corradolab points out in their answer, don't use masterkey as a password for SYSDBA. In fact, don't use SYSDBA for your application to connect, but create a specific user and assign it the necessary but minimal rights for it to do its work.
You didn't say if the web server and the database server are on same or different site, but, anyhow,
do not expose a database server to the public Internet.
If web and database server are in different sites, consider using a firewall (on the database) to allow connection only from the web server address or a VPN between the two sites.
If they are in the same site, expose only the web server to the Internet (put it in DMZ) and keep the traffic to and from the database server on the private LAN.
BTW Having Firebird on the Internet using sysdba/masterkey is like going around with "kick me" written on your back. Don't be surprised if it hurts. :)
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 have an application (written in PHP) that fetches data from several remote Progress databases.
The way it is working now, we ask our clients to open a port in their firewall to our IP, then we're able to run queries using ODBC connection from the PHP code.
The problem is that the data transferred over the internet is unencrypted.
We thought about two solutions but we've issues with both:
Updating Progress DB to use SSL. Problem: this requires our clients to change the way they connect with other vendors to have them all using the SSL.
Creating a VPN connection between us and the clients. Problem: we have many clients and the IPs/subnets may be overlapping.
What else can we do to have the data transferred to us encrypted?
Thanks.
Create an SSH tunnel between your systems - this'll allow them to work as they were, the comms will be encrypted, as long as the client systems support SSH connections.
https://en.wikipedia.org/wiki/Tunneling_protocol
This document looks fairly complete:
https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-tunneling-on-a-vps
You can find a windows version of Open SSH here:
http://www.mls-software.com/opensshd.html