Enable SSL Connectivity from IPS to MySQL Database

[Johno2518]

Hi,

I have split my IPS Web App and Database server and they are hosted separately (Azure Web Apps hosting IPS app and Azure Database for MySQL). Given that data can be captured over the wire in clear text leading to secure vulnerabilities (note blocking port 3306 will not prevent someone sniffing traffic and seeing the data in clear text). The services are hosted in the same datacentre however this will not hide/fix the issue. Only hosting the web app and DB on the same server would prevent this issue.

Can you please enable an option in conf_global.php to enable IPS to initiate a secure connection to the database. Not sure what function is in use however if using the PHP MySQL_connect function, the last parameter is client_flags needs to be set to MYSQL_CLIENT_SSL.

However this gets implemented, I think its a critical setting required for a modern micro services design.

Thanks

Jonathon

[Lindy]

As noted in your ticket: 

 

I can appreciate you've done some research on this, but you are referencing deprecated extensions in MySQL. Invision Community utilizes mysqli and the process (ssl_set()) is different than simply appending a flag. In addition to changes to the database handler, you would need to generate a certificate, bind that certificate to your installation, etc. It's certainly not as simple as setting a flag and while Azure may provide a mechanism to somewhat simplify this by generating a certificate (though it doesn't work with mysqli without additional setup), it's unfortunately not something we presently support on an application level or have roadmapped to support in a self-hosted capacity. 

The proper method, with SSL DB or not, is to secure transmission between your web nodes and the database on a network level. There should never be an opportunity to "sniff" a connection from other nodes on a network to database, because only your web nodes should be able to access the DB. A virtual network, vlan, virtual private cloud and appropriate security rules should be utilized so that only web nodes are able to communicate with your database. In the case of off-premise access to the database, network rules to only allow specific IPs should be created and enforced. 

I apologize for any frustration and inconvenience. This is rather environment specific and not generally an out-of-the-box offering. 

I'm sorry I couldn't be of more assistance, but we appreciate the feedback. 

 

[Johno2518]

Hi Lindy,

 

Please see reply in ticket, this does not negate the requirement for Transport encryption which is also lightly touched on by

 

Anyone who packet inspects the data over that network will be able to view all content in clear text. In AWS land this is the VPC, someone can packet inspect traffic and firewall rules will not prevent this.

I look forward to seeing how Invision will address this vulnerability.

I've enjoyed the conversations as its great to see different aspects of the designs/implementations of the software.

[Summit360]

Just to add to this as I'm sure we're not alone... I've reached the end of the economic line for a single VPS. I count myself lucky the provider is excellent and very few SPOF incidents. I don't wish to move to a single commodity dedicated server, I'm going horizontal. Using any of the leading VPS providers there is a 'private' network which isn't actually 'private'. A couple do offer it. A VPN would be the only solution that works at any host, based on your feedback @Lindywhich is more complex to setup and manage than certificates.

I don't think it's unreasonable for us to have a way of securely connecting to our database servers out of the box, others manage it.

Issuing certs and distributing them isn't really a challenge. With the rise of tools like RDS and other 'remote' cloud services, we're increasingly connected beyond the idilic single server setup. As @Johno2518 says, transport security is the key. Because even in a private world, it's not if, but when!

I'm probably going to solve this with either editing the core files, or following plan A with running Maria in a cluster and still having a 'localhost' connection. Its far better now than it used to be ? i.e. it works without needing a full-time dba to keep it running ?

 

[Dll]

Have you considered moving your hosting over to the likes of google, as then you can use their mysql proxy to connect via ssl

https://cloud.google.com/sql/docs/mysql/sql-proxy

Or use an open source proxy such as this one:

http://www.proxysql.com/

[InsERT Webmaster]

Any news on this @Lindy? Connection encryption is pretty much the standard these days as regulations like GDPR effectively mandate its use.

It's rather surprising Invision hasn't caught up yet.

[bfarber]

On 9/8/2020 at 8:49 AM, Pawel Pesz said:

Any news on this @Lindy? Connection encryption is pretty much the standard these days as regulations like GDPR effectively mandate its use.

It's rather surprising Invision hasn't caught up yet.

As mentioned, you can encrypt the connection between your web server and database server at the network level already.

[InsERT Webmaster]

4 minutes ago, bfarber said:

As mentioned, you can encrypt the connection between your web server and database server at the network level already.

Are you referring to using a proxy @bfarber? That solution adds an extra layer which is completely unnecessary as encrypted connections are well supported in PHP.

As other users had pointed out, other suggestions like VPC are rather unsatisfactory.

[Clunk]

This is still a problem in AWS land.
It requires setting up an extra VPN layer, and even though prohibits the MySQL server from having the `require_secure_transport` enabled, resulting in incidents from security scanners.

MySQL Client encryption is widely supported in all kinds of applications and it would be really beneficial to have it supported in Invision too.

[Marc]

Please see the response on this from my colleague above