SSL Certificates with FileMaker

Intro: SSL Basics

SSL certificates are a very common way to secure client/server network connections, and the FileMaker platform has made use of them for many years. Starting with version 15 however, FileMaker introduced a number of security changes, in handling SSL and certificates, on both the server and the clients. But where do they come into play, and how might this affect your deployments?

Because of the amount of terminology involved and the wide scope that SSL (Secure Socket Layer) connections cover, we should first go over some basics of typical SSL connections and the certificates needed to use them. In an attempt to be as brief as possible, I’ll be mainly discussing server configuration issues, and leaving out many smaller details. Definitely check out the references and links if you’d like more information.

Why Use SSL?

This is after all the heart of the topic. Network security is a non-trivial subject that can seem overwhelming, but hopefully anyone deploying or managing a server is at least somewhat interested in their system’s security. Using SSL-based connections is a very basic step you can use to help with the following goals:

• users can trust that they are connecting to the correct server
• prevent MITM (man-in-the-middle) attacks
• prevent packet injection or forged content
• greatly reduce packet sniffing/snooping

For situations where a server is on a public (Internet) IP these goals are central. But these issues can seem esoteric for those who never access their servers remotely and where their servers are only accessible on the LAN. But even for these networks, one or more of the following are possibilities:

• a system on your network gets hacked
• a weakly-encrypted wireless connection (e.g., WEP or WPA1)
• your router gets hacked
• an untrusted device (or malicious user) connects to your network

If any of the above are true, then its quite likely that the same actors involved will also attempt to discover your passwords or any other confidential content passing over your network. For FileMaker Pro & Go connections, even when not using SSL, credentials are encrypted and data will have some minimal encryption. But consider the following XML query:

curl -u "myuser:secretpassword" "http://server.example.com/fmi/xml/fmresultset.xml?-db=mydatabase&-lay=PROJECT_XML&-max=10&-findall"

This would pass over your network without any encryption, and could be a great use case for SSL, since both the data and credentials are passed unencrypted. To fix this, we could change the code as follows (assuming port 443 is being used for https connections):

curl -u "myuser:secretpassword" "https://server.example.com/fmi/xml/fmresultset.xml?-db=mydatabase&-lay=PROJECT_XML&-max=10&-findall"

So for this script, adding a “s” was all it took to improve its security.

In Part II, we’ll discuss a few additional benefits specific to FileMaker.

Downsides to SSL?

You will need to use a signed SSL certificate. Although there is some small benefit with using FileMaker’s self-signed certificate, in order to fully realize the benefits mentioned above, a custom certificate signed by a certificate authority is needed (we’ll delve into certificate types in Part II). Acquiring this can present some initial logistical challenges, and require administrative overhead, as well as yearly fees for renewal.

SSL connections will not help with EAR (Encryption At Rest) requirements. In other words, any database files, scripts, or other documents available via the file system will not be protected by SSL. However, it can indirectly protect data at rest by making it harder to exploit a network connection to gain file system access or sniff passwords.

There is a performance penalty for encryption and decryption of data. In the past, I’ve heard this stated as being as high as 10% added overhead, especially for the initial connection setup. But I suspect this is now much reduced as algorithms have improved and most CPU’s have started to include instructions to help optimize encryption speeds. Features in the latest revision of SSL (aka “TLS”), such as session reconnects, will also help reduce any overhead.

It does not protect you from dictionary attacks. Various forms of this attack are frequently used, probably because they are frequently effective and easy to implement. Besides using strong passwords for all access, you may want to consider using external authentication or fail2ban to help block these attempts. Since version 14, the FileMaker Admin Console will block access from a given IP address for 15 minutes after 5 repeated failures.

What access can use SSL?

Here we start to get a bit more specific to FileMaker. All of the various methods of accessing a FileMaker system can be made to use SSL connections.

These include:

• external container data (uses http/https)
• FileMaker Pro & Go client connections (port 5003)
• FileMaker Pro’s Upload to FileMaker Server (uses http/https)
• FileMaker Server’s Admin Console (when using port 16000)
• ODBC
• WebDirect or CWP (Custom Web Publishing)
• XML

Since version 14, FileMaker’s HTTP and HTTPS ports have been configurable, but still default to ports 80 and 443, respectively.

One minor exception on the use of SSL is port 16001 access to the Admin Console – this always uses a connection without SSL, but is only accessible locally.

Enabling SSL

Once you have installed your SSL certificate, you’ll need to enable it in the various access methods. For some methods, access is controlled by the settings in the Security tab of FileMaker Server’s Admin Console.

Use SSL for database connections: Enabling this makes all FileMaker Pro & Go connections use SSL. It will also cause WebDirect connections to redirect to the https port. This was titled “Use secure connections” in FileMaker 13.

Use SSL for progressive downloading: When checked, external container data will use SSL based connections.

Other types of access require modifications outside of the admin console.

CWP: This is perhaps the most complicated case for switching access. Besides only providing links to the SSL site, you may want to disable access via http connections (perhaps at the firewall) or add a redirect to the SSL version. You may also need to move your PHP files out of the http directory (e.g., move from the htdocs folder to the httpsRoot folder), and fix links (static or dynamic) that might be using http connections.

JDBC: I haven’t been able to determine yet if JDBC connections can be encrypted. I’ll update this when I learn more.

ODBC: For ESS connections, this must be configured in the DSN settings with ODBC Manager.

XML: As mentioned previously, this will require modifying any scripts or configurations in the external system to use an https connection. For most systems this should be fairly easy, but it could be problematic if you must edit a system’s source code. For many scripts or commands, such as curl, options must be set to allow the use of an unsigned certificate.

References

• FileMaker 16 Security Guide: Best Practices for Configuring Security Options
• FileMaker 15 Security Guide: Best Practices for Configuring Security Options
• FileMaker Network Security and SSL – Overview
• FileMaker SSL Certificate Network Encryption Security
• New Security Features In Version 15 FileMaker Platform
• The SSL Performance Myth