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
Related
I've some mysql host in private network and would like to use a reverse proxy server (i.e. nginx) to connect with mysql-client to mysql host via reverse proxy server.
An example to better understand my answer:
suppose I've:
a mysql server with ip yyy.1
a mysql server with ip yyy.2
both in the network of a proxy server with ip XXX, and I associate to XXX the DNS mysql-server1.com and mysql-server2.com.
My goal is connect to mysql server yyy.1 when I use mysql client to connect to XXX by calling mysql-server1.com on port 3306, and similare when try mysql-server2.com on port 3306.
The problem with nginx is that I can't differenciate TCP request by server name, so in XXX server I should associate one port foreach mysql server, but this implies that every time I should change the port also in mysql client settings, and I don't wanna this!
There's some proxy-server that can accomplish that?
Could I use IP Table to route the request mysql-server1.com:3306 to localhost:[some port], where I could use [some port] in proxy setting to forward the requests to the server yyy.1?
This is impossible.
In the MySQL Client/Server protocol, the client never identifies the hostname to which it is attempting to connect to. Unlike in some other protocols, such as HTTP (with the Host header), the original name the client used to resolve an IP address from DNS is not preserved. TLS SNI is also not available, because TLS negotiation on a MySQL connection does not begin until the client reads the server capability flags to discover whether the server supports TLS, at which point the client asks to switch the connection to TLS... and this, of course, is after the connection is is already established.
In the MySQL Client/Server protocol, the server always talks first.
Your only options are for the proxy machine to listen on multiple IP addresses, with a DNS hostname pointing to each IP, and use the address to which the client connected to determine which server to use.
Or, each proxy instance listens on a separate port.
The protocol design prevents name-based virtual hosting.
I am trying to establish a SSL-encrypted connection to a my MySQL Docker service running on a AWS VPC (setup up by the Docker for AWS cloud formation template). The elastic load balancer is configured to redirect port 3306. There is no problem to connect to the container (e.g. by using MySQLWorkbench, mysql-client, ..) as long as SSL is not turned on (adding AWS's own certificates (ACM) or my custom certificates to the ELB listener). In case SSL is enabled, the client starts hanging / freezing, without returning a proper error. I added the ca-certs from ACM, generated my own certificates (with and without additonal key / cert for the client) but nothing seems to resolve my problem.
Now I am well aware of the fact, that this setup is not that usual. I guess the standard way of doing this is to configure the MySQL-Server itself. AFAIK, in this case only the connection between client and ELB is encrypted, but I do not understand why this causes a problem?
I am grateful for answers!
In MySQL's client/server protocol, the server talks first. It advertises its capabilities (including whether it supports SSL). Then the client requests that the connection switch to SSL mode. Only then does SSL negotiation take place.
For this reason, it is not possible to offload SSL in front of MySQL.
Your connection hangs because the client is waiting for the initial packet from the server, while the ELB is waiting for the client to start negotiating SSL -- because unlike the MySQL client/server protocol, the client talks first on standard SSL negotiation.
You have to have a certificate on the MySQL Server, and not on the ELB, for this to work.
An AWS Network Load Balancer is a more appropriate solution for exposing MySQL, but you still need the SSL cert on the MySQL Server itself.
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.
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.
Using as3crypto's TLSSocket it should be possible to connect to an SSL server. However, my server uses a self-signed certificate. How can I configure the client to accept that certificate?
I'm assuming I need to hard-code the cert's fingerprint in the client somewhere (or get it there some way). That's ok.
If as3crypto doesn't support this, other options are welcome.