To secure your data from hackers while traveling the Internet, the FileMaker Platform provides way to use the SSL Protocol with its FileMaker Server software. Information on how to do this is provided in detail in the FileMaker Server product documentation. However, unless you know a little about how the Internet works, just what one is doing and how it keeps your server secure when you follow the instructions to install an SSL certificate may remain a mystery. I wrote this article to provide some background.
TCP/IP, the Communication Language of the Internet
The Internet is a network of devices serving as connection points for moving data at various speeds while a governing body called ICANN (Internet Corporation for Assigned Names and Numbers) watches over the process. The Internet is run by protocols, a set of rules that determines how this data is sent back and forth. The underlying communication language of the Internet is a 2-layer protocol called TCP/IP. TCP stands for Transmission Control Protocol, and IP stands for Internet Protocol.
Network packets are the smallest unit of information transmitted over the Internet. IP is responsible for mapping out how to get the network packets to the correct destination via a series of “hops” between Internet connection points, identified by an IP address. A network packet using IP carries with it a “header,” which holds information about the source and destination of the packet, its size, etc. IP has some limitations: it does not control the order by which the data packets arrive at the destination, whether it arrives at all, how fast they arrive, and the size of packets are limited. It’s like waiting for a friend at the airport without a phone, while not knowing whether all the bags arrived because they were sent separately on unidentified planes.
Like a good airport authority, TCP adds a control layer on top of IP to make it more reliable. TCP allows one device to talk to another device by establishing a connection tunnel called a “socket” between two endpoints. A socket is created as the end result of a “3-way handshake”, a series of negotiations between a sending device and a receiving device, which determine the parameters of the socket connection. The negotiation goes like this:
• Device A sends a TCP SYN (synchronize) packet to Device B.
• Device B receives A’s SYN packet and sends a SYN-ACK (acknowledgement) packet back to Device A.
• Device A receives B’s SYN-ACK packet and sends an ACK packet back to Device B.
• Device B receives A’s ACK, and a socket connection is established.
Once the connection has been established, the socket remains open for the duration of communication between the endpoints. TCP then compiles units of data called network packets into the correct size, organizes them into a sensible sequential order, sends them to the destination in a data stream, resends lost or out-of-sequence packets, acknowledges receipt of each packet, and controls the speed of data flow so that the receiving device is not overwhelmed. Once the communication ends, another set of negotiations is performed to tear down the TCP socket connection.
TCP is great, but it doesn’t concern itself with the safety of where network packets are going. Like airports in the U.S. before 9/11, TCP doesn’t care whether a device’s identity is valid or a “man in the middle” pretending to be the device.
When hosting a server, it is important to be able to assure visiting clients that the destination point of any data being transmitted back and forth from the server is a location verified by a trusted authority. It is also important to know that when transmitting sensitive data like personal contact information and credit card numbers, the data itself is encrypted and inaccessible even if it is intercepted.
The Secure Sockets Layer (SSL) is the most basic internet security protocol that provides the data security described above. The SSL protocol operates on top of TCP. It is another series of negotiations that results in a secure socket connection between the two endpoints established by TCP:
• After a TCP socket is established, an SSL handshake is initiated by a request from client software such as a browser or other app on the sending device. The client sends which version of SSL it is running, what ciphersuites it wants to use, and what compression methods it wants to use.
• The recipient (server) determines the highest SSL version supported by both endpoints, chooses a ciphersuite from the client’s options, and optionally chooses a compression method. Then it sends its SSL certificate.
• The certificate must be trusted by either a trusted third party known as a Certificate Authority (CA) that has cryptographically signed the server’s certificate or by the client itself (which is when you get the dialog box asking if you want to trust the server). Once the certificate is verified and/or the client is certain this server really is who it claims to be, an encryption key, created according to the chosen ciphersuite, is exchanged. The server and client can then compute the private key for symmetric encryption. The client sends an encrypted and authenticated message to the server.
• The server verifies that the MAC is correct, and that the message can be correctly decrypted. It returns a message to be verified by the client.
• The client verifies the message. The handshake is finished and secure communication between the client and server is established.
Faster and friendlier than an airport security checkpoint, SSL allows the encrypted data to travel freely to its destination. On a web browser, you will see the SSL connection by checking the address bar. The URL will start with https:// instead of http://, and you’ll see a lock icon in the address bar. When connecting to a FileMaker Server, you will see a green lock in the top right corner of the solution window.
Using SSL doesn’t make it completely impossible to steal network traffic data, but it certainly makes it much more difficult. Even if a hacker could steal or mimic an SSL certificate, s/he would still need to have the private encryption key provided when the original connection was established to be able to decipher the data into a human-readable format.
As more FileMaker solutions move to the cloud and data is shared over the Internet, SSL has become a much more prominent feature of FileMaker Server, and I expect that trend will continue.
Resources and Links for Using SSL With FileMaker Server
Now that you know how it works, you can create secure connections to and from your FileMaker Server installation by importing an SSL Certificate using the FileMaker Server Admin Console. You can get more information about configuring security for FileMaker 17 here:
Configuring Security for FileMaker 17: https://support.filemaker.com/s/answerview?language=en_US&anum=000026004
Note that FileMaker Server does not officially work with every Certificate Authority. Here is a link to help you figure out which CA is right for your setup and FileMaker Server version:
FileMaker Network Security and supported SSL Certificates: https://support.filemaker.com/s/answerview?language=en_US&anum=11413
In the case you’re not interested in paying a CA for an SSL certificate, David Nahodyl, of Blue Feather Group, does a wonderful job of explaining how to install a free one from Let’s Encrypt, a non-profit Certificate Authority on Mac and Windows.
Please let me know if this article was helpful, and/or feel free to contact us at infoCypher if you would like us to set up SSL on a FileMaker Server for you.