Hi experts could anyone explain how Client certificate and Server certificate validation work in Snowflake? I am confused what OCSP actually does in each flow.
More details: https://docs.snowflake.com/en/user-guide/ocsp.html#ocsp-overview
Summary:
OCSP is an industry standard that is meant to run over Port 80. Snowflake uses Online Certificate Status Protocol (OCSP) to provide maximum security to determine whether a certificate is revoked when Snowflake clients attempt to connect to an endpoint through HTTPS.
Snowflake uses OCSP to evaluate each certificate in the chain of trust, up to the intermediate certificate and the root certificate authority (CA) issues. Ensuring that each certificate is not revoked helps Snowflake to establish secure connections with trusted actors during the identity verification process.
Why OCSP use Port 80?
Port 443 is primarily used for HTTPS (HTTP over SSL/TLS). Certificates are inherent to secure TLS connection and hence certificate revocation check too would be inherent to TLS. OCSP is a standard meant for performing certificate revocation checks. Running OCSP checks over port 443 can mean two things:
OCSP traffic is encapsulated within TLS traffic but then since TLS needs certificate revocation and OCSP is meant for Certificate Revocation check, there is no way to perform revocation check for OCSP.
A potential proxy TLS service that proxies OCSP traffic to the right OCSP server. Client to proxy connection on port 443 and proxy to OCSP Server connection on port 80. This however would not change the security scenario in any way since there would still be a client reaching out to port 80.
The OCSP Servers running on Port 80 are not run by Snowflake. These are run by the Certificate Authorities that are beyond our control. This is also a standard.
The point to note here is, opening Port 80 with strict whitelisting is reasonably secure as there is full control over what goes on in that Port.
Related
I have setup my own mongoDB and enabled authorization that’s hosted on an external server.
Which i can now connect to my DB using mongo Compass while mongoDB is:
bindIp : 0.0.0.0
But not any other things else.
Then I found this thread on the mongoDB community forum:
here
Stating that there’s a misconception on bindIp. Which it does not listen to remote ip that wants to connect, but listen to only local network. In order to connect to my mongoDB with a remote ip while not opening all my port to public (0.0.0.0) i need to set up a SSL connection.
Now here’s the problem. How do i setup SSL connection ? I took the class M301 and know about X.509 but still have no clue how to connect via SSL.
I would like to connect through something like with the connection string of:
mongod://:#XXX.XX.XX.XXX:XXXXX/?ssl=true <<<<
If X.509 is the method, how do i work with pem key ? how do i sign one ? how do i use client key in mongo compass?
If you have a certificate, MongoDB documentation provides guides for setting up TLS on the server. How to create the certificate is usually not covered; typically you would either work for a company whose IT department would take care of this for you, or you would use a service such as MongoDB Atlas which would handle TLS termination.
For learning purposes you can use self-signed certificates and there is probably a university course for setting up TLS.
I am creating a simple client to connect to the LDAP servers running on one of my windows 2008R2 Active Directory Domain Controllers.
I have successfully connected to the LDAP server over a non TLS connection. However, whenever I attempt to make a TLS connection, the handshake fails. After some digging, and downloading the certificate using the following command:
openssl s_client -connect <domain controller>:636
I found that the certificate being served from the LDAP server is invalid. I can see that the certificate is signed by our CA and my local system, that runs the application already has this trust established with the CA. However, It is missing all of the subject information in the certificate. The client application does not allow for this.
After speaking with the administrator, he indicated that the certificates being generated for the domain controller systems to serve TLS certificates over LDAP is automatic and is created by our internal Microsoft Certificate Server. He was not sure how to address this.
After numerous Google searches, I have come up pretty empty on how to resolve this. Is it something that is addressed on the certificate server? Is it something on the domain controller which is stripping the subject information? Is it some setting or configuration? Since, I do not have direct access to these systems I am at a loss on where to begin.
Any assistance would be appreciated.
Blindly trusting a certificate that is invalid is not an acceptable solution.
Ask your admin to export the root certificate for your environment (like, to a .cer file). Then you can use that file to add it as a trusted root certificate on the computer that needs to access it.
That's how we do it in our environment when we've needed to access an external domain over LDAPS.
Of course, that only works if the application accessing LDAPS uses the Windows certificate store. Some applications, like Java-based apps, don't, and you need to do it another way.
I was able to assist my Admin with updating the template the certificate server was using to include the subject and subject alternate name.
I found the following articles that helped determine the problem
https://blogs.msdn.microsoft.com/microsoftrservertigerteam/2017/04/10/step-by-step-guide-to-setup-ldaps-on-windows-server/
https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx
https://support.microsoft.com/en-us/help/931351/how-to-add-a-subject-alternative-name-to-a-secure-ldap-certificate
Ultimately going over each setting until we found the right solution that solved the problem of why the certificate server was sending and invalid certificate.
Is there a way to set more than one certificate as a device certificate in the SSL Context? I will be having two certificates signed by different trusted CA servers in server SSL. But client can validate only one of them. I am looking for a way to update the SSL context with two certs. I am planning to send both to the clientSSL and the client will check both of these and pick just one of them as server dev cert.
You can't just arbitrarily redefine TLS. The Certificate message only allows one certificate and its authentication chain. See RFC 2246 and successors.
I am having to consume a web service via 2 way SSL. We have exchanged certificates and I am trying to connect and am getting a handshake failure. I am using Oracle Service Bus to connect to the web service. My questions:
What is the keystore in the fwmconfig folder (that I access from Oracle Enterprise Manager)?
What is the keystore in the weblogic server (that I access from the admin console/managed server keystore tab)?
What are the differences between these and which one should I use to import the servers cert and try to connect?
Also, there are cacerts in several directories in the installation, what do I use those for?
Not knowing where to import the server certificate. Can someone please help?
The enterprise manager keystore is used by fusion middleware for message level security (encrypting the message with certificates
The weblogic keystore is used by the webserver/load balancer to accept the HTTP requests and handles SSL
See above
The cacerts are the default trusted Root CA's
So the keystore to use for enabling SSL is the weblogic server version.
Also be sure to enable 2 way SSL in weblogic:
http://docs.oracle.com/cd/E14571_01/apirefs.1111/e13952/taskhelp/security/ConfigureTwowaySSL.html
Resources used:
http://theheat.dk/blog/?p=2059
If you use SQL Server Authentication (2005), are the login details sent in clear text over the wire?
As secure as you want to make it...
you can configure SSL fairly easily, and if you don't have a trusted cert, if you force encryption, SQL Server can create/issue it's own self signed cert for your use...from this write-up
Credentials (in the login packet) that
are transmitted when a client
application connects to SQL Server are
always encrypted. SQL Server will use
a certificate from a trusted
certification authority if available.
If a trusted certificate is not
installed, SQL Server will generate a
self-signed certificate when the
instance is started, and use the
self-signed certificate to encrypt the
credentials. This self-signed
certificate helps increase security
but it does not provide protection
against identity spoofing by the
server. If the self-signed certificate
is used, and the value of the
ForceEncryption option is set to Yes,
all data transmitted across a network
between SQL Server and the client
application will be encrypted using
the self-signed certificate
Whether or not the login credentials are encrypted depends on the encryption capability/configuration of the client and server.
At the protocol level, completely unencrypted SQL logins are allowed, though my guess is that these are rare because I suspect most modern database drivers do not support them.
Details
Clients communicate with Microsoft SQL Server using the Tabular Data Stream (TDS) protocol.
Shortly after a client opens a TDS connection to the server, it informs the server of its encryption capability. The server compares this announcement with its own configuration/capability to determine the encryption state for the connection.
In a nutshell, the encryption state is determined as follows:
If client or server announces that they do not support encryption and the other side does not require encryption, the entire connection—including login—will be unencrypted.
If both client and server announce that they support encryption but do not require it, just the first TDS packet of the login request will be encrypted. The remainder of the connection, including any additional login request packets, will be unencrypted. A properly-designed database driver will ensure that the SQL authentication password is placed in first login packet, but this isn't required at the protocol level.
If either client or server announces that they require encryption, the entire connection will be encrypted (except for a small amount of preliminary data) unless the other side does not support encryption. In that case, the connection will be terminated.
The only way to ensure that login requests are always encrypted is to set the 'require encryption' option on either client or server. There’s no option to disallow completely unencrypted connections without requiring full encryption.
Regardless of whether or not the login or connection is encrypted, the SQL authentication password is always obfuscated but the scrambling is easily reversible.
Further Reading:
Technical details on connection encryption states - MS-TDS 2.2.6.5 PRELOGIN (under heading Encryption)
Password obfuscation formula - MS-TDS 2.2.6.4 LOGIN7 (see last paragraph)
Slightly more in-depth write-up on the topic - SQL Passwords: Encrypted Between Client and Server? (disclaimer: this is a post on my blog)
The credentials are sent in clear text.
You can probably find a number of sources for this, but here's one:
"Secure the channel between the Web server and database server because credentials are passed in an unencrypted format. For example, use SSL or IPSec."
Here's a link to some security best practices for SQL 2005. That doc states in part:
In Windows Authentication mode,
specific Windows user and group
accounts are trusted to log in to SQL
Server. Windows credentials are used
in the process; that is, either NTLM
or Kerberos credentials. Windows
accounts use a series of encrypted
messages to authenticate to SQL
Server; no passwords are passed across
the network during the authentication
process. When SQL logins are used, SQL login passwords are passed across the network for authentication. This makes SQL logins less secure than Windows logins.
Reading this thread made me even more confuse then I was!
Anyway, I did some tests with Wireshark, with or without encrypted connection I was never able to see my password (and my user name I think). What was very visible without encryption is the actual queries.
Perhaps it is the lack of knowledge with Wireshark to retrieve the login credentials, but since I was able to see everything else I'm pretty sure I was looking at the right spot and the password was ALWAYS hidden.
Apart from the fact that passwords are sent in clear text, it is also possible to replace the hash of the password.