I am attempting to establish MariaDB replication using SSL Certificates for authentication. Reading the documentation about setting up the master server with a slave user which uses the GRANT command.
At the following link ( https://mariadb.com/kb/en/mariadb/grant/#per-account-ssltls-options ), the part to set up authentication on the account uses REQUIRE ISSUER and REQUIRE SUBJECT. These take in string representations of part of the SSL Certificates.
My question is, how is the client certificate, which will be provided on connection by the slave server, verified by the master? I cannot see in config where the master server is provided with a client certificate chain that the slave's certificate is issued off. Have I missed where the master is loaded with CA/chain certificates or even just the client certificate?
If it does not, the replication does not seem to be using any of the crypographic properties of the certificate. Just string matching on the certificate subject/issuer.
Related
i have an SSL handshake issue on one of my servers. the certificate is CA signed and the server is still showing "not secure"
i got another server using the same root chain and it is secured.
root/intermediate certs and the CA itself are all uploaded on the machine and the browser
chain is 100% valid as it was identified via the Subject Key Identifier/Authority Key Identfier.
from pcap i see this for non-working
CSR was verified to match the cert
the server side is never pushing the Hell Server,Certificate message
it does look like a server side issue for me. not a client one
again the same chain is used for another server and the browser is considering it secure.
anyone can assist?
certs were uploaded on Trust-root authority for the browser
installed on the machine itself (local machine and current user)
cert itself was verified
certificate was verified in the server's DB as well as its chain
I was trying to establish tls between an app and mysql server (no mutual authentication is needed in this case)
URL passed in my Hibernate Property file:
hibernate.dialect=net.sf.hibernate.dialect.MySQLDialect
hibernate.connection.url=jdbc:mysql://mysql-0:3306/dbschema?useSSL=true&requireSSL=false&trustCertificateKeyStoreUrl=file:/opt/jks/truststore.jks&trustCertificateKeyStorePassword=test12
Also I'm passing configuration in percona server like this :
mysqld --ssl-ca=/custom_certs/ca-test.pem --ssl-cert=/custom_certs/server-cert-test.pem --ssl-key=/custom_certs/server-key-test.pem --require-secure-transport=ON
After doing all the changes and adding trust store to the app, while starting application tls ceremony is enforcing client certificate retrieval.
Network capture looks like this:
MySQL --> Login Request user= TLSv1.2 Client Hello
TLSv1.2 --> Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
TLSv1.2 --> Certificate
TLSv1.2 --> Alert (Level: Fatal, Description: Unknown CA)
I also verified the user table to see if there's requireX509 column enforced as true for the said user, but that was not the case.
What can be the root cause of the issue? Is there any missing hibernates / mysql property or some other configuration that is possible via code?
Please note: Here I don't have the access to the code of app. Only configuration files are accessible via k8s secrets.
Is there any way to disable MySQL automatic TLS generating?
CN=MySQL_Server_8.0.25_Auto_Generated_Server_Certificate
CN=MySQL_Server_8.0.25_Auto_Generated_CA_Certificate
If i check my website with search.censys.io, i can find it's ip even though it's protected by CloudFlare because MySQL has generated a TLS certificate which exposed original server's ip
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Does a localhost connection to a MariaDB (or MySQL) database could be intercepted without SSL / TLS protocol.
For me the solution is very simple:
I learned that an unencrypted connection with PHP (MariaDB and MySQL) and the localhost as host will connect via the UNIX socket and is therefore safe! However, it is not a mistake to use an SSL certificate. This is particularly important for connections via applications in other programming languages (e.g. Java). Even if there is an internal danger in the network, it is advisable to choose an encrypted connection. (TLS is even safer then SSLv3). In my case I don't need to use SSL or TLS.
Normally a database server should accept connects only from one application server configured by IP. If the database is used by more then one application, the server, which is able to connect to the database must hold a webservice which can be used to access the database.
There is no need to connect from different servers to a database. So you do not need any secure connection which would slow down the transfer.
SSL (latest version was SSLv3) is considered to be vulnerable and isn't supported anymore by recent versions of MariaDB (and MySQL).
Instead of use the successor TLS (Transport Layer Security), preferrable protocol versions TLSv1.2 or TLSv1.3 which are considered to be safe.
In Addition MariaDB also offers additional security checks for TLS connections, e.g.
Client:
check the the name in server certificate matches the host name in connection string
verify the finger print of server certificate
specify a cipher suite for connection (or exclude certain cipher suites)
Server:
require X509 certificate from client
check subject and/or issuer of client certificate.
specify a cipher suite for connection (or exclude certain cipher suites)
For more information please check
Securing connections for client and server.
Transport Layer Security
Yes, if you have concerns about malicious users having access to your network, you should use SSL for connections between the app and the database server.
At my company, everything must be SSL. Every app-to-app connection must be https. Every database connection must be SSL. It doesn't matter that it's behind multiple levels of firewall in our internal network. It's defense in depth.
We do use certificates with the SSL, for both validating the SSL encryption and for authentication. It's stronger authentication than using passwords.
When we say SSL that's because the MySQL options use that term. But we really use TLS.
Note that MySQL's bind-address while limiting the clients who can connect to the database server, does not stop wiretappers from intercepting TCP packets. They don't have to connect to the database server to do that, they just have to be on the same network.
I've found that if you connect to a Cloud SQL instance over SSL the CommonName provided in the server's certificate is my-project-123456:myinstance which renders the certificate un-validatable, as the client expects that the CN to be either the hostname or IP.
Every solution to this problem seems to amount to "just disable validation", which is not acceptable to me because:
Why has GCP decided to do everything else correctly, providing a CA cert and client certificates, only to drop the ball on identity validation? By disabling validation you're basically saying "I'm OK with being MITMed at some point".
What about projects where we can't play fast and loose with validation because of PIPA/HIPAA?
What about mySQL clients that don't support turning validation off? eg: All PHP 5.6 mysql libs using mysqlnd prior to the upcoming 5.6.16 release.
Is there any way to make SSL work correctly on Cloud SQL?
One of the reasons for not having the IP address of the instance in the common name of the server certificate is because these IPs can change. What is the IP address of instance A today can be the IP address of instance B tomorrow, because A was deleted, or A decided that it doesn't want the IP address anymore. So, the instance name was decided as being a more unique identification of the instance.
Also, the mysql client libraries by default have hostname verification disabled. http://dev.mysql.com/doc/refman/5.7/en/ssl-options.html
With regards to MITM attacks, it is not possible to MITM attack a Cloud SQL instance because the server certificate and the each of the client certificates are signed by unique self-signed CAs which are never used to sign more than one cert. The server only ever trusts certificates signed by one of these CAs. The reason for using unique CAs per client cert was because MySQL 5.5 did not support certificate revocation lists, and we also did not want to deal CRLs, but wanted to support deletion of client certs.
We will look into ways of supporting SSL for clients which cannot turn off hostname validation. But I cannot promise an ETA on this.
Cloud SQL Team.